Design Systems Team/Team Processes

"Continuous improvement is better than delayed perfection."

Kanban
Design Systems Team (DST) uses Kanban methodology.

Kanban is a scheduling system developed at Toyota with the aim of balancing demand and capacity, and limiting the amount of work in progress at the same time.

Estimation
Dedicate a portion of DST Planning meetings to estimate tasks chosen by the team:


 * Tasks in the “Up Next” column of our main workboard, starting with those marked high priority.


 * Technical Program Manager facilitates, using https://planningpokeronline.com to create a room for the team.
 * Engineering Manager, Product Manager, and Technical Program Manager should “Join as spectator.”
 * Task creator describes the task at a high level. Team has a chance to discuss/clarify.
 * Engineers & designers (depending on the task) select the number that correlates to their estimate of the task:
 * 1 point = Small. We feel we understand most requirements and consider it relatively easy. Most likely be completed within a day or two.
 * 3 points = Medium. We know what needs to be done, but there may be a few extra steps. Most likely completed within one week.
 * 5 points = Large. This is complex work, or work we don’t do very often. Will likely involve research or consultation. Most likely completed within two weeks.
 * 8 points = Extra Large. We need to break this down further (add to next Task Refinement agenda, or set up a separate meeting if urgent).
 * Once all estimators have estimated, the cards are revealed. Team discusses & aligns on an estimate.
 * Technical Program Manager adds the estimate to the Phabricator task, and moves the task into a logical column/board if needed.
 * Estimates may be updated at any time as the work progresses.

Work in progress (WIP) limits
Recommended background reading: https://www.atlassian.com/agile/kanban/wip-limits

Each column in the Design-Systems-Sprint board shall have either a defined WIP limit, or no WIP limit:


 * Committed: 30 points
 * Blocked: 30 points
 * Research: 15 points
 * Ready for Design: 15 points
 * In Design: 15 points
 * Design Review: 15 points
 * Ready for Development: 15 points
 * In Development: 15 points
 * Code Review: 15 points
 * Design Sign-Off: 15 points
 * QTE Sign-Off: 5 points
 * Product Sign-Off: no WIP limit
 * Pending Release: no WIP limit

DST Phabricator Norms
For general Phabricator documentation, see: https://www.mediawiki.org/wiki/Phabricator

Phabricator Task Prioritization
Priority levels signal to ourselves and the world: How important is this task? When do we expect to complete this task?


 * Unbreak Now! = Something is broken and needs to be fixed immediately, setting anything else aside. This should meet the requirements for issues that hold the train.
 * High = Complete this month.
 * Medium = Complete this quarter (i.e., within the next three months).
 * Low = Complete next quarter (i.e., within the next six months).
 * Lowest = We will not complete this for at least six months.

Design-Systems-Team
General guidance:


 * Design-Systems-Team is our main “home” in Phabricator, and contains milestone boards Design-Systems-Product-Roadmap and Design-Systems-Sprint within it.

Design-Systems-Product-Roadmap
General guidance:


 * Tasks typically move from left to right as they progress through our workflow.
 * Tasks on the roadmap board are typically epics.

Design-Systems-Sprint
General guidance:


 * Contains tasks we are working on right now.
 * Tasks typically move from left to right as they progress through our workflow.
 * Individual team members should work from right to left: first unblock pending reviews, then finish tasks in progress, then pick up new tasks.
 * Tasks scheduled for deployment on the train should get tagged with the version number e.g. MW-1.37-notes (1.37.0-wmf.14; 2021-07-12).
 * If you need a code or design review, please highlight this in your daily standup within the #design-systems-standup Slack channel.
 * Generally, Phabricator tasks should go through triage & refinement in design-systems-team. However, sometimes tasks need immediate action - feel free to move these items into design-systems-sprint and let the team know in your standup.

Codex
General guidance:


 * Used as a “tag” to indicate that a task is related to Codex.
 * No status tracking happens in this board.

Planning

 * Review/discuss tasks that have been prioritized by PM for the next two weeks
 * Achieve a shared understanding of the work
 * Estimate tasks, accounting for complexity, risk, and difficulty

Task Refinement

 * Focusing on tasks in the "Needs Refinement" column of Design-Systems-Team board:
 * Clarify requirements, acceptance criteria, dependencies for tasks within our top priority projects

Strategy

 * Discuss open questions around our product strategy and realign on the roadmap and OKRs.

Engineering Enclave

 * Discuss technical topics in-depth
 * Standing topics:
 * If we're going to swarm, let's coordinate our swarming
 * What needs to be included in the next release?
 * What should we do in our next live code review session?

Live Code Review

 * Engineers review a pre-selected patch or patches together

Standup

 * Bring questions & issues that would benefit from real-time discussion - particularly about design/engineering handoff & spec review

Design Sync

 * Discuss and align on topics related to the design of design tokens, components, patterns and guidelines

Office Hour

 * Discuss emergent topics related to team direction, strategy, and processes with product/engineering/design/program management
 * Surface questions/issues that need cross-functional support or decision-making between engineering, design, and product/program management

Team Processes Task Force

 * Ensure DST team processes are defined, socialized, and understood
 * Facilitate improvements to team processes, such as:
 * Choosing and adhering to an Agile framework (scrum, kanban, etc)
 * Phabricator boards & workflows
 * Meeting purposes & cadences

Tea Time

 * Enjoy some low-key social time together
 * Get to know each other better

Participants and roles

 * Design Systems Team Tech Lead: submit patches, review code and resolve disagreements, +2 patches
 * Design Systems Team engineers: submit patches, review code, +2 patches
 * Design Systems Team designers: conduct design review, may +2 design-related patches
 * Contributors outside the DST: submit patches, review code, +2 some patches (see below for details)

Conduct
We value code review not only as an opportunity to prevent issues and maintain a healthy code base, but as a process that encourages collaboration, knowledge sharing, and growth. We follow these guidelines for a healthy code review culture and ask that all of our collaborators do so.

Code review ratings
We follow the definitions of the code review ratings (-2, -1, 0, +1, and +2) as outlined in the general Code review docs. We have a few additional norms around these ratings:


 * -1 is a clear signal that changes are required before the change can be merged. Generally, we give the person who applied the -1 a chance to review again after changes have been submitted. If that person isn't available in a timely manner, or if it is very clear that the concerns were addressed, someone else can confirm that the issues were resolved and merge the patch.
 * 0 is used for general comments, questions, or non-blocking concerns. Only apply a -1 if there are blocking issues outlined in comments.
 * +1 is used liberally to show support for a patch that you do not want to merge for whatever reason. Multiple approvals of a patch offers encouragement and documents support for a code change.

Who can +2?
Most of the time, someone from the Design Systems Team will apply a +2 to merge a patch. That said, we welcome contributors from outside the team to +2 a patch if it's a minor or uncontroversial change, or if general approval of the patch has been demonstrated (e.g. via a +1 from a DST member).

Unresolved comments
We use unresolved comments as a signal that a patch is not yet ready to be merged. This is especially helpful when we want to get design review before merging a patch. Before you merge something, review the unresolved comments and determine if any are blocking. If not, the patch can be merged and unresolved comments can be addressed in a future patch.