Technical Collaboration Guidance

The Technical Collaboration Guideline (TCG) allows Wikimedia Foundation (WMF) Product teams and Wikimedia communities to work together in a systematic way by establishing best practices for inviting community involvement in the product development and deployment cycle.

The Technical Collaboration Guideline is part of a Wikimedia Foundation Annual Plan goal for the Technical Collaboration team to create a systemic approach to community engagement for product development teams. The emphasis in the Technical Collaboration Guideline is on communication - consistency and reliability in sharing and discussing information with interested community members. The TCG explicitly does not focus on the processes of creating software, as development plans are unique to each product, and Product teams determine goals and expected outcomes for their work. Instead, for now the TCG helps to identify the who, what, when, where, and how community members can be reached so that they can participate in the processes that are set up for each project or product.

The TCG is being developed over the course of the 2016/2017 fiscal year for the Wikimedia Foundation, and is being led by Keegan Peterzell. The basic recommendations are scheduled to be completed by the end of 2016.

Sections

 * /Principles/
 * /Private planning/
 * /Milestone communication/
 * /Translation/

Timeline
Subject to change, very rough. "Q" stands for quarter in the fiscal year 2016-2017, so Q1 refers to July-Sept 2016. Dependencies and risks are TBD.
 * Q1 - T138240: Technical Collaboration Guideline - project information, T138436: Technical Collaboration Guideline - translations,T137088: Recommendations to publish Product updates: drafts will be completed, forming the foundation of the TCG ("Milestone communication" and "Translation"). This moves towards completing objective one.
 * Dependencies here are other peoples' time to discuss the issues, and me focusing on what I've learned from my conversations and turning them into actionable recommendation bullet points. The risk here is that, despite best efforts to work with a multitude of stakeholders within the WMF on this, a viewpoint might get lost that will help inform the outcome due to time constraints. This is mitigated by the review in the second quarter.
 * Q2 - Thoroughly review the TCG draft with CLs and product teams to iterate and improve, keeping in mind additional sections may be found that need to be written.
 * Dependency here is other peoples' time. The time this will take is unknown. I could receive little feedback and have little to do for refinement, the thing might need a major overhaul, or maybe just simple copy-editing. I'm not going to have an understanding of the commitment until the time comes. The worst-case scenario is that it takes more time than a quarter. This isn't not a bad thing, as it will not preclude other work from happening anyway. Areas of the TCG that are deemed complete can go ahead and be used.
 * Q2/3 - I start working with a CL and a product team to use the TCG - starting with a product inception - to use the recommendations in the TCG, and document the steps and outcomes. This moves towards completing objectives two and three.
 * Dependency here is a product team with a CL that will a) buy-in to the TCG recommendations and b) has a new concept that is ready to be explored. The risk is TCG recommendations will be heard as recommendations and not necessarily followed - thus the importance of buy-in from whatever team takes this on.
 * Q4 - communicate the TCG and encourage its adoption within the WMF and communities