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.

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