Once upon a time there was 20% time, which had various problems and we thus ended[0] and turned into LevelUp[1]. The point is to increase our capacity to do engineering, broadly defined. LevelUp has had various problems and so I have some ideas about what to do next, but I want to open a bit of discussion first to make sure I'm getting the problems right. I'll wind up this discussion late on Tuesday the 16th, I hope, and get the new programs in motion by the end of that week.
Problems/unmet needs:
a. People in our technical community (volunteers, WMF, WMDE, and others) want to be more effective but aren't consistently getting what they need. Sometimes that's code/design review, sometimes that's looking over someone's shoulder to learn by example, sometimes it's tutoring, sometimes it's a project guided to completion, sometimes it's simply learning what resources, guidelines, and tools are available, and sometimes it's HOWTOs, reference guides, inventories, and directories. We get glimpses of this when I ask what people want to learn; see [0] and the 2013 Jan-March LevelUp signups[2]. Different people learn in different ways[3] so there is no one-size-fits-all solution.
b. Code review backlog. Per (a) this is keeping tech contributors from learning -- it's also important that it keeps improvements from reaching users. And it's just dispiriting; the number of unresolved commits in mediawiki/* has gone from ~360 to ~815 in the last 6 months[4][5], and most of the "can we deploy this?" queues haven't moved in a few months.[6][7]
c. Some people say they want to mentor or be mentored but then do not perform teaching or learning activities unless a meta-mentor prods them several times a month, or do not set reasonable goals. The plan for LevelUp was that people's managers would check on progress. Thus LevelUp in the most recent round did not lead to most participants meeting their goals. OPW and to a lesser extent GSoC and UCOSP seem to work partly because there's a pre-qualification process including goal-setting, partly because the student and mentor strongly commit to carving out time, and partly because my team does strong hands-on meta-mentorship.
d. Some WMF engineering contributors want to help increase our community's capacity via individual mentoring or learning. Some want to just review code and design. Some want to create and lead teaching sessions. Some feel as though they haven't been allotted the time to do any of this kind of work.
e. Related to (a) and (d), we have frustrating bottlenecks in our capacity for some key engineering activities, *especially* user experience design, community liaising, performance, front-end (especially JS) coding and review, ResourceLoader, and operations work. These affect everyone but hit volunteers disproportionately.
f. I have to rename LevelUp because of the name conflict with some company. I can come up with a suitable name for whatever the next thing is, don't worry, no bikeshedding necessary here, but I just wanted to mention it.[8]
Do these seem like the right problems to address in trying to build our community's capacity for technical contributions? Was there anything you liked about 20% time or LevelUp that you want to retain? I am especially interested in what you have to say if you rarely speak up on this list, and it is okay to email me off-list.
[0] http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064615.html
[1] https://www.mediawiki.org/wiki/Mentorship_programs/LevelUp
[2] https://www.mediawiki.org/wiki/Mentorship_programs/LevelUp/Q1_2013
[3] https://blogs.msdn.com/b/susantodd/archive/2011/05/06/quot-people-in-context...
[4] https://blog.wikimedia.org/2012/10/03/engineering-september-2012-report/
[5] https://blog.wikimedia.org/2013/04/04/engineering-march-2013-report/
[6] https://www.mediawiki.org/wiki/Review_queue#Extensions
[7] https://www.mediawiki.org/wiki/User_experience_review_queue
[8] "I feel that solving a problem is more interesting than finding a name for the solution. I realize that I stand in the minority of the open source community on this." -Kevin Maples
20%, LevelUp and (I believe) whatever model comes after are victims of collateral damage caused by a root problem: lack of time, lower priority.
Are we paid by the Wikimedia community to maintain an infrastructure and deliver specific features at specific times? Or are we paid to build and maintain an increasingly sustainable and empowered technical community?
The nicest aim is "both!" but our steps show that currently we are assigned to deliver a service, and this is the main measure of our success. The logical consequence is that the sustainability and empowerment levels of our technical community suffer. The problems of 20% and LevelUp are just a symptom of that.
If we as a community really want to do both then we need to change something deep in our plans. Our community metrics should matter as much as our delivery deadlines, and trade-offs should be negotiated if one of both gets into bad red numbers. Teams should plan for deliveries as much as for community sustainability within their scope areas. The board and the WMF executives should be ready to ask and understand metrics and trade-offs in both sides.
Without this change we are likely to keep falling in the same trap: setting plans and expectations that the daily stress will squash. Employees unable to keep their "sustainability" goals and managers unable to enforce them either because there is a deadline we must meet.
PS: I took the liberty to prune your analysis to show the backbone of the problem:
On 04/13/2013 12:42 AM, Sumana Harihareswara wrote:
Problems/unmet needs:
b. Code review backlog. Per (a) this is keeping tech contributors from learning -- it's also important that it keeps improvements from reaching users. And it's just dispiriting; the number of unresolved commits in mediawiki/* has gone from ~360 to ~815 in the last 6 months[4][5], and most of the "can we deploy this?" queues haven't moved in a few months.[6][7]
c.
The plan for LevelUp was that people's managers would check on progress. Thus LevelUp in the most recent round did not lead to most participants meeting their goals.
d.
Some feel as though they haven't been allotted the time to do any of this kind of work.
e. Related to (a) and (d), we have frustrating bottlenecks in our capacity for some key engineering activities, *especially* user experience design, community liaising, performance, front-end (especially JS) coding and review, ResourceLoader, and operations work. These affect everyone but hit volunteers disproportionately.
wikitech-l@lists.wikimedia.org