How to handle GitHub issues

This document describes how the team will respond to GitHub issues.
Authored by Gene Johnston - @gejohnston
Adapted by Fernando Rijo Cedeno - @zFernand0

Engineering triage of an issue

The following actions will be taken by individual engineers as they categorize an issue for further action. Our approach reflects the guidelines in the Zowe TSC issue handling proposal.

• For each issue:
  • Add a GitHub label for Priority: priority-critical, priority-high, priority-medium, priority-low.
    • These priorities are defined in the Zowe TSC issue handling proposal which will eventually be incorporated into the Zowe TSC issue handling policy.
    • Take your best guess. It can be re-classified if we hold a review.
  • If the issue appears to be an enhancement:
    • Add the label “enhancement”.
  • If the issue appears to be a bug:
    • Add the label “bug”.
    • Add a label for Severity: severity-critical, severity-high, severity-medium, severity-low.
      • These severities are also defined in the Zowe TSC issue handling policy.
      • Take your best guess. It can be re-classified if we hold a review.
    • If we do NOT currently plan to address the issue in the next 2 quarters:
      • Add the label “for-review” (which will request that the team review the issue).
  • Confirm if the issue should be closed:
    • The issue is not a clear bug in the product.
    • There has been no activity in the issue for more than 12 months.
    • The issue has less than 10 up-votes.
    • You are unaware of any plans to address the issue in the current quarter, or in the next quarter.
    • The creator is NOT known to you as a high-profile / highly-motivated Zowe consumer.
    • Add the following comment to the issue:

      This enhancement has had no activity for 12 months. The issue also has less than 10 up-votes by the community. No action on this enhancement is targeted for the next 2 calendar quarters. Therefore, this enhancement is being closed. If you feel that this enhancement should continue to be available for community up-votes, you may reopen this issue.

    • If the issue is not reproducible, or a duplicate, add an appropriate comment.
    • Ensure that the issue priority is priority-low.
    • Close the issue as “not planned”. To gather statistics, we want to differentiate issues for which we deliver a change (Close as completed) and those issues that were administratively closed (Close as not planned).
• New Issues (on or after November 2022):
  • New issues that are created using the issue templates are automatically tagged “new” and either “bug” or “enhancement”.
  • If an issue template is not used, the issue is not tagged and should be manually reviewed and tagged appropriately.
  • Every two weeks, the team will evaluate new incoming issues.
    • The team will also evaluate issues of any age that have been labeled ‘for-review’ by an individual engineer.
    • The “new” label should be removed once priority is assigned.
    • The ‘for-review’ label should also be removed after the team completes its review.
    • The team may add the label ‘for-review-pm’ to bring an issue to the attention of Product Management, for possible further escalation.
  • The automation will make the following comment on the issue:

    Thank you for raising this issue.
    The community has 90 days to upvote 👍 the issue.
    If it receives 10 upvotes, we will move it to our backlog. If not, we will close it.

  • All issues should be reviewed at the next PI planning. Any issues with 10 upvotes should be discussed and prioritized, and tagged with the label “community-upvoted” to prevent the stale bot from marking the issue as stale.
  • If an issue is not marked with any of the following labels, the issue will be closed after 90 days of no activity. It may be reopened by a community member if they so choose.
    • community-upvoted
    • third-party
    • for-review
    • keep
    • security