Document a merge policy for team-compass

[jmunroe]

When try to fix some linking issues in https://github.com/2i2c-org/team-compass and discovered that there are currently 5 open PR (all 2-weeks or older):

• Add more docs to our blog section
• Clarify that we don't use X/Twitter
• Update workflow.md
• Add definition of the OSAE role
• Add link to fundraising guide

Unlike our infrastructure repo, we don't have a self-merge policy on team-compass. Assuming nothing yet is written down, I'll propose:

Contributing to the 2i2c Team Compass

The 2i2c Team Compass is a living document and should reflect our current practices and policies. Any 2i2c team member is welcome and encouraged to propose changes to the Team Compass to ensure it serves it function as the Single Source of Truth for the organization.

The following procedure provides guidance on submitting, reviewing, and merging pull requests for the Team Compass. If there is an ambiguity in this procedure, refer to 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.
• 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.

[choldgraf]

I really like that you noted the problem above (stale PRs on the TC), suggested the root cause (unclear process around merging on the TC), and stated your intent to document a solution to that problem (a new process) with simple language ready to merge. Really nicely done.

Maybe one other point to include:

• If the 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).

More generally, I don't want "ugh it is too much work to adapt <pre-existing process doc> to the Team Compass" to be a blocker for updating the team compass. It would be much better to just 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!