Skip to content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

Software Support

This document provides information about the software support process. That is, how our development team goes about addressing these issues. Including scheduling, project management tools and practices, issue soliciation, issue selection, and prioritization.

How to Submit Issues

Our code is managed via GitHub

Any issues with our software portfolio should be tracked in our repos through GitHub issues. Links for some our more active repos:

Support Sprint Process

Support sprints are dedicated efforts, time-boxed to 3 weeks quarterly. We schedule these as part of our internal scheduling procedures. Support sprints are scheduled 3 to 6 weeks ahead of time. A public prioritization meeting is scheduled prior to starting a support sprint. A notification of this meeting will be made (see below for how to subscribe) to the support mailing list 3 to 6 weeks ahead of time.

How do I get Notified of Support Sprints and prioritization meetings?

We email anyone who has opted in to our software support newsletter which includes when the support sprint was scheduled, when the prioritization meetings are happening, and a link to the meeting. These are sent shortly after it's scheduled and again right before the meeting.

Sign up here.

Step 1: Scheduling the Support Sprint

While there is some leeway in the exact timing of each support sprint, the sprints must be scheduled quarterly and should be scheduled roughly 3 months apart. Project scheduling should be coordinated by the project/technical lead and the software lead during routine software scheduling meetings.

After setting up the sprint schedule, we create a software support board and communicate the schedule to contributors. The prioritization meeting should be scheduled some day the week before the support sprint.

Step 2: Setting up the Project Board

Immediately after scheduling the support sprint, the technical lead should create a project board to facilitate the tracking, prioritization, and assignment of issues. This has traditionally taken the form of a GitHub projects board or a GitHub discussion post, both of which provide automated tracking for issues that are hosted on GitHub.

Step 3: Notifying the Community

The community is notified via an email sent to anyone subscribed to the newsletter.

This email should include:

  1. The time of the prioritization meeting
  2. Link to the meeting, a new meeting should be created every time via MS Teams.
  3. The purpose of the meeting
  4. The start / end date of the sprint
  5. A solicitation for issues that are significant to the community
  6. Instructions on getting issues added to the board.
Optional Boilerplate Email for MS Teams Calendar Event

This meeting will be used to prioritize the issues found at < link to project board > for the upcoming support sprint scheduled < date range of support >. The list of issues found on the project board is currently incomplete. If the list doesn't contain work that you would like to see scheduled during this sprint, then feel free to add items to the list. For contributors outside the ASC, please note that organizational policy does not currently allow read/write access to internal project boards. If you'd like work to be scheduled during this sprint, please ensure that an issue has been created and email me at < your email > to get the work scheduled.

Step 4: Selecting Additional Issues

Despite community engagement, contributors do not generally produce enough issues to ensure that there is enough work to fill the sprint. In this case, the technical lead should select additional issues. While these issues are chosen at the discretion of the technical lead, the following generally make good candidates for support sprints:

  • Bug fixes
  • Issues with significant community engagement
  • Issues tagged with "missions" or "products"
  • Issues that have a proposed solution
  • Issues that appear to have an easy fix
  • Issues with an existing PR

While there is no correct number of issues for each support sprint, support sprints typically include 35 - 50 issues.

Step 5: Prioritizing Issues

Prioritization meetings are typically a loosely guided discussion in which the technical lead acts as the facilitator. Prioritization meetings generally follow a format such as:

  1. Ask attendees if there are any last-minute issues that should be added.
  2. Introduce and prioritize issues. If the issue creator is in attendance, call on them for an issue summary and their perspective on relative importance. If the creator is not in attendance, the technical lead should be prepared to offer a summary / context on the issue and ask the community about the importance of the issue.
  3. When all issues are prioritized, revisit any issues that may need additional discussion.
  4. Ask for any closing remarks
Issue deferral

Deferring an issue generally means "this is a good, important issue, but it requires further discussion." This discussion should not interrupt the flow of prioritization.