Given that we are a small functional team that is meant to maintain 🔧, support ☎️, care for ❤️, and cultivate 🌻 our amazing Octokit 
and Terraform community we often have to make decisions that are best for the entire community.
We don't take this act of prioritization lightly nor are we haphazard about it. We want to honor the time and thought that everyone has put into all of the SDKs that we have come to know and ❤️.
With the number of repos that we need to maintain (70+) and weekly interactions (500-1000 +/-) that we end up having with everyone, we have to define how we prioritize and our commitment to respond (think of an SLA of sorts) to those priorities.
In each of the repositories we own you'll see the same labels for priority.
They are:
Priority: Critical, Priority: High, Priority: Normal, Priority: Low
These map directly to the priorities set in our Octokit Active community board.
| Repo label | Community board | Example |
|---|---|---|
| Priority: Critical | Urgent | Any security issues - Data leaks - Broken or non functioning SDK that has been published - Any stop work scenarios for users (where rollback is not possible) |
| Priority: High | High | Any broken SDK methods - Deprecated or broken features - Critical dependency updates - Pull Requests that have been completed, are active, and are passing CI - Any issues that have been reported multiple times / impacting multiple users |
| Priority: Normal | Normal | Any non-prioritized features - Issues impacting a low number of users - Schema changes and additions - Normal dependency updates |
| Priority: Low | Low | Basic workflow changes - Draft issues/PRs - Stale issues/PRs - non-critical dependency updates - Any incomplete design work |
Note: This does not represent a commitment to resolution, just how quickly we'll acknowledge and respond.
| Priority | Response expectation |
|---|---|
| Urgent | 0 to 24hrs: A security advisory will be posted if needed and updates publically posted to the corresponding repository in issue or discussion form. |
| High | <= 1 Week : We'll respond in issue/PR and will have a plan of action within the response expectation time window. |
| Normal | >= 1 Week : We'll acknowledge and make administrative assignments to the issue or PR. It may be labeled "up-for-grabs", where we encourage community contribution. |
| Low | > 1 Week: Typically, little to no action will take place on these items. |
Remembering that we as a team have to prioritize not at the individual SDK or community level but across many repositories and communities, our methods need to consider several variables. Our process, while not exactly scientific, is aimed at protecting the interests of our communities first - we use a modified version of RICE.
Here are some data points, empathetic aspects, and questions we use to help us prioritize.
- Does the issue compromise data integrity, user security, or the integrity of GitHub?
- How serious is the need?
- What's the overall impact on the SDK community?
- What's the overall impact on the package communities?
- What's the overall impact on the language communities?
- How active is the SDK community?
- How many open issues are there?
- How many open PRs are there?
- What is the throughput of the given SDK where the issue is?
- What is the overall usage footprint?
- What’s the difficulty of the changeset/fix?
- How much friction is the issue causing?
- What's the overall time/effort cost of addressing the issue/need? etc...