Technical Decision Forum/Technical Decision Making Process

Jump to navigation Jump to search
Other languages:

This process should be used in any circumstance where the impact of the decision will be felt beyond the team making that decision. This especially includes decisions that impact code and software deployed on Wikimedia production infrastructure.

Latest updates Visit the workboard Technical forum logistics and membership Published decisions


Below is a process for how technical decision are made. This process was adopted in 2020 as an evolution of the legacy TechCom process.

Key objectives of this process are:

  • Make the process more inclusive by shifting to representation by teams/groups instead of individuals
  • Have clear timelines for when a decision will be made
  • Being clear upfront about what stakeholders will be engaged
  • Developing a clear lifecycle of a decision

This process includes:

  • Technical Decision Forum which will be composed of representatives of teams from Product and Tech, WMDE and independent +2 contributors.
  • Templates for problem statements and decision records

Process Model[edit]

Technical Decision Making Process FlowNEW.png

Decision Making Flow[edit]

Decision Team Identification or Creation[edit]

The Decision Team is the group driving the decision. In most cases this will be an individual team, volunteer group or affiliate. But there are certain decisions, similar to the decision to implement Vue.js (JavaScript Framework), that are more cross cutting where the team might be made up of a cross section of people. It is crucial that who is accountable for the decision is resourced (have a clear way to execute the decision) and they have the authority to act on that decision.

Problem Statement (1 week)[edit]

A document which describes the decision to be made. This is tagged with the Technical Decision Making board in Phabricator.

STEP 1: CREATE 'Problem Statement' task in Phabricator. [Decision Team]

You can use this Phabricator task template to create the task.

STEP 2: Technical Decision Forum Project Manager copies the submitted 'Problem Statement' task in Phabricator into a Google Doc and shares it with the project owner who submitted it and the Technical Decision Forum Chairs to review, add comments and discuss. Below is the template for the Google Doc that will be used for real-time collaboration during this stage of the process. The Technical Decision Forum Project Manager will add a link to the Problem Statement Google Doc to the initial phabricator task when the project owner is ready to share it.

Template: Problem Statement

  • Define the problem or opportunity (WHAT).
  • Outline the importance of addressing the problem or opportunity (WHY).
TDF Problem Statement.pdf

Touch Points:

  • Phabricator Workboard (with overview template)
  • Office Hours (available by appointment biweekly)

Technical Decision Forum[edit]

The Problem Statement is shared with the Technical Decision Forum by adding a phabricator ticket to the Decision Forum Inbox. The Project Manager of the forum will monitor phabricator and send process emails to the forum when there are new overviews.  

The Technical Decision Forum is made up of people representing individual teams, organizations or volunteer groups. The Forum is chaired by a representative from the Technology Department and one from the Product Department, the chairs are rotated on a quarterly basis. Teams may rotate their representation as needed, but the expectation is that feedback on the artifact can be provided within a week. The feedback requested at this point is as follows:

  • Is the problem statement correct?
  • Is it clear how solving this problem moves forward our organizational goals (supports, Movement Strategy, the 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 overview?

Touch Points:

  • Office Hours
  • Technical Decision Forum Google Group
  • Phabricator
  • Google Docs
  • Slack

Research and Prototyping Stage (Timeboxed with check-ins every two weeks)[edit]

Once the Problem Statement is confirmed with the Technical Decision Forum, the Decision Team begins work and demos/checks in with the Technical Decision Forum every two weeks. Here is where options and solutions are developed. This phase should be scoped and timeboxed. At the check-in they demo progress being made to inform the decision. This is the time where stakeholders are engaged with, further models are developed and prototyping occurring as needed.

Note: Demonstrations do not have to be prototypes with UIs. They could be a summary on progress on a document, pseudo code or anything else that helps others see where the team's progress and thinking is at that time.

Touch Points:

  • Technical Decision Forum
  • Demonstrations during Office Hours
  • Retrospectives
  • Phabricator
  • Progress Announcements in Technical Decision Radar

Executive Review (Depends on the scope of the decision)[edit]

For larger, more impactful decisions, system-level tradeoffs or decisions that greatly impact the community, demonstration of the overview is done for relevant executives, typically the Chief Technical Officer (CTO) and Chief Product Officer (CPO). The CTO and CPO will delegate a representative that will review the Problem Statement and flag for review with the CTO and CPO when it is believed it might meet the requirement for Executive Review.

Touch Points:

  • Meeting with Executives

Make the Decision[edit]

Once the Decision Team has engaged all the stakeholders outlined in the Problem Statement and reviewed with Executives (as required) the team can make the decision.

Touch Points:

  • Technical Decision Forum
  • Phabricator
  • Decision Announcement in Technical Decision Radar

Decision Record Published[edit]

Once a decision has been made it is published on MediaWiki here.


Retrospectives are held on a twice quarterly basis to review the decision-making process.

Technical Forum[edit]

Logistics and membership page

Guidelines for when to use the process[edit]

This process should be used in any circumstance where the impact of the decision will be felt beyond the team making that decision. This especially includes decisions that impact code and software deployed on Wikimedia Production Infrastructure.


TDF Problem Statement.pdf
RACI Template (pdf)
Decision Record TEMPLATE pdf.pdf

Decision Type Matrix[edit]

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.  

Type of decision Description Recent Examples Who is responsible for this decision?
New system or capability Project that touches other systems components, is a new component or service or is introducing a new capability on the production system. RFC: Expiring watch list entries

RFC: Wikimedia Push Notification Service

Architecture Team
Picking specific tools Teams should be able to pick the right tools to do their jobs. If the tool impacts 1 other team then it needs to go through the process.

Currently in our coupled environment though this is difficult so greater coordination might be needed for a time.

RFC: Adopt a modern JavaScript framework for use with MediaWiki

RFC: Add a frontend build step to skins/extensions to our deploy process

Engineering Teams that owns the component in question
Software implementation details Engineering practices focused questions. The “how” RFC: Standard method for feature-management in skins/extensions

RFC: Require use of common storage abstractions (policy)

Engineering Teams that owns the component in question
Product Questions Typically product questions that engineers would like an answer on because it would make some aspect of engineering life easier. Which browsers do we support at what level is one type of example. Removing support for IE 8 from basic support Product
Feature Requests Volunteer community developers sometimes have engineering level features that would be deployed on Wikimedia production infrastructure. Director of Product, Platform
Gerrit Privilege Policy Currently volunteers get +2 status through this. Staff receive +2 automatically Technical Engagement/Developer Advocacy (facilitation of decision)



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

Mapping of Current Process to New Process[edit]

Current New
TechCom Technical Decision Forum
RFC Decision Artifacts
Workboard: phab:tag/techcom-rfc/ Workboard: phab:tag/tech-decision-forum/
TechCom Radar Technical Decision Radar
Last Call When the stakeholders have been engaged
RFC is closed RFC is published as Decision Record on

Transition Process[edit]

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.