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.

Code of Conduct / Online Behavior / Dev Privileges
How do we structure online conversations?
 * Mailing lists
 * BZ
 * IRC
 * Gerrit

of mind that may not be there without. maybe we could replicate this into our other communities. to publicly and loudly.
 * brandon: Need something concrete to look at and say "No, you have screwed up." Ability to look at it and say that someone crossed the line, as opposed to a fuzzy, subjective line.
 * Trevor: Who makes the decisions?
 * sumana: MW core merge group. Makes sense, because they're the leaders of the community.
 * ariel: But if someone in that group is crossing the line, we have trouble.
 * guillom: Maybe those people don't want the responsibility, either
 * JamesF: And technical leaders don't necessarily make good leaders in this respect.
 * sumana: Well, and I'm willing to communicate the response of the "council"
 * asheesh: Not necessarily good to have people who select themselves to have power.
 * brandon: Everyone needs to be able and willing to step up and say "you're being a jerk"
 * sumana: But that feeds the flame wars rather than extinguishing them?
 * rob: "You're out of line" almost always leads to meta conversations about conduct....
 * RoanKattouw: Distinguish between telling someone that they're out of line and actually taking action against them. Very little precedent. If we had a policy, that would be good.
 * sumana: Need to talk to the community, but is there any opposition to even having a code?
 * Quim, JamesF, and Trevor at least somewhat opposed:
 * Quim: Confrontation happens. It's OK. But ending the conversation is not good.
 * JamesF: We're really good at being jerks. The rules on enwiki are bad. Because they're too much. Writing it down doesn't add value, so we just need people to use their common sense to take action.
 * sumana: I agree, but we need to consider that having a code of conduct will give others some peace
 * Trevor: It's scary to have too many rules. But having a few rules might be OK.
 * sumana: Maybe having people, who are admins, simply extend their power to conduct.
 * Chad: Careful to talk as a community member, not as an employee.
 * brandon: Admins on enwiki may mark themselves as willing to take the heat for a decision, and
 * guillom: Maybe better to talk to this person privately or on IRC about their conduct, as opposed
 * brandon: Dangerous to do things privately, though, because it may mean that nobody will do it.