just a quick big picture update:
1) In general, as you may have noticed, Danese has hired Engineering
Program Managers. This is a standard way in growing tech organizations
to manage, organize and communicate technology projects. The current
Rob Lanphier - general core engineering (MediaWiki core, API, code
review, QA, etc.)
Alolita Sharma - features/product engineering
Tomasz Finc - fundraising, mobile/offline
Guillaume Paumier is currently doing both product planning and some
EPM work for the multimedia usability project.
This has led to much-improved internal planning and organization of
WMF's technical projects, and as you've probably seen, a solid general
update and documentation of the engineering projects that are
If you want to keep up with hiring of staff and contractors, there's
now also a new Twitter feed: http://twitter.com/wikimediaatwork
2) My role is shifting to helping articulate our overall product
development strategy and research, meaning to synthesize input from
many different sources (community, other departments, researchers,
etc.) that helps inform our decision as to which projects we either
want to build or prioritize. That includes questions such as "Let's
take this existing MediaWiki extension and help review it and whip it
into shape". To support this work, I will work with one strategically
oriented Senior Product Manager (Howie Fung) and a Senior Research
Analyst (currently posted).
This, of course, will be primarily relevant to projects we're directly
paying for, but also to some extent the kinds of meetings and the
types of volunteer projects we'll facilitate and try to actively
generate interest in. Ultimately, volunteer developers invest time in
projects they care about, but we do not guarantee that every MediaWiki
extension will be reviewed, improved or deployed by WMF staff
engineers, irrespective of whether there's a large amount of community
interest in it or not. (For example, there might be large interest in
a feature that's prohibitively complex, or poorly thought out, or very
Indeed, I don't believe in an approach that only relies on user
ratings or votes, rather, priorities should be set based on the
overall impact on our strategic objectives that any planned project
(technology or not) is going to have. Is it going to help our editor
community be more effective? Is it going to help us reach more people?
Is it going to drive the overall quality of the content? Is it going
to support reaching disadvantaged or underrepresented communities?
That said, that doesn't mean that a process can't be open and
consultative. I invite you to look at the (permanently open) Call for
Proposals on StrategyWiki, and the special extension that's used to
show a dashboard of particularly active or interesting proposals: http://strategy.wikimedia.org/wiki/Main_Page
I hope to help kick this process back into gear a little bit, and
improve upon it, as a way to solicit more extensive and carefully
thought-out proposals than what typically finds its way into Bugzilla.
(And I agree that Bugzilla is a great tool, especially for smaller
Together with Danese, the EPM team, and others, we will aim to make
WMF's decisions transparent and understandable. When Danese writes
about "making code review more transparent", this is a big part of
what she's talking about -- the entire process of deciding, for
example, that a community-developed software extension is being
reviewed, deployed, and possibly even integrated into MediaWiki core.
So we do want to be clear _why_ something happens, even if you might
disagree with the reasons.
Last but not least, please bear with us, as we're a) still a small
team, b) still generally professionalizing and maturing our
engineering practices, c) in active growth and transition mode,
meaning we have to absorb and orient lots of new people. We're all
here to help Wikimedia succeed, and we appreciate patience, kindness,
good faith and good humor in working together.
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Wikitech-l mailing list