Wikimedia engineering 20% policy

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.

Scheduling
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 ( and code reviews in Gerrit)
 * Antoine &#34;hashar&#34; Musso - Monday - European times ( and reviews in Gerrit)
 * Benny Situ - Friday, code review/patch (, reviews in Gerrit)
 * Brandon Harris - Monday-Friday, varying schedule, design reviews
 * Brion Vibber - Tuesday Pacific office hours, code/bug/patch review
 * Gabriel Wicke - Mainly Thursday European time, on IRC. Parsoid documentation / communication, code review, bugs and GSoC mentoring
 * Ian Baker - Friday, code review
 * Niklas Laxström - Thursday and Friday morning, Europe, always available on IRC
 * Patrick Reilly - Thursday, code review, bugs ( and reviews in Gerrrit)
 * Roan Kattouw - Tuesday Pacific office hours (actual hours vary), code/bug/patch review (, code reviews in Gerrit)
 * Rob Moen - Tuesday, code/patch/bug review
 * Sam Reed - Friday, 12pm to 8pm, code/bug/patch/other review
 * Tim Starling - Friday (Australia, Thursday afternoon/night US)
 * Trevor Parscal - Tuesday, code review . Currently working on code review for Extension:OnlineStatusBar.
 * Ryan Kaldari - Friday, bugs, code review
 * Amir E. Aharoni - Sunday, code review (, reviews in Gerrit)
 * Arthur Richards - Friday PST workday, code review, bugs, testing, other things as they come up
 * Max Semenik - Monday-Friday, code review, bugs
 * Andrew Otto - Friday
 * David Schoonover - Friday
 * Diederik van Liere - Friday

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
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
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
 * Roan Kattouw - Wednesday, roughly 11am-8pm CET (actual hours vary), code/bug/patch review
 * Rob Moen - Tuesday, code/patch/bug review
 * Trevor Parscal - Tuesday, code review
 * Brandon Harris - Monday-Friday, varying schedule, design reviews
 * Jon Robson
 * 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
 * Thursday 18:15 UTC (10:15am PST)
 * Aaron Schulz - Thursday, code review
 * Patrick Reilly - Thursday, code review, bugs
 * Friday UTC/late Thursday SF - 00:00 UTC (4pm PST)
 * Benny Situ - Friday, code review/patch
 * Tim Starling - Friday (Australia, Thursday afternoon/night US)
 * Ryan Kaldari - Friday, bugs, code review
 * Arthur Richards - Friday PST workday, code review, bugs, testing
 * Friday 17:30 UTC (9:30am PST)
 * Ian Baker - Friday, code review ** Antoine &#34;hashar&#34; Musso - Monday - European times
 * Sam Reed - Friday, 12pm to 8pm, code/bug/patch/other review
 * Amir E. Aharoni - Sunday, code review (, reviews in Gerrit)
 * Gabriel Wicke - Monday-Friday varying, Europe, on IRC, new parser design documentation and code review
 * The Analytics Team (Diederik van Liere, Andrew Otto, David Schoonover)

Scope
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:


 * 1) Merging reviewed code into the release or deployment branch, and deploying it
 * 2) Resolving bugs which require shell access or develop reviewed task lists to let volunteer easily handle them.
 * 3) Pairing up with volunteers on code review, bug fixes or general development, to build skills/capacity
 * 4) Individual ongoing code review, of patches and commits, to ensure the backlog doesn't exceed an acceptable maximum.
 * 5) Complex branch reviews and branch merges
 * 6) Design review or UX testing of community-developed projects/improvements
 * 7) Updating public wiki pages, documenting/sharing data, and otherwise contributing to making WMF engineering work transparent
 * 8) Engaging in discussions, especially insofar as it goes beyond simply being responsive and available.

Examples of secondary tasks that can fall into this category:


 * 1) Ongoing bug fixes & bug triage support
 * 2) * E.g. 1.19 deployment blockers
 * 3) Increase test coverage
 * 4) Build documentation or examples explaining how to use the MediaWiki code

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

 * Site emergencies
 * Part-time engineers
 * Mission-critical project teams (e.g. fundraiser)