Hi Erik,

Thanks for sharing this update. It looks like a move in a good direction for 
WMF's engineering.

I am worried by how short-term the current plans/goals are, though. I know that 
a lot of work that the engineering department does, particularly with regards 
software, which can only be planned on a quarterly basis to ensure it's as 
agile and responsive to changing needs as possible. However, there's also the 
long-term view - what the key pieces of work that department wants to get done 
over the course of the next year or longer are - which is currently missing. I 
think this is particularly important for the engineering side of things 
(expected server capacity needs etc.), but it's also relevant for the software 
development side in terms of the larger picture.

Is there a wikipage available somewhere that sets out the long-term 
view/strategic priorities for the engineering department? If not, could I 
encourage you to think about starting one?

Thanks,
Mike

On 27 Jun 2014, at 02:55, Erik Moeller <e...@wikimedia.org> wrote:

> As an update on the goals process for WMF engineering, we've begun
> fleshing out out the top priorities for the first quarter. Going
> forward, we'll aim to call out the top priorities for each quarter as
> we approach it, to create more shared visibility into the most urgent
> and high-impact projects we're working on.
> 
> I've decided for now to use a division between "User-Impacting
> Changes" and "Cross-Functional Platform and Process Improvements". The
> intent of calling out both areas is to ensure that important
> organizational priorities don't fall off our collective radar. At the
> management level, the intent is for us to pay special attention to the
> priorities called out in this manner, and this may also impact our
> willingness to request help from across the organization if necessary
> to support these priorities, at least in Q1.
> 
> I've merged the current draft into the goals document, here:
> https://www.mediawiki.org/wiki/Wikimedia_Engineering/2014-15_Goals#Top_departmental_priorities_for_Q1_.28July_-_September_2014.29
> 
> Once again, this is draft and marked as such. The "Impact" column will
> include links to relevant metrics once those are a bit more solid; if
> you look further down in the document you'll see that these are being
> refined and tweaked in multiple areas right now.
> 
> A little bit of rationale for some items that may surprise you:
> 
> - I've decided to list HHVM as the top priority in both categories.
> This is because a) it's a very complex undertaking from an engineering
> perspective and requires significant coordination across development &
> operations, b) it's probably the biggest change regarding how code
> gets executed in production since we adopted PHP in the first place,
> c) the expected performance benefits for many uncached logged-in user
> operations are very significant (I defer to the team to quantify
> before throwing out estimates).
> 
> This is also indicative of the importance we're attaching to site
> performance. There's no question that performance is directly
> correlated with user engagement, and it's appropriate that we spend
> significant effort in this area.
> 
> - We're elevating SUL finalisation (
> https://www.mediawiki.org/wiki/SUL_finalisation ) to a top priority,
> and I've classified it as user-impacting. This is because it's on the
> critical path for making it easier to develop cross-site functionality
> (as long as we have to deal with the edge case of "detached accounts",
> certain features that work across wikis are just trickier to
> implement), and one of those long term issues of technical debt we've
> been kicking down the road for years. It's also a pretty complex
> project -- if it goes wrong and we mess up our account database, we're
> in big trouble. So we want to make sure we have lots of eyeballs on
> this from a technical and community management perspective. We may not
> completely wrap up in Q1 since we need to give users whose accounts
> are affected significant warning time, which is just elapsed time we
> can't shorten.
> 
> - Front-end code standardization is called out as a top priority. We
> really need to dig ourselves out of the mess of having disjointed
> templating systems, widget libraries, and JS frameworks across our
> codebase if we want to increase development velocity and UX
> consistency. I'm prepared to sacrifice short term development velocity
> on other projects in order to make this happen.
> 
> - The content API that Gabriel is working on (
> https://www.mediawiki.org/wiki/Requests_for_comment/Content_API ) is
> called out as a top priority. This is because the Parsoid output (for
> which the content API will be a high performance front-end) is now
> getting to the point where it's starting to become plausible to
> increasingly use it not just for VisualEditor, but also for views as
> well. The potential here are performance benefits across the board:
> for logged-in users in general by consistently relying on fast, cached
> output; for users loading VisualEditor by giving them most of the
> payload required to edit in read mode; for users saving through
> VisualEditor by potentially turning the wikitext transformation into a
> post-save asynchronous process and thereby making saves near
> instantaneous.
> 
> Moreover, it will put us on the long term path towards possibly using
> HTML5 as MediaWiki's native format, supporting HTML5-only wikis, and
> more. And it will be valuable for third party re-use and re-processing
> of Wikimedia content for a multitude of use cases. Last but not least,
> it's also a great use case for a service-oriented architecture
> including REST APIs & good/clean API documentation.
> 
> In short, this is a big deal, and it has lots and lots of
> architectural implications -- so raising the visibility on this is
> intended to get more people to actually think through what all of this
> means for the future of MediaWiki.
> 
> Other elements of the prioritization shouldn't be surprising:
> Phabricator is a big deal, and it's coming; Mobile (including new
> contributory features) and VE (including a really awesome new
> citations experience we're prepping for) continue to be high on the
> agenda, and we need to standardize and improve our quantitative
> measures across the board. Growth is going to work on new user
> acquisition in Q1 which didn't quite make the cut for the top 5
> because it's not as broadly impacting as some of the other things
> listed here, but still a big deal -- as are other things not called
> out here. The intent isn't to demote anyone's work, but to give
> ourselves shared awareness of some of the most mission-critical things
> that are going on.
> 
> If you do feel the prioritization is off, leave a note on the talk
> page. It's still draft and we reserve the right to correct and adjust
> as we learn things, but we'll wrap the Q1 prioritization by July 1.
> 
> Thanks!
> 
> Erik
> -- 
> Erik Möller
> VP of Engineering and Product Development, Wikimedia Foundation
> 
> _______________________________________________
> Wikimedia-l mailing list, guidelines at: 
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> Wikimedia-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
> <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>


_______________________________________________
Wikimedia-l mailing list, guidelines at: 
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>

Reply via email to