Talk:Wikimedia engineering 20% policy/Flow

Previous page history was archived for backup purposes at Talk:Wikimedia engineering 20% policy/LQT Archive 1 on 2015-07-11.

This is my idea for replacing 20% time with a new program for WMF engineers. It's called LevelUp.

• It's quarterly, not weekly
• It permanently increases our community code review capacity
• It grows you as a technical leader

Plan:

Starting in 2013, every engineer or sysadmin at WMF has a quarterly goal: either to get more domain knowledge on a particular repo/codebase and become a regular code reviewer on that codebase, or to coach a particular mentee to get +2 privileges on a repo. So, some WMFers coach other WMFers, and some coach volunteers. Sumana helps matchmake and find volunteers (including via programs like Google Summer of Code and the Outreach Program for Women), and your manager checks in with you about your progress during your regular one-on-one or status meetings.

To inform this, we're creating a table of who knows the most about all the components of Wikimedia's codebase and infrastructure, including MediaWiki core, extensions, and our server architecture. As it grows, this table will highlight the extension update frequency, number of high-priority open bugs, and potential new maintainers (including recent committers) and mentors.

You can learn by reviewing code and hacking with your mentor, and you can teach by metareviewing your mentee's code reviews, pair programming, and so on.

I predict that, at the end of 1 quarter of this, our code review backlog will be about the same as it is now (statistics). But after 2 quarters, it'll go down, because we'll have more confident reviewers and maintainers. And you'll benefit because you won't have to wait as long to get your changesets reviewed.

Opting out

If you prefer to opt out of LevelUp, you can simply spend 1 day a week doing design and code review for new extensions, fixing bugs that affect everyone, increasing test coverage, or something else that helps the whole community. But we'll request that you concentrate on parts of our infrastructure that currently aren't getting much love, as indicated in the maintainership table.

I like this idea, of course.

Currently the most experience engineers may review the oldest and most neglected code, but there is no mechanism for their actions apply to anything more than the bugzilla patch or gerrit change itself. A lot of knowledge gets sent in a one-off.

The focus on code review should be on increasing capacity in a manner that is sustainable, not in assigning people to do something they may or may not like simply because they are the only one who knows it. Creating a system where people pay their skills forward like LevelUp is one such mechanism which can hopefully allow us to repeat and be a "force multiplier" where work done serves more than one purpose.

One consideration should be mentioned. Usually engineers find it invaluable when their code is being audited during mentorship. The reason why is they are already familiar with its ins-and-outs so the act of review gives them new things to look out for, gives them a place to hang the new found knowledge, and they adequately arguing the opposing case from the perspective of reviewee gives them the empathy to see the frustrations our community of developers has with our current process. Hopefully that will be a component as part of this process.

Great, thanks. OK, the updated policy is at Mentorship programs/LevelUp.