Wikimedia Engineering/WMF Tech Days 2012/Down with twenty percent

Replacing 20 % Time (and maintainership)

New term: "Level Up". Everybody in WMF eng. will level up, or help someone else level up. Do not has gerrit project ownership? Get it. Work on things that have very few people who can help. Design review, project management, and so on. Sumana to help matchmake between mentors and mentats, etc. Near term: This will hurt. Code review backlog should be worse after a quarter. But, those new people will be able to review more and more, and get better at reviewing. After two quarters of this, we should be getting serious benefits.

• Bigger, stronger community
• Smaller backlog
• Less boring shit for us to do

• adam wight: What structure?
• sumana: Open to suggestions. It's just a quarterly goal, and Sumana would help with matchmaking. Weekly meeting with supervisor? (entire room giggles) Quarterly checkin with Sumana?
• sumana: Replacing 20% time, so no *mandatory* interruption, but you get to help the community and don't have complex switching all the time.
• RoanKattouw: Code review backlog may go up, how can we avoid that?
• Rob: Can ask people to bear with us until we get things figured out.
• sumana: People who have ownership and do code review are overburdened. 20% time doesn't fit with workflow, and may not solve the problem.
• terry: You're also being told what to do, as opposed to picking your own projects (which may be better)
• sumana: And 20% time for mentorship and so on may be much more rewarding, so we have that to look forward to. Plus, code review seems like a chore, which is just never good.
• RoanKattouw: At first, many people with different skills could be applied to code review where no such person already existed, but were in other projects. We instituted 20% time to steal those people. We may still need to do that, but not in all cases.
• sumana: Shouldn't focus on numbers. Focus on goals instead.
• Rob: Original motivation is this: There are _so_ many review requests. So let's put a limit on it. 20% seemed like a pretty good limit, allowing a bunch of work on other things as well.
• sumana: Coming in, this is a good way to grow and help others grow.
• sumana: Example: Arthur has commit access to mediawiki/core. Maybe there's someone out there who could work with him on a specific thing. He may not feel comfortable reviewing core, though. So he may be happy to get mentoring. He feels better about MobileFrontend.
• arthur: This is already happening internally, as well, but the only change would be A) remove 20% time and B) we would do it with volunteers as well.
• RoanKattouw: Internal mentoring happens inside of teams. But if you're no longer on a team, you could still mentor for that project!
• terry: Not only cross-pollenation, but also to empower others to add to the system, not just be part of it. It would be great to have more and better code reviewers soon.
• gabriel: How would you measure success of this program?
• sumana: In January, we say "did you meet the goal(s) you set?" Defined by employees and managers, not by anyone else.
• Rob: No 20% time => 2000 unreviewed patches. What the hell should we do? Maybe we can make it last a shorter amount of time? Maybe we should look at it in terms of backlog? If we have over X number of unreviewed revisions, we could just emergency-review it.
• Trevor: We're only talking about one solution, can we talk about others?
  • Assign areas of code, specific features, to people, and requiring them to code review that area. Also, with any time they have left, they can set goals for improvements to that code, rather than only responding to others changing it.
• subbu: People could simply say that they're interested in X, and then if someone needs help in that thing, they can ask.
• sumana: So it would be more voluntary.
• siebrand: That doesn't work.
• sumana: Need to create a list of parts of the ecosystem that need help.
• subbu: And who's interested in what. (which is harder)
• sumana: There's also other measures, like extension update frequency and so on. But code review is relatively easy to measure.
• maxsem: Who's the maintainer? Lots of people assume the author. Well, not helpful.
• sumana: Right, and you should look for recent committers and mergers. That's more helpful.
• arthur: But we could combine two approaches pretty simply. Having a list makes sense, and having LevelUp(TM) makes sense.
• RoanKattouw: Having more specific goals seems like one of the best benefits. Could be aware of the problems when setting goals. And goals can be like "cut down the backlog of review".
• At first, we'll be pretty under-covered. But it will get better.
• JamesF: Agreed, the most common committer recently can get the responsibility at first and then move on later.
• sumana: Possible approaches:
  • Increase how much we care about particular chunks.
  • LevelUp(TM) as a quarterly goal
  • Lowering our standards
  • Social pressure (PSAs)
  • Core review team (dedicated)
  • Getting more community members to have responsibilities

  Many of these could work together. And it's not only code review.

• RoanKattouw: "Ops Monkey" - forced to be on IRC all the time, and basically "picked up pieces", so doing busywork. Triaging, etc. But in code, it's hard to get people to take a week off.
• Alolita: Would we lose components? (sumana) Yes, probably (Alolita) OK, so what happens?
• sumana: Well, nothing. That's the end of it. Offer possibilities for volunteers, maybe. There may be trouble with already-backlogged extensions, but if we can fix it somehow, we should try.
• TimStarling: ParserFunctions, for example. It's been the same for a long time. But pretty much, it just works. Until you write something new.
• Trevor: Realistic to do both, maybe per-engineer. Some like 20% more than LevelUp.
• RoanKattouw: Some people like Roan and Timo enjoy code review more, so maybe they should be into the system, and others should be pulled out and into LevelUp.
• guillom: Much better to do both at once, rather than jumping in.
• sumana: Will talk to others, read notes, come up with a better idea that will work better than 20% time. In near future, continue with status quo.