Skip to content

Latest commit

 

History

History
70 lines (61 loc) · 10.4 KB

triage_process.md

File metadata and controls

70 lines (61 loc) · 10.4 KB
Raw

Issue and PR Lifecycle and Triage Process

The community holds meetings regularly to triage issues and pull requests across the ManageIQ organization’s repositories. Attendees include code owners and mergers for the repositories, but all are invited to attend.This is not a meeting to assign when work will be done.

Triage meetings are divided into two groups General and API/UI.

Triage Category Core/Provider Link UI/API Link
Unassigned issues Core/Provider unassigned issues UI/API unassigned issues
Assigned issues without scope label Core/Provider issues without scope label UI/API issues without scope label
Stale issues Core/Provider stale issues UI/API stale issues
Unassigned pull requests Core/Provider unassigned pull requests UI/API unassigned pull requests
Assigned pull requests without scope label Core/Provider assigned pull requests without scope label UI/API assigned pull requests without scope label
Stale pull requests Core/Provider stale pull requests UI/API stale pull requests

Issue Triage

  • Triage unassigned issues
    • Assign the issue. There are three possible scenarios.
      • Assign someone to at least get in on the radar. This does not mean that the assignee is expected to start work on the issue.
      • Apply the help wanted label. This means that while the issue is valid, the team does not have plans to work on it in the near future.
      • Do not assign to anyone and revisit the issue. In other words, we want to be sure that the issue does not get ignored in perpetuity.
    • Close invalid issues with a comment and/or label as to why it has been closed.
  • Review issues with assignee, but no scope label.
  • Review stale issues
    • Bug label
      • If the bug is stale, but not verified, will decide during triage if it should be closed.
      • If the bug is not reproducible, comment back to the opener of the issue for more info. If there is no response, then close after it goes stale.
    • Question label
      • Should not go stale.
      • Can either be answered and closed OR converted to another scope label such as enhancement or bug with appropriate renaming of the issue title.
    • All other scope labels
      • Should never go stale, either pin or close.
      • If the item is considered reasonable, the issue should be labeled pinned to prevent the stale label from being applied.

Pull Request Triage

  • Review unassigned pull requests.
    • Apply scope labels
    • Assign the pull request. There are three possible outcomes.
      • Assign someone to at least get in on the radar. This does not mean that the assignee is expected to start work on the issue.
      • Apply the help wanted label. This means that while the issue is valid, the team does not have plans to work on it in the near future.
      • Do not assign to anyone and revisit the issue. In other words, we want to be sure that the issue does not get ignored in perpetuity.
  • Review assigned PRs with no scope label.
  • Review stale PRs.
    • Bump via @mention after 1 month of no activity
    • Apply stale label after 3 month of no activity
    • After turns stale and 3 months, close the PR.
    • Stale and unmergeable PRs are closed automatically.