Technical decision making
 | For continuous improvement, we are currently conducting a retrospective on the technical decision process.
More information about the retrospective is available. |
The Wikimedia technical decision-making process empowers teams to make decisions that are informed by experts from Wikimedia Foundation teams, affiliates, and volunteer groups.
About the decision making process
[edit]The technical decision making process has these key objectives:
- Make the process more inclusive by shifting to representation by teams or groups instead of individuals
- Have clear timelines for when a decision is made
- Be clear upfront about which stakeholders are engaged
- Develop a clear lifecycle of a decision
The process includes these main components:
- Technical Decision Forum composed of representatives from the Wikimedia Foundation Product and Technology departments, Wikimedia Deutschland, and independent +2 contributors
- Templates for problem statements and decision records
When to use the process
[edit]The technical decision making process should be used in any circumstance where the impact of the decision will be felt beyond the team making that decision. This includes decisions that have a significant impact on code and software deployed on Wikimedia production infrastructure.
Templates
[edit]The decision making process uses standard templates to document and guide decisions.
-
Problem statement template -
Responsibility assignment matrix (RACI) template -
Decision record template
Decision records
[edit]The final artifact of the process is a decision record. Visit the decisions page to read decision records that have completed the process.
Process flow
[edit]The decision making process is a sequence of steps to help decision makers define a problem, collect feedback, research solutions, and document the decision.
1. Identify the decision team and project owner
[edit]To start the process there needs to be a decision team and a proposal owner who will work through the process from start to finish. The decision team and the proposal owner is the group driving the decision. Usually the decision team is a Wikimedia Foundation team, affiliate team, or volunteer group. The project owner is the member of the decision team responsible for guiding the decision through the process.
If a decision has a wide impact, the decision team can include people from different teams. For example, the decision to implement the Vue.js framework was made by a cross-functional working group. It is crucial that who is accountable for the decision has the resources and the authority to act on that decision.
2. Define the problem statement
[edit]To start the decision making process, the project owner should use the problem statement template to open a task on the workboard in Phabricator.
Once a task is created, the Technical Decision Forum project manager copies the problem statement into a Google Doc and shares it with the project owner and the Forum chairs to review, add comments, and discuss. Forum chairs have one week to review the problem statement and provide feedback to the decision team. There will be at least one office hours with Chairs and the decision team to discussion and sign-off the final version of the Problem Statement.
Once the project owner is ready to share the revised problem statement, the Forum project manager adds a link to the Google Doc in the original Phabricator task.
Touch points
- Office hours
- Phabricator
3. Get feedback from the Decision Forum
[edit]Once the problem statement is finalized, the Technical Decision Forum Representatives will review the problem statement and provides feedback to the decision team. Forum Representatives are expected to share their feedback within one week. The feedback answers these questions:
- Is the problem statement correct?
- Is it clear how solving this problem supports Wikimedia goals (movement strategy, medium term plan, annual plan, etc.)?
- Are these the right stakeholders?
- Is the needed subject matter expertise to make a decision reflected accurately? Are the right groups outlined in the problem statement?
The Forum project manager is responsible for requesting review from Forum members and sharing Forum feedback with the project owner.
Touch points
[edit]- Office hours
- Technical Decision Forum Google Group
- Phabricator
- Google Docs
- Slack
4. Research and prototype
[edit]Once the Forum has provided feedback on the problem statement, the decision team begins researching and prototyping solutions. This phase should have a well-defined scope and time frame.
The decision team is responsible for checking in with the Forum every two weeks to share their progress. This is the time when stakeholders engage with the decision team, further models are developed, and prototyping occurs as needed.
Touch points
[edit]- Technical Decision Forum
- Demonstrations during office hours
- Retrospectives
- Phabricator
- Progress announcements in decision making process updates
Executive review
[edit]For larger, more impactful decisions, system-level tradeoffs, or decisions that greatly impact the community, demonstration of the problem statement is done for relevant executives, typically the Chief Technology and Product Officer (CTPO) of the Wikimedia Foundation. The CTPO delegates a representative to review the problem statement and flag for executive review.
5. Make the decision
[edit]Once the decision team has engaged all the stakeholders outlined in the problem statement and (if required) reviewed with executives, the team can make the decision.
Touch points
[edit]- Technical Decision Forum
- Phabricator
- Decision announcement in in decision making process updates
6. Publish decision record
[edit]Once a decision has been made, the decision team publishes the decision record to the decisions page.
Questions and feedback
[edit]Questions and feedback are always welcome. Contact us at TDFsupport@wikimedia.org.
Background
[edit]The technical decision making process was adopted in 2020 as an evolution of the Requests for comment (RFC) process (TechCom). To learn more, visit the background page.