Technical decision making/Background

= 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

= Process Model =



= What? =

0 Decision Team Identification or Creation
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.

1 Decision Statement Overview (1 week)
A document which describes the decision to be made.

Template: Decision Statement Overview


 * 1) Why: what is the value? Does it align with our broader values?
 * 2) What: What is needed? What is in Scope and What is out of Scope?
 * 3) Who: Who needs to be consulted? Who will be implementing this? Affected by this? What is the impact? (Using RACI format)
 * 4) When? Any timeline?
 * 5) Model or Diagrams (optional): A visualization to help distill the decision to be made.

Touch Points:


 * Phabricator Workboard (with overview template)

2 Technical Decision Forum
The Decision Statement Overview 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?
 * Are these the right stakeholders?
 * Is the needed subject matter expertise reflected accurately?

Touch Points:


 * Office Hours
 * Technical Decision Forum Google Group
 * Phabricator

3 Research and Prototyping Stage (Timeboxed with bi-weekly check-ins)
Once the Decision Statement Overview is confirmed with the Technical Decision Forum, the Technical Decision Team begins work and demos/checks in with the Technical Decision Forum on a biweekly basis. 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.

Touch Points:


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

4 Executive Review (Depends on the scope of the decision)
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 CTO and CPO. The CTO and CPO will delegate a representative that will review the Decision Overview 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

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

Touch Points:


 * Technical Decision Forum
 * Phabricator
 * Decision Announcement in Technical Decision Radar

6 Decision Record Published
Once a decision has been made it is published on MediaWiki.org in a decision record area.

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

What the forum is

 * A place to empower teams to make decisions that are informed by others
 * A place to clarify stakeholders and problem statements
 * A touch point for technical teams

What the forum is not

 * A decision making body
 * A blocking body
 * Another discussion venue for technical solutions
 * A place to do the actual stakeholder consultations on the specifics of a decision

Composition
The Technical Decision Forum is composed of representatives from different teams from the Wikimedia Foundation and WMDE (with room to add additional affiliates) and other groups and networks from the volunteer community.

Each team appoints a representative in the Technical Decision Forum and teams can change their representative at any time. Teams are expected to plan for coverage during vacations and other types of leave in the forum.

The forum has two co-chairs. One representing the Technology Department and the other representing the Product Department. Chairs are appointed by the CTO and CPO respectively and rotated on a quarterly basis.

Wikimedia Foundation Teams
Wikimedia Foundation Teams may opt to have less representation than is indicated here. For example SRE may decide to have less people represent their teams than all of the individual teams. As teams change or as we grow, updates will be made accordingly.


 * Abstract Wikipedia
 * Anti-Harassment Tools
 * Community Tech
 * Editing
 * Growth
 * Mobile Apps
 * Structured Data
 * Web
 * Product Infrastructure
 * Language
 * Inuka
 * Product Analytics
 * Parsing
 * Library
 * Analytics Engineering/Data Engineering
 * Platform Engineering
 * Architecture
 * Performance
 * Release Engineering
 * Quality and Test Engineering
 * Fundraising Tech
 * Scoring/Machine Learning Platform
 * Search Platform
 * Security
 * Research
 * Data Center Operations
 * Data Persistence
 * Infrastructure Foundations
 * Observability
 * Service Operations
 * Traffic
 * Developer Advocacy
 * Wikimedia Cloud Services

Affiliate Representation

 * WMDE Engineering

Community Representation

 * Representative from the Independent +2s

Time Commitments
The expectation is that teams will be able to respond to forum requests for feedback within a week. The representatives should be able to confirm the level of stakeholder their team is in a decision (if at all) and provide feedback on the decision overview document if needed. This should require a maximum of two hours a week of commitment and it is suspected that many weeks will require less.

To make sure this time commitment remains at the level suggested sufficient program management support will be required to manage the process.

Administration of the Forum
Project Management will be provided from the Technology Department for administration of the forum. This role ensures that the decisions in process move along, SLAs are met, teams are represented and are responsible for running retrospective rituals.

Guidelines for when to use the process
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.

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 initial process will be piloted with system architecture decisions. During that time the Technical Decision Making Process/Forum and TechCom will both exist. TechCom will continue to be responsible for non-system architecture decisions 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 RFCs will be closed and the TechCom-RFC board will be archived. The tickets can always be reopened and transitioned to the new document format if they are still relevant.

= Who? = Responsible:


 * Kate

Accountable:


 * Grant

Consulted:


 * Tech Department Managers
 * Product Department Engineering Managers
 * Engineers
 * TechCom
 * Product Managers
 * Technical Community Members

Informed


 * Broader Wikimedia Movement

= When? = Timeline:

= Resources =


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