How to handle GitHub issues - zowe/zowe-explorer-vscode GitHub Wiki

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.
    • 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:

        The squad has reviewed this issue and determined the request lacks sufficient appeal for the broader Zowe community.

        While no dev work by the squad is planned for this item, we welcome contributions from the community for squad review. For now, this enhancement is being closed.

      • 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, or the team decides the issue is high priority, 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
      • priority-critical
      • priority-high
      • severity-critical
      • severity-high

zowe/vscode-extension-for-zowe

⚠️ **GitHub.com Fallback** ⚠️