How to be a Sheriff - Seneca-CDOT/dps911-osd700-winter-2023 GitHub Wiki

Overview

Sheriffs help steward and manage the project and its infrastructure, and make sure that the team can function optimally at all times. Their primary role is to help developers shepherd their code through the development and review process so that it can be landed cleanly in git, and to do so without breaking any tests, CI automation, or infrastructure.

While open source is a community effort, the Sheriffs play a crucial role in helping to maintain quality, keep operations running smoothly, and to help deal with fallout from any unexpected situations. Sheriffs aren't "in charge" or responsible for fixing every problem. Instead, they are our first line of defence, helping to shine a light on problems, coordinate efforts to make fixes, and making sure we make decisions quickly.

Schedule

At any given time, two Sheriffs are on-call, with a third on backup as needed. We always maintain at least two so that we can get changes and reviews done quickly if necessary. Everyone on the team is required to take regular rotations as one of the Sheriffs. If you haven't already done so, please add your name to the Sheriff Schedule so that it is full.

If you are scheduled to be Sheriff and can't perform your duties for some reason, it is your responsibility to reach out to your backup and make sure that another person can take your on-call.

Responsibilities

The single most important responsibility of a Sheriff is to be available to the team to help solve issues that would otherwise keep the tree from being open and green. This includes:

  • Being available and visible on Slack. Sheriffs are first-among-peers and ready to help the community with whatever is going wrong.
  • Monitoring all of our systems for possible issues or failure, including GitHub, PRs, CI, Staging, Prod, and other Infrastructure
  • Communicating with the team on Slack and GitHub when issues arise. Sheriffs help maintain calm and facilitate timely communication.
  • Filing issues when problems arise, or discussions happen in Slack or meetings (i.e., capture knowledge).
  • General issue maintenance (e.g., adding labels, assigning to people, fixing typos, linking to issues, etc).
  • Keeping PRs moving through review, especially making sure that the right people are assigned to do reviews and are responding
  • Helping with git issues (e.g., squashing, rebasing)
  • Making sure that CI is green. If something breaks, Sheriffs file issues and help lead an investigation, pulling in whoever the experts are in a particular area.
  • Backing-out changes that can't be fixed (i.e., git revert). Sheriffs make sure that the rest of the team isn't blocked on a failed push or CI build.
  • Helping to communicate changes to the team when a breaking change lands (e.g., being able to point devs to docs or PRs that help explain how to adjust their environment/code to recent changes on master).
  • Running meetings, including weekly triage. This includes documenting the outcomes of these meetings.

If something goes wrong, the Sheriff is the one to call on first. Sheriffs should know what's landed recently, and what's about to land, and can talk about the state of the tree at any point.

Sheriffs are encouraged to change their Slack name to add "-Sheriff", so that devs can quickly find them when needed. They can also pin communication to the Slack channel, indicating who is on-call.

Creating Releases

Sheriffs create a release in our GitHub repo at the end of a milestone for the project. For how to manage releases, GitHub has excellent documentation on how to manage releases, including creating one.

To increment project version for a release, you can use CLI command npm version in the project directory.

For example, assuming you have initialized npm and git, npm version 0.8.0 -m "sample commit" will change the version in package.json and create a new commit with the commit message sample commit by -m option. This new commit will have a tag v0.8.0, which you can use for creating a release.

NOTE: locally created tags don't exist on GitHub repo unless you push them. To push the commit with the tag, you can push with --tags flag, such as git push origin main --tags. For more information on tags, see here.