[Wikitech-l] Fwd: [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
Meant to CC Wikitech-l too... -- Forwarded message -- From: Tilman Bayer tba...@wikimedia.org Date: Wed, Jun 25, 2014 at 8:37 AM Subject: Re: [Wikimedia-l] Quarterly reviews of high priority WMF initiatives To: Wikimedia Mailing List wikimedi...@lists.wikimedia.org Minutes and slides from last Friday's quarterly review of the Foundation's Parsoid team are now available at https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews/Parsoid/June_2014 . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller e...@wikimedia.org wrote: Hi folks, to increase accountability and create more opportunities for course corrections and resourcing adjustments as necessary, Sue's asked me and Howie Fung to set up a quarterly project evaluation process, starting with our highest priority initiatives. These are, according to Sue's narrowing focus recommendations which were approved by the Board [1]: - Visual Editor - Mobile (mobile contributions + Wikipedia Zero) - Editor Engagement (also known as the E2 and E3 teams) - Funds Dissemination Committe and expanded grant-making capacity I'm proposing the following initial schedule: January: - Editor Engagement Experiments February: - Visual Editor - Mobile (Contribs + Zero) March: - Editor Engagement Features (Echo, Flow projects) - Funds Dissemination Committee We’ll try doing this on the same day or adjacent to the monthly metrics meetings [2], since the team(s) will give a presentation on their recent progress, which will help set some context that would otherwise need to be covered in the quarterly review itself. This will also create open opportunities for feedback and questions. My goal is to do this in a manner where even though the quarterly review meetings themselves are internal, the outcomes are captured as meeting minutes and shared publicly, which is why I'm starting this discussion on a public list as well. I've created a wiki page here which we can use to discuss the concept further: https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_reviews The internal review will, at minimum, include: Sue Gardner myself Howie Fung Team members and relevant director(s) Designated minute-taker So for example, for Visual Editor, the review team would be the Visual Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. I imagine the structure of the review roughly as follows, with a duration of about 2 1/2 hours divided into 25-30 minute blocks: - Brief team intro and recap of team's activities through the quarter, compared with goals - Drill into goals and targets: Did we achieve what we said we would? - Review of challenges, blockers and successes - Discussion of proposed changes (e.g. resourcing, targets) and other action items - Buffer time, debriefing Once again, the primary purpose of these reviews is to create improved structures for internal accountability, escalation points in cases where serious changes are necessary, and transparency to the world. In addition to these priority initiatives, my recommendation would be to conduct quarterly reviews for any activity that requires more than a set amount of resources (people/dollars). These additional reviews may however be conducted in a more lightweight manner and internally to the departments. We’re slowly getting into that habit in engineering. As we pilot this process, the format of the high priority reviews can help inform and support reviews across the organization. Feedback and questions are appreciated. All best, Erik [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikimedia-l mailing list wikimedi...@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
OK, so really the process that we need here is: 1) Get more people on the security team via NDA and whatnot (sign me up, by the way, obviously) 2) Develop a triage system to quickly investigate and handle invalid and duplicate bugs 3) Determine when and how we’re going to do the program 4) Do it. -- Tyler Romeo 0xC86B42DF From: Brian Wolff bawo...@gmail.com Reply: Wikimedia developers wikitech-l@lists.wikimedia.org Date: June 26, 2014 at 0:34:54 To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] MediaWiki Bug Bounty Program On 6/26/14, Chris Steipp cste...@wikimedia.org wrote: On Wed, Jun 25, 2014 at 5:49 PM, Alex Monk kren...@gmail.com wrote: Chris, why don't we leave privacy policy compliance to the users posting on the bug? Wikimedia personal user data shouldn't be going to the security product. There are a few cases where there may be legitimate private data in a security bug (look, sql injection, and here are some rows from the user table!, Hey, this was supposed to be suppressed, and I can see it, This user circumvented the block on this IP). But there might be ways to flag or categorize a report as also including private data? Someone with more bugzilla experience would need to comment. Why does WMF get the right to control by access to MediaWiki security bugs anyway? Could we not simply host MediaWiki stuff externally? Perhaps on the servers of any other major MediaWiki user. This certainly could be done. That other major MediaWiki user would have to be someone everyone trusts, and preferably with a strong track record of being able to keep their infrastructure secure. If there's a legitimate proposal to try it, let's definitely discuss. Personally I'd prefer that MediaWiki related support software stay hosted by WMF (at least for the foreseeable future). WMF just seems like the logical people to host it, and I don't see any harm in MediaWiki being a Wikimedia project in a similar sense as wikipedia is a Wikimedia project. What I would like to see though is a mediawiki world where WMF is not special. What I mean by that is that being a WMF employee/contractor wouldn't get you any special treatment - trusted people would get special access where needed because they're trusted and have demonstrated their competence. A WMF staffer would have to go through the same procedure as anyone else would have to to get any sort of special access. Much of the people who have special access would still be WMF employees, since WMF employs most senior developers, but it wouldn't be you're a wmf employee = here's access to everything even if you don't need it, you're not a WMF employee = have to jump through a million hoops plus sign something in blood plus bribe someone to get access to things that would be extremely helpful to your work. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l signature.asc Description: Message signed with OpenPGP using AMPGpg ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
Tyler Romeo wrote: OK, so really the process that we need here is: 1) Get more people on the security team via NDA and whatnot (sign me up, by the way, obviously) Any process that involves volunteers signing non-public, indefinite vows of secrecy and silence are antithetical to Wikimedia's values and mission. This isn't a cult. Our bedrock principles are open access and transparency. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
On Thu, Jun 26, 2014 at 12:33 AM, Brian Wolff bawo...@gmail.com wrote: What I mean by that is that being a WMF employee/contractor wouldn't get you any special treatment - trusted people would get special access where needed because they're trusted and have demonstrated their competence. A WMF staffer would have to go through the same procedure as anyone else would have to to get any sort of special access. Much of the people who have special access would still be WMF employees, since WMF employs most senior developers, but it wouldn't be you're a wmf employee = here's access to everything even if you don't need it, you're not a WMF employee = have to jump through a million hoops plus sign something in blood plus bribe someone to get access to things that would be extremely helpful to your work. Note this is my own personal view as a WMF software developer, and not any sort of official statement. The situation already isn't you're a wmf employee = here's access to everything even if you don't need it. For example, for a good while after I was hired I didn't have access to security bugs. Eventually there were enough hey, look at this sure, CC me so I can see it? conversations that we realized I should be given the access. There's a security IRC channel (existence of which is publicly acknowledged), which again you need a reason better than WMF pays me to get access to. Or consider root access to anything outside of a few labs projects: I don't have it and if I were to ask for it there'd be a discussion that I'm sure would rightly conclude that I don't need it. Probably an extremely short discussion. And don't forget that at least some of the hoops to jump through (e.g. demonstration of competence, NDA, idenfitication, privacy policy agreement) is also part of being hired in the first place. It's like how international travel is easier for someone who already has their passport than for someone who needs to get one. +2 for example is this way: Getting hired as a developer usually gets +2 on the repos that you've been hired to work on, yes. But if you can't convince the hiring managers that you are competent, can contribute high quality patches, and have good judgment in knowing when to merge something (i.e. the sort of things that are listed at [[mw:Gerrit/+2#Granting]] for community members), why are they going to hire you? -- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
On Jun 26, 2014 9:44 AM, MZMcBride z...@mzmcbride.com wrote: Any process that involves volunteers signing non-public, indefinite vows of secrecy and silence are antithetical to Wikimedia's values and mission. This isn't a cult. Our bedrock principles are open access and transparency. To clarify, I think Max wants more docs listed at https://meta.wikimedia.org/wiki/Non-disclosure_agreements Maybe Max is unaware about https://wikitech.wikimedia.org/wiki/Volunteer_NDA -Jeremy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
I’ll be frank. I care a lot more about the security of MediaWiki as a software product, as well as the security of its customers (both WMF and third-party) than I do about some made-up notion of “open access” to security bugs. I think it makes complete sense to have people with access to security bugs sign an agreement saying they will not release said bugs to the public until they have been fixed, released, and announced properly. -- Tyler Romeo 0xC86B42DF From: MZMcBride z...@mzmcbride.com Reply: Wikimedia developers wikitech-l@lists.wikimedia.org Date: June 26, 2014 at 9:44:25 To: Wikimedia developers wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] MediaWiki Bug Bounty Program Any process that involves volunteers signing non-public, indefinite vows of secrecy and silence are antithetical to Wikimedia's values and mission. This isn't a cult. Our bedrock principles are open access and transparency. signature.asc Description: Message signed with OpenPGP using AMPGpg ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
As a third-party user: I completely concur. NDAs for security bug access are pretty much standard, aren't they? - d. On 26 June 2014 15:08, Tyler Romeo tylerro...@gmail.com wrote: I’ll be frank. I care a lot more about the security of MediaWiki as a software product, as well as the security of its customers (both WMF and third-party) than I do about some made-up notion of “open access” to security bugs. I think it makes complete sense to have people with access to security bugs sign an agreement saying they will not release said bugs to the public until they have been fixed, released, and announced properly. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
I feel like this would result in a ton of reports that say YOU CAN DEFACE THE MAIN PAGE!!! which is editable, if not protected, because it's a wiki. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
A general and boring explanation on how access restrictions are handled/configured in Bugzilla currently. No opinions involved. On Wed, 2014-06-25 at 21:18 -0700, Chris Steipp wrote: There are a few cases where there may be legitimate private data in a security bug (look, sql injection, and here are some rows from the user table!, Hey, this was supposed to be suppressed, and I can see it, This user circumvented the block on this IP). But there might be ways to flag or categorize a report as also including private data? Someone with more bugzilla experience would need to comment. I'm not aware of any standardized way to do this. Current practice is described in item 2 below. In general, Bugzilla offers two things: 1) Access restriction to all tickets in a certain product by default (like all tickets under Security). Only Bugzilla admins, members of the security group, the bug reporter, and people explicitly CC'ed on such a ticket can access such a ticket in such a product. 2) Separate from that, marking both attachments and specific comments in a ticket as private. It's configured that it can be set and seen by Bugzilla admins and members of the security group. There is a practice (tradition?) to set the 'private' flag if somebody finds or notifies about private data exposed (IPs, passwords, SSIDs), insults / personal attacks, or spam. We don't have an explicit policy defined for setting that flag. A while ago I was told that people who by default have access to Security tickets in Bugzlla need to have an NDA [1] in place. andre [1] https://en.wikipedia.org/wiki/Non-disclosure_agreement -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] dumps.wikimedia.org, downloads.wikimedia.org downtime Thursday June 26 13.30 UTC
Στις 23-06-2014, ημέρα Δευ, και ώρα 20:56 +0300, ο/η Ariel T. Glenn έγραψε: dumps.wikimedia.org, downloads.wikimedia.org will be down on Thursday June 26 from 13.30 UTC until 14.30 UTC. While we expect the actual downtime to be much less, we're blocking one hour just in case. And Murphy has spoken. The server is being finicky about coming back up, so we're over the window. Apologies and I'll update as soon as we have more information. Ariel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
On Thu, 2014-06-26 at 16:17 +0200, Bartosz Dziewoński wrote: I feel like this would result in a ton of reports that say YOU CAN DEFACE THE MAIN PAGE!!! which is editable, if not protected, because it's a wiki. This. I have seen several 'bug reports' in Mozilla Bugzilla by 'security researchers' about source code of projects being exposed on Mozilla's servers. Clearly a security breach. What does FOSS stand for? So it boils down to how to keep clueless people out, to be rough. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
On 06/26/2014 10:15 AM, David Gerard wrote: NDAs for security bug access are pretty much standard, aren't they? I don't know about standard but they are certainly common in cases where said software has a large installed base and early disclosure of a vulnerability would place them at risk without being able to protect themselves. It's not about avoidance of being transparent but to give a bit of protection to third parties - note how fixed security issues are moved from security back to their real components when being closed. -- Marc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
On Thu, Jun 26, 2014 at 8:03 AM, Andre Klapper aklap...@wikimedia.org wrote: On Thu, 2014-06-26 at 16:17 +0200, Bartosz Dziewoński wrote: I feel like this would result in a ton of reports that say YOU CAN DEFACE THE MAIN PAGE!!! which is editable, if not protected, because it's a wiki. This. I have seen several 'bug reports' in Mozilla Bugzilla by 'security researchers' about source code of projects being exposed on Mozilla's servers. Clearly a security breach. What does FOSS stand for? So it boils down to how to keep clueless people out, to be rough. Heck, we get it to security@ pretty often. Just had one a few weeks ago saying If I append a ?title=foo param it changes the page title! -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
On 26 June 2014 15:02, Jeremy Baron jer...@tuxmachine.com wrote: On Jun 26, 2014 9:44 AM, MZMcBride z...@mzmcbride.com wrote: Any process that involves volunteers signing non-public, indefinite vows of secrecy and silence are antithetical to Wikimedia's values and mission. This isn't a cult. Our bedrock principles are open access and transparency. To clarify, I think Max wants more docs listed at https://meta.wikimedia.org/wiki/Non-disclosure_agreements Maybe Max is unaware about https://wikitech.wikimedia.org/wiki/Volunteer_NDA I wouldn't be surprised. I've never seen this page before and, according to the history, it was only created a week ago. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] dumps.wikimedia.org, downloads.wikimedia.org downtime Thursday June 26 13.30 UTC
Στις 26-06-2014, ημέρα Πεμ, και ώρα 17:37 +0300, ο/η Ariel T. Glenn έγραψε: Στις 23-06-2014, ημέρα Δευ, και ώρα 20:56 +0300, ο/η Ariel T. Glenn έγραψε: dumps.wikimedia.org, downloads.wikimedia.org will be down on Thursday June 26 from 13.30 UTC until 14.30 UTC. While we expect the actual downtime to be much less, we're blocking one hour just in case. That was the longest one hour window I've ever taken part in. But it's over, the dumps are back on line and everything should be functioning normally. After this last round of dumps that were interrupted catches up in a couple of days, I'll be tweaking the bandwidth cap for downloaders. Ariel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Extension Jenkins now use update.php --schema to log SQL
Hello, Earlier today I slightly changed how Jenkins run the MediaWiki extension job. Specifically the way the database is updated. We used to simply: php maintenance/update.php I wanted to log the SQL queries behind added to the database and the script has a --schema option to do just that. So Jenkins now: php maintenance/update.php --schema update_sql.log sleep 1 php maintenance/update.php The sleep is needed because --schema still write to the update_log database. The two runs ends up having the same ul_key in the table since it just vary by timestamp (so if two run occurs in the same second, the second has a duplicate key error). There should be a better fix, but sleep 1 works ™ Flow had an issue with the tests failing because --schema still run the post-db maintenance script (might be the cause of above problem). Erik Bernhardson figured out a temporary workaround for Flow: https://gerrit.wikimedia.org/r/#/c/142303/ The issue is tracked by https://bugzilla.wikimedia.org/67163 Any help welcome! -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
Marc A. Pelletier wrote: On 06/26/2014 10:15 AM, David Gerard wrote: NDAs for security bug access are pretty much standard, aren't they? I don't know about standard but they are certainly common in cases where said software has a large installed base and early disclosure of a vulnerability would place them at risk without being able to protect themselves. It's not about avoidance of being transparent but to give a bit of protection to third parties - note how fixed security issues are moved from security back to their real components when being closed. If you know of any non-disclosure agreements for large, open-source projects, it'd be interesting and helpful to collect a list of links to them for reference. If they're standard/common, it shouldn't be too difficult to find a lot of examples to look over and learn from. A very brief search turned up https://wiki.mozilla.org/Legal/Confidential_Information, which outlines some of the issues that Wikimedia similarly faces with respect to non-disclosure agreements and volunteers. Jeremy Baron wrote: Maybe Max is unaware about https://wikitech.wikimedia.org/wiki/Volunteer_NDA Err, thanks for the link. As pointed out, that page is less than a week old and had not been advertised or linked from anywhere, as far as I can tell. I don't think there's a reasonable expectation that anybody would have known about it. I'm also not sure any volunteer is following that page... i.e., I'm not sure it's active or authoritative (yet?). MZMcBride P.S. Who's Max? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] MediaWiki Bug Bounty Program
On Thu, Jun 26, 2014 at 12:57 PM, MZMcBride z...@mzmcbride.com wrote: Jeremy Baron wrote: Maybe Max is unaware about https://wikitech.wikimedia.org/wiki/Volunteer_NDA Err, thanks for the link. As pointed out, that page is less than a week old and had not been advertised or linked from anywhere, as far as I can tell. I don't think there's a reasonable expectation that anybody would have known about it. I'm also not sure any volunteer is following that page... i.e., I'm not sure it's active or authoritative (yet?). Yeah, it's not authoritative yet - we're still figuring out the kinks. Luis -- Luis Villa Deputy General Counsel Wikimedia Foundation 415.839.6885 ext. 6810 *This message may be confidential or legally privileged. If you have received it by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia Foundation, for legal/ethical reasons I cannot give legal advice to, or serve as a lawyer for, community members, volunteers, or staff members in their personal capacity. For more on what this means, please see our legal disclaimer https://meta.wikimedia.org/wiki/Wikimedia_Legal_Disclaimer.* ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension Jenkins now use update.php --schema to log SQL
Le 26/06/2014 21:51, Antoine Musso a écrit : Erik Bernhardson figured out a temporary workaround for Flow: https://gerrit.wikimedia.org/r/#/c/142303/ The issue is tracked by https://bugzilla.wikimedia.org/67163 Hello, I have commented out the update.php --schema call for now. Ie reverted the feature. https://gerrit.wikimedia.org/r/142386 -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] First _draft_ goals for WMF engineering/product
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
