Technical decision making/Background

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
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
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
The decision making process uses standard templates to document and guide decisions.

Process flow
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
The decision team 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
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 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.

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

 * Phabricator workboard
 * Office hours

3. Get feedback from the Decision Forum
Once the problem statement is finalized, the Technical Decision Forum reviews the problem statement and provides feedback to the decision team. Forum members 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

 * Office hours
 * Technical Decision Forum Google Group
 * Phabricator
 * Google Docs
 * Slack

4. Research and prototype
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 scoped 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

 * Technical Decision Forum
 * Demonstrations during office hours
 * Retrospectives
 * Phabricator
 * Progress announcements in decision making process updates

Executive review
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 Officer (CTO) and Chief Product Officer (CPO). The CTO and CPO delegate a representative to review the problem statement and flag for executive review.

5. Make the decision
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

 * Technical Decision Forum
 * Phabricator
 * Decision announcement in in decision making process updates

6. Publish decision record
Once a decision has been made, the decision team publishes the to the decisions page.

Questions and feedback
Questions and feedback are always welcome. Contact us at [mailto:tech-decision-forum-support@wikimedia.org tech-decision-forum-support@wikimedia.org].

Office hours and retrospectives
Office Hours are every two weeks by appointment from 12:00pm-1:00pm Eastern Time (17:00-18:00 UTC). Appointments are available on the Wikimedia Foundation staff calendar every other Tuesday for 30 minutes each. Office hours are open to anyone who has questions about a decision or about the process. To schedule an appointment, use the Google calendar page or contact us at [mailto:tech-decision-forum-support@wikimedia.org tech-decision-forum-support@wikimedia.org]. Retrospectives are held twice a quarter to review the decision making process.

Background
The technical decision making process was adopted in 2020 as an evolution of the Requests for comment (RFC) process (TechCom).

Why?
To evolve the TechCom RFC process to a more explicit decision making process that allows teams and other stakeholders to have a clear understanding of:


 * What types of decisions must utilize this process
 * What the timeline expectations are for that process
 * Who the stakeholders are that should be engaged in their decision
 * The lifecycle of a decision: a problem being raised -> decision being made -> published -> revisited -> iterate and improve

Currently, many cross cutting technical decisions are shepherded by TechCom. TechCom has lacked the resourcing to be proactive about decisions and all necessary stakeholders aren’t always represented. This shift is designed to take the best parts of the TechCom process and improve upon the challenges. It is also intended to allow iteration. The first release doesn’t propose to improve every single aspect of the existing process, but does have the goal to make those aspects at least equal with the status quo. The change will ensure decisions are being driven by teams or groups fully committed to completing the work, that problem statements are defined early and stakeholders are outlined. This proposal is also designed to remove gatekeeping by ensuring people are consulted rather than giving explicit approval. Following is a review of the successes and difficulties of the existing TechCom process. In shifting this process we do not want to forget the successes but also want to improve on the challenges.

Successes of the TechCom RFC Process


 * Clear place to ask for a decision
 * Process occurs transparently on Phabricator
 * TechCom Radar summarized discussions going on
 * Defined process
 * Identifies many stakeholders during the process

Challenges of the TechCom RFC Process


 * Not always clear who is driving the decision and when a decision will be made
 * Viewed and reacted to as gatekeeping
 * Sometimes stakeholders are missed
 * Often TechCom is brought in late in the process
 * Solutions are brought forward without a clear problem statement/stakeholders not agreeing on what problem is being solved
 * TechCom does not have inclusive membership
 * Not a clearly resourced committee
 * Project Management of process not clearly resourced

Decision type matrix
Below are typical decisions from the existing RFC process. These decisions are outlined here to ensure they are not lost in the transition. Some decisions are outside the scope of this process and a new responsible party is proposed. Both the type of decision and the group that should be responsible for driving this type of decision are outlined below. Some items such as the product specific decisions are not technical in nature and should be made by Product rather than in this process.

Transition process
This variant of the process was piloted with Vue.js decisions. During that time the Technical Decision Making Process/Forum and TechCom both existed. TechCom will continue to be responsible for other decisions beyond the work of the Vue.js Taskforce per the existing TechCom Charter. Having both exist at the time allows for trial and iteration on this process on a small scale before using it for a wider range of decisions.

Once the pilot is finished all technical decisions and TechCom will be transitioned to the Technical Decision Making Process. TechCom members may serve as representatives of their teams on the Technical Decision Forum if that is what their team decides.

What happens to existing RFCs?

There will be a two week grace period after the Technical Decision making process and Technical Decision Forum is set-up for groups to claim their existing RFCs. After the two weeks the remaining Phabricator tasks that are purely RFCs will be closed and the TechCom-RFC board will be archived. Other tasks that are tagged as RFCs but contain other work will be triaged and untagged as an RFC and requested be moved to the next decision making process if appropriate. The tickets can always be reopened and transitioned to the new document format if they are still relevant.

Resources

 * Open Decision Framework
 * Farnam Street Decision Making Course
 * Wikipedia Article on consensus decision making
 * GEODE RFC Process
 * Eigenquestions: The Art of Framing Problems
 * Decisive Dan and Chip Heath