Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automating Team Sign-Off with Open Bug Acknowledgment #30841

Open
9 tasks
vpintorico opened this issue Mar 6, 2025 · 0 comments
Open
9 tasks

Automating Team Sign-Off with Open Bug Acknowledgment #30841

vpintorico opened this issue Mar 6, 2025 · 0 comments
Labels
team-dev-ops DevOps team

Comments

@vpintorico
Copy link

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

@vpintorico vpintorico added the team-dev-ops DevOps team label Mar 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-dev-ops DevOps team
Projects
None yet
Development

No branches or pull requests

1 participant