-
Notifications
You must be signed in to change notification settings - Fork 94
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
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).
- Add a GitHub label for Priority: priority-critical, priority-high, priority-medium, priority-low.
-
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
Welcome
Using Zowe Explorer
Roadmaps
Development Process
Testing process
Release Process
Backlog Grooming Process
How to Extend Zowe Explorer
- Extending Zowe Explorer
- Using Zowe Explorer Local Storage
- Error Handling for Extenders
- Secure Credentials for Extenders
- Sample Extender Repositories
Conformance Criteria
v3 Features and Information