This is about our Team Compass, how to understand and read it, and how to make changes if you need.
Why have a Team Compass?¶
There are a few major reasons why we use a Team Compass:
Asynchronous coordination. 2i2c is a distributed organization with team members across the world. Some are full-time, some are part-time, some are collaborators that work closely with us. Having a Source of Truth that is available to all team members helps us stay aligned and prevent information silos from popping up.
Transparency. 2i2c collaborates with many external stakeholders, and wishes to be a model organization for transparent and inclusive organizational dynamics. We believe this builds trust and connections with communities we serve. The Team Compass is a record of everything we’re up to, and how we do it.
Provenance. Almost all organizational decisions are made via edits to the Team Compass, or in documentation that we link to from the Team Compass. Because we conduct most discussions in GitHub repositories and issues, we have a historical record of the evolution of 2i2c, as well as provenance behind its decisions.
How to update the Team Compass¶
The 2i2c Team Compass is a living document and should be frequently updated reflect our current practices and policies. Any 2i2c team member is encouraged to propose changes to the Team Compass to ensure it serves as the Source of Truth for the organization.
Do not hesitate to propose a change! See our Documentation Guide for instructions of how to edit our Team Compass (and other documentation that 2i2c uses).
The following procedure provides guidance on submitting, reviewing, and merging pull requests for the Team Compass. If there is an ambiguity in this procedure, see Making decisions at 2i2c for the principles motivating these guidelines.
If a PR is related to an issue from another repository with the 2i2c organization, include a reference to that issue in the PR description. Leave a paper trail.
PRs that concern minor grammatical fixes, updates of broken links, or a style changes that improves readability should be self-merged without review. Trust one another.
PRs that involve a policy or procedural change within a team should be reviewed by at least one other member of that team. Consult the right people.
If a team has already decided on a process, and the Team Compass is simply out-of-date, then it’s acceptable to self-merge a PR without approval (even if the PR is simply to delete out-of-date process and link to another document that defines our current process). Iterate on the core ideas.
Once a PR has been approved via a review, it can be merged by anyone. Bias towards action.
A PR should not remain open for more than a week. Timebox the discussion.
PRs are always welcome. If something seems unclear or incorrect to you, it likely needs improvement. Make it safe to try.
If there a concern that “it is too much work to adapt <pre-existing process doc> to make a PR” and that is blocking updating the Team Compass, it is better to delete a section and add a sentence like "the process for this is documented at [this link]() ". The Team Compass can delegate authority for a process to other places.
What is a Source of Truth¶
The Team Compass is a Single Source of Truth, meaning that it is the definitive answer for questions about 2i2c’s policy and state. Below is a quick definition of “Source of Truth”:
- Source of Truth
- Distributed teams and open communities need to balance information across team members, and ensure that everyone is on the same page. For this reason, it is recommended to adopt a “single source of truth” for anything important. This is an authoritative source that everyone can look to in order to know the current status and plan for anything we do at 2i2c[1].
- Single Source of Truth
- See Source of Truth.
References for Single Source of Truth: For a few examples, see this Bitergia post and the GitLab SSOT section.