Thanks for this email Adam. It took me some time to get to it :p
Just a little note regarding MobileFrontend. We are planning work to make
it thinner and better versioned, and strip certain responsibilities outside
of it and properly test them, like for example the mobileview API.
What I want to say with this is that any convergent development that
benefits several platforms should happen in new extensions, libraries &
packages, or somewhere else other than MobileFrontend.
Please lean on the Reading web if you need help to set up anything.
On Thu, May 14, 2015 at 6:20 PM, Adam Baso <abaso(a)wikimedia.org> wrote:
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
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
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
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 (&
* Cataloging features by channel in some sort of matrix, and delivering
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
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.
Mobile-l mailing list