Skip to content

On-Call

Each week we rotate responsibility for supporting our users. The person is on-call and is expected to:

The On Call project is the hub for the week's work.

Spend the week working on issues

During the week the on-call person should be working on (in this order):

  • High priority issues and those raised by teams
  • Other bugs if all above are fixed
  • Enhancements from Up Next Enhancements if:
    • All high priority isseus are fixed
    • They've fixed 3 bugs already that week

The on-call person should not pick up new project work, unless specifically agreed with Nick or Brendan.

Public GitHub issues

Public GitHub issues are reported in Slack #bugs and come from our public repos:

First determine whether the issue is a bug or an enhancement.

On Call GitHub project

New bugs and enhancements to both our public and private repositories should appear here.

The on-call person should triage all new issues. Critical bugs should be worked on immediately, others should be added to the the Triaged Bugs list, which is in a rough priority order.

GitHub Bugs

Triage - On-call person

  1. Reproduce the issue or request more details if it's not possible
  2. Update the issue:
    • Label the issue a bug
    • Thank the user for their report
    • Inform them the current status and that it is being investigated
  3. Decide if the issue is either critical or very quick to address. If so then:
    • Dispatch the bug to the appropriate person:
      • If it was caused by a change in the latest release, assign to the person who introduced it
      • Investigate it yourself If not then add the bug to the Triaged Bugs list in the On Call Project.

Fixing the bug - Assigned person

  1. Fix the bug and create a PR which links to the issue. If the on-call person is not the assigned person, request a review from the on-call person
  2. When the PR is merged, add the next release label to the issue

Releasing fixes - On-call person

When a release is published go through the existing open issues to find the fixed issues. Close them with comment saying they are fixed.

GitHub Enhancements

  1. Respond to the suggestion by trying to find out what problem this is solving? Maybe there is another solution that is easier or already available.
  2. Update the issue:
    • Label the issue an enhancement
    • Thank the user for their report
    • Don't promise them that we'll implement it, or give them a timeline!

These will then appear in the On Call Project and Nick and Brendan will prioritise them.

Support emails

Emails to our hello@sourcery.ai group, or from our teams.

Email Bugs

  1. If it is a bug create a public issue for it and send the link to the user
  2. Handle the same way as for public issues
  3. Additional steps are to keep the user informed by email including when the fix is released

Email Enhancements

  1. Respond to the suggestion by trying to find out what problem this is solving? Maybe there is another solution that is easier or already available.
  2. Thank the user for the suggestion but don't promise anything unless it is in the current cycle.

Sentry issues

Sentry capture exceptions from all across Sourcery:

New exceptions that haven't been seen before are reported in Slack #sentry_alerts.

Handling Sentry issues

This section needs to be fleshed out as it is handled.

Discord

We have a Discord server called Sourcery.

Respond to any bugs, questions and suggestions there in a timely manner.

If anyone suggests a refactoring that is impactful and can quickly be implemented, it would be awesome to turn it around in a day to massively inspire that person. This is only the responsibility of the person on-call if all new and outstanding issues are fixed.

Handover

  • The next on-call cycle begins when the all hands and demo meetings begin on Friday
  • By that point all new issues that came in during the week must be triaged
  • The next on-call person is not responsible for taking over issues that have already been assigned