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.