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
 * Antoine &#34;hashar&#34; Musso - Monday - European times
 * Brandon Harris - Monday-Friday, varying schedule, design reviews
 * Brion Vibber - Tuesday Pacific office hours, code/bug/patch review
 * Gabriel Wicke - Monday-Friday varying, Europe, on IRC, new parser design documentation and code review
 * Ian Baker - Monday, code review
 * Neil Kandalgaonkar - Monday and Thursday afternoons PST
 * Niklas Laxstrom - Monday-Friday, Europe, always available on IRC
 * Patrick Reilly - Thursday, code review, bugs
 * Roan Kattouw - Wednesday, roughly 11am-8pm CET (actual hours vary), code/bug/patch review
 * Sam Reed - Friday, 12pm to 8pm, code/bug/patch/other review
 * Tim Starling - Friday (Australia, Thursday afternoon/night US)
 * Trevor Parscal - Monday, code review

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!

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) Increase test coverage
 * 3) 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.

Exemptions

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