Core Experiences Group Norms

Background

Representatives from Web, Design System Team, and Editing met to discuss how to work together in shared spaces, and came up with the below guidance. By publishing these docs here, these teams agree to commit to trying this way of working for a time and iterating as appropriate.

Our assumption is that by sharing processes and approaches, we can reach greater alignment between teams, accomplish more effective collaboration, and accomplish even greater things together.

Consider this a living document, subject at all times to further discussion, alignment, and refinement as we learn more about what works for us.

Status

Currently the following teams have agreed to work in this way:

We encourage other teams to join us! If this sounds good to you and your team agrees, please add yourselves to this list.

Phabricator

Make sure any tasks for other teams are tagged with their associated backlog: Web-Team, Editing-team, Design-System-Team.
Communicate urgency to the other team via a comment or the description. If no note is left, it is assumed to not be urgent.
Use standardized, Phabricator-provided templates wherever possible to ensure relevant information is present, and to where relevant to provide well-formed bug reports with sufficient reproducibility information. Specifically, we recommend the following:
- The "Report a Software Bug" bookmark for bugs
- The "Request a Software Feature bookmark for feature requests

Gerrit

Posting or +1-ing patches in a codebase managed by another team is welcomed.
You are encouraged to not +2 or merge patches outside your area of responsibility, unless it’s urgent. Let the other team know if such urgent action occurred.

Slack

Use talk to channels, e.g. #talk-to-editing, #talk-to-web and #talk-to-design-system-team to discuss urgent matters and reference Gerrit/Phabricator tickets.
The receiving team should acknowledge high priority messages here within 24hrs
For risky changes that impact other teams' products, be proactive at communicating and getting feedback from impacted teams using Slack and Phabricator.

Tests

To assist with the above processes, we use tests (Pixel, Selenium, unit test) to document important features to each other that we may or may not be familiar with, so that we can be proactive rather than reactive about issues.
While the maintaining team often has the most context on patches merged into a particular codebase and should therefore maintain appropriate tests, it is also a responsibility of the merging team to be aware of and to discuss potential fallout with maintainers.
When regressions occur between teams, we consider and discuss the addition of tests to prevent them from happening again.