Team,
Summary of message:
* Reading web engineers should take on Reading-oriented api.php work and,
if they like and as appropriate, Node.js work
* App engineers who will come forward to work on Reading-oriented api.php
or Node.js appreciated
* Reading Infra (Bryan/Brad/Gergo) mandatory for Q4 code review or
API/Core, Q1 please engage Reading Infra for up front consulting and code
review for API/Core
Now, the full message:
On another thread there was some discussion around transfer of API features
from Max to Reading web engineers. Concurrently, we've been cataloging pent
up demand for api.php and Node.js API/Services style work.
https://www.mediawiki.org/wiki/Wikimedia_Reading/Mobile_needs_from_MediaWik…
Bryan, Toby, and I met yesterday to discuss the engagement model for
Reading web/apps and Reading Infrastructure. The outcome of that discussion
was carried into the standing Reading API/Services tri-weekly meeting
afterward, where there was basic agreement on an approach going forward.
Last evening, I discussed this with Jon Katz and Kristen as well. And the
Reading web/app leads met this morning to socialize further. Here's where
the thinking is:
* Generally, Reading web engineers will need to take on Reading-oriented
api.php work or, if they think it the right fit for a given problem,
Node.js service work, or both. App engineers should come forward if they're
interested in fuller stack development - for example, Bernd is already
writing Node.js code and it sounds like Brian may be interested in pairing
to tackle Text Extracts api.php stuff related to Share a Fact.
* Q4: Reading Infrastructure (Bryan, Brad, Gergo) available for code review
of API and MediaWiki core-related patches. Otherwise, it is focused on a
core set of problems that are set for Q4 (also, Gergo is half time on web
engineering at the for this quarter, although he'll taper off).
* Q1 and beyond: Reading Infrastructure available to Reading engineers for
** Up front consulting on API and MediaWiki core-related work. It's
critical to avoid missteps up front.
** Code review of API and MediaWiki core-related patches
** Approximately one api.php task implementation per Reading Infrastructure
resource per quarter for the web/apps area. In the API/Services meeting we
talked about perhaps something like pageimages and createaccount related
Phabricator tasks for Q1 as good candidates. The purpose of this work is to
demonstrate good examples of how work can be implemented, incrementally
increasing velocity, and providing an opportunity for web/app engineers to
pair up with their Reading Infrastructure peers.
This model mirrors the Services (not part of Reading) team model for
consulting, code review, and software architecture scaffolding. As the
Services team focuses much of its time on broadly available software
architecture, so too does the Reading Infrastructure team plan to focus
most of its work.
Practically speaking, it's hard to think at all levels of the stack. But we
have an extremely talented team, and an engineer can deepen one's
experience tier by tier over time.
In Reading web engineering there's a level of familiarity and expertise
with PHP - and where there's room for improvement I'm confident
professional growth goals can make this a reality. As with HTML, CSS, and
JavaScript, in the Wikimedia development environment PHP - and the
MediaWiki-oriented way of coding it - is critical to delivering high
quality user experiences. We fully support and encourage pursuit of
training / dedicated study in this area.
With respect to api.php and extension code hooked into it: a really key
part of writing this sort of code is understanding the boilerplate and
scaffolding pieces. Bryan's team is able to point people to existing good
examples and a number of web engineers are comfortable in this area as well.
As for growing more application server (PHP) skills in the MediaWiki
environment outside of api.php specifically (i.e., Core and other thornier
pieces of the codebase), Sam has offered to pair with anyone who wants his
help.
Thinking ahead, there is the more systemic question of staffing mix
dedicated to application layer services in Reading. The current plan, which
I have to note could be subject to change (budgeting is in flight, and we
have backfill and new resource requests in there), is to acquire talent for
web engineering in application layer services for the Reading experience.
While it's good for all web engineers (and some app engineers) to be able
to code to api.php or Node.js, there's value in having someone really
focused on this middle tier / middleware stuff in the Reading web/app area,
too. Max Semenik is now focused upon geo/Search & Discovery, and he had
deep expertise in this area, and we should be thinking about staffing for
this sort of skill level.
In a related matter, I've heard a number of people talking about a more
convergence-based approach to software development in Reading. For example,
implement a feature in the API portion of the MobileFrontend extension,
then leverage it in the apps and desktop web. This is the place we should
be for some (maybe for new stuff, most?) set of features, and part of
getting to this place requires small steps:
* Picking a few simple problems to solve and working across web & apps (&
maybe infra)
* Cataloging features by channel in some sort of matrix, and delivering
intentionally
We now have a weekly Reading web/apps engineering leads meeting, where we
can make some incremental progress on the first part for picking a few
simple problems.
For the cataloging piece, I'm working to figure out an approach (ideally
with a SPOC). The more intentional we are about which features get rolled
out where and in which order, plus think carefully about convergence versus
doubled effort (and to be sure there will be cases for both), the greater
our success will be delivering the most beautiful and channel relevant
experiences for our readers.
-Adam