Skip to content

Automating Team Sign-Off with Open Bug Acknowledgment #30841

Open
@vpintorico

Description

@vpintorico

What is this about?

We want to formalize our release sign-off process within GitHub by automatically prompting each team to acknowledge their outstanding bugs before confirming sign-off. Specifically, when a team checks its “sign-off” checkbox in a release PR description, an automated workflow should pull the list of open bugs labeled with both the release (e.g., regression-RC-7.42) and the team (e.g., team-assets), then prompt the team to accept or cancel the acknowledgment. Those unresolved bugs will be recorded in a PR comment for transparency and accountability if accepted.

Scenario

As a team member responsible for release sign-off,
I want an automated prompt that shows me all unresolved bugs relevant to my team when I check my sign-off box,
so that I can clearly see which issues remain outstanding, accept accountability for them, and ensure that the release decision is transparent.

Scenario

  1. A release PR is created with a description that includes a Team Sign-Off checklist, for example:
# Team sign-off checklist
- [ ] Accounts
- [ ] Assets
  1. When the Assets team checks its box:
  • A GitHub Actions workflow detects the checkbox update and fetches all open issues labeled with:
    -- regression-RC-7.42
    -- team-assets
    -- type-bug
  • A window or confirmation prompt informs the Assets team how many unresolved bugs exist, broken down by severity (e.g., sev0, sev1, sev2, sev3).
  • It then asks the team to either confirm or cancel their acknowledgment.
  1. Upon confirmation:
  • The workflow posts a final comment listing the open bugs by severity and stating that Assets team has officially acknowledged these unresolved issues.
  • If the team cancels, no final acknowledgment is recorded, and the PR remains unapproved by that team.

Design

No response

Technical Details

No response

Threat Modeling Framework

No response

Acceptance Criteria

Acceptance Criteria

1. Automatic Detection

  • When a team’s box is checked in the PR, the workflow automatically fetches open issues matching the relevant labels (release, team, bug).

2. Severity Breakdown

  • The system accurately classifies unresolved bugs by severity (e.g., sev1, sev2) in the prompt and the final comment.

3. Confirmation Flow

  • The process includes an interactive step, enabling teams to confirm or cancel their acknowledgment.
  • A final, visible comment is posted only if acknowledgment is confirmed.

4. Transparency & Traceability

  • The final posted comment remains on the PR, documenting the team’s acceptance of shipping with those open bugs.

5. Minimal Overhead

  • Once the box is checked, the only additional actions should be a quick prompt review and a slash command for confirmation or cancellation. No extra manual steps are required.

Stakeholder review needed before the work gets merged

  • Engineering (needed in most cases)
  • Design
  • Product
  • QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
  • Security
  • Legal
  • Marketing
  • Management (please specify)
  • Other (please specify)

References

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions