Wikimedia engineering 20% policy
This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. |
Wikimedia Foundation engineering 20% policy
A policy and practice whereby WMF engineering staff spent at least 20% of their work time on tasks that directly serve the Wikimedia developer and user community
LevelUp → |
The 20% policy was a policy for all full-time paid Wikimedia Foundation engineering staff. In a nutshell, the policy states that irrespective of other assignments, every engineer or product manager should spend at least one day a week on tasks which directly serve the Wikimedia developer and user community, ideally in ways which can't be easily done by most volunteers, and/or which increase volunteer capacity.
Scheduling
[edit]WMF engineering staff can list their "20% days" below. Please be specific about the times you plan to be available.
- Aaron Schulz - Thursday, code review (code status changes and code reviews in Gerrit)
- Antoine "hashar" Musso - Monday - European times (code status changes and reviews in Gerrit)
- Benny Situ - Friday, code review/patch (code status changes, reviews in Gerrit)
- Brandon Harris - Monday-Friday, varying schedule, design reviews (code status changes)
- Brion Vibber - Tuesday Pacific office hours, code/bug/patch review (code status changes)
- Niklas Laxström - Thursday and Friday morning, Europe, always available on IRC; Google Summer of Code mentorship (code status changes)
- Roan Kattouw - Tuesday Pacific office hours (actual hours vary), code/bug/patch review (code status changes, code reviews in Gerrit)
- Rob Moen - Tuesday, code/patch/bug review (code status changes)
- Sam Reed - Friday, 12pm to 8pm, code/bug/patch/other review (code status changes)
- Tim Starling - Friday (Australia, Thursday afternoon/night US) (code status changes)
- Trevor Parscal - Tuesday, code review (code status changes)
- Ryan Kaldari - Friday, bugs, code review, Google Summer of Code mentorship (code status changes)
- Amir E. Aharoni - Sunday, code review (code status changes, reviews in Gerrit)
- Max Semenik - Friday, code review, bugs, Google Summer of Code mentorship (code status changes)
- Matthias Mullie - Friday European time, code review (code reviews in Gerrit)
- Gabriel Wicke - Will be mainly Thursday European time after Parsoid deadline in December, on IRC. Parsoid documentation / communication, code review, bugs and GSoC mentoring (code status changes)
- Subramanya Sastry - will be Thursday US Central Time after Parsoid deadline in December, Code/bug/patch review, Parsoid code documentation (wiki pages) and tests (wiki pages)
- Patrick Reilly - will be Thursday after mobile team deadline on 16 September; code review, bugs (code status changes and reviews in Gerrrit)
- Jon Robson - will be Friday after mobile team deadline on 16 September
- Arthur Richards - will be Friday PST workday after mobile team deadline on 16 September, code review, bugs, testing, other things as they come up (code status changes)
- Andrew Otto - will be Friday, starting when Analytics team gets to full power
- David Schoonover - will be Friday, starting when Analytics team gets to full power
- Diederik van Liere - will be Friday, starting when Analytics team gets to full power
Especially during 20% days, WMF engineering staff should aim to be available on relevant IRC channels and lists, and participate in community activity such as bug triaging processes, ongoing release planning, etc.
Schedule chart
[edit]Not fully filled out yet. Please mark out the hours you're committing to be regularly available online as code/bug/patch-review office hours. Don't forget to leave time out for lunch!
IRC checkins
[edit]Each cohort should plan on checking in daily for 15 minutes on IRC:
- Tuesday 18:15 UTC (10:15am PST)
- Brion Vibber - Tuesday Pacific office hours, code/bug/patch review (code status changes)
- Roan Kattouw - Tuesday Pacific office hours, code/bug/patch review (code status changes, code reviews in Gerrit)
- Rob Moen - Tuesday, code/patch/bug review (code status changes)
- Trevor Parscal - Tuesday, code review (code status changes)
- Brandon Harris - Monday-Friday, varying schedule, design reviews (code status changes)
- Matthias Mullie - Tuesday European time, code review (code reviews in Gerrit)
- Wednesday 18:15 UTC (10:15am PST)
- Niklas Laxstrom - Monday afternoon for deployment, Thursday at 7-8UTC, and Friday morning, Europe, always available on IRC (code status changes)
- Thursday 18:15 UTC (10:15am PST)
- Aaron Schulz - Thursday, code review (code status changes and code reviews in Gerrit)
- Patrick Reilly - Thursday, code review, bugs (code status changes)
- Subbu
- Friday UTC/late Thursday SF - 00:00 UTC (4pm PST)
- Benny Situ - Friday, code review/patch review (code status changes, reviews in Gerrit)
- Tim Starling - Friday (Australia, Thursday afternoon/night US) (code status changes)
- Ryan Kaldari - Friday, bugs, code review (code status changes)
- Arthur Richards - Friday PST workday, code review, bugs, testing (code status changes)
- Friday 17:30 UTC (9:30am PST)
- Antoine "hashar" Musso - Monday - European times (code status changes and reviews in Gerrit)
- Sam Reed - Friday, 12pm to 8pm, code/bug/patch/other review (code status changes)
- Amir E. Aharoni - Sunday, code review (code status changes, reviews in Gerrit)
- Gabriel Wicke - Monday-Friday varying, Europe, on IRC, new parser design documentation and code review (code status changes)
- Jon Robson
- The Analytics Team (Diederik van Liere, Andrew Otto, David Schoonover)
Scope
[edit]The 20% policy is a policy for all full-time paid Wikimedia Foundation engineering staff. In a nutshell, the policy states that irrespective of other assignments, every engineer or product manager should spend at least one day a week on tasks which directly serve the Wikimedia developer and user community, ideally in ways which can't be easily done by most volunteers, and/or which increase volunteer capacity. These are identified as primary tasks below.
Examples of primary tasks that can fall into this category:
- Merging reviewed code into the release or deployment branch, and deploying it
- Resolving bugs which require shell access or develop reviewed task lists to let volunteer easily handle them.
- Pairing up with volunteers on code review, bug fixes or general development, to build skills/capacity
- Individual ongoing code review, of patches and commits, to ensure the backlog doesn't exceed an acceptable maximum.
- Complex branch reviews and branch merges
- Design review or UX testing of community-developed projects/improvements
- Updating public wiki pages, documenting/sharing data, and otherwise contributing to making WMF engineering work transparent
- Engaging in discussions, especially insofar as it goes beyond simply being responsive and available.
Examples of secondary tasks that can fall into this category:
- Ongoing bug fixes & bug triage support
- Increase test coverage
- Build documentation or examples explaining how to use the MediaWiki code[1]
Secondary tasks may be more suitable for newly hired or junior developers, especially when paired up with more experienced engineers.
20% time is not a replacement for fully dedicated effort supporting MediaWiki releases, code/security review, QA, etc. Instead, it is intended to ensure that we share the workload on tasks which are mission-critical to Wikimedia's success more broadly, and that all Wikimedia engineering staff remain in touch with the larger Wikimedia development and user community through the course of their daily work.
WMF staff responsible for 20% time should check in with the activity lead during the appropriate check-in time prior to the 20% day, bearing in mind the status on this page. We may need to negotiate the priority of the activity.
Exemptions
[edit]- Site emergencies
- Part-time engineers
- Mission-critical project teams (e.g. fundraiser)
Notes
[edit]- ↑ see http://railscasts.com/ for an example applying to the Ruby on Rails framework