Note: An issue that has been assigned to a user, but has no milestone, is not triaged, but is considered the responsibility of that user, and is not part of our triage queue at this time.
See the CE documentation for an explanation of the severity labels.
|Label||What it means||How to handle it|
|awaiting feedback||Information has been requested from the user||If no reply has been received in two weeks, the issue can be closed.|
|maintainer-discussion||Issues for further discussion by project Maintainers||Projects maintainers should review status and provide input within 1 week.|
Issues for triaging can be identified using the following criteria:
Such issues can be listed using the issues filter
Distribution team implements issue triaging on a rotating schedule, where each person in the team gets assigned to do it for one week. This is done in the order of joining the company. The process which one follows while on issue triage duty can be summarized as follows
Issue triage rotation week of <starting date>
awaiting feedbacklabel was added and no response was received from submitter. Check out the issue list with
awaiting feedbacklabel for such issues and close them with the "for issues with no reply" response.
@gitlab-org/issue-triagein the comments.
needs investigationlabel to it.
maintainer-discussion. Example cases where maintainers should be notified with this label:
For Schedulinglabel so that it gets scheduled for one of the upcoming milestones (or even
Backlogmilestone). Also apply the severity labels as applicable.
<action>can be moved, closed, triaged, resolved or marked as needs investigation. This helps in keeping track of the issue triaged per week. Related issues feature of GitLab should not be used for this purpose as it generates an incorrect association between the issues.
/spendquick action feature of GitLab to track the time you spent in triaging issues. There are no hard limits for this, but a reasonable amount of time would be 3 to 5 hours a week.
Issue triage rotation week of <starting date>. Use the
Triagetemplate to fill in the description.
Copy and paste into issues where appropriate
If someone is asking for support in the omnibus-gitlab project, point them to the correct place to look
Provided description seems to point to this issue not being related to this project. This can be the case when installation and `gitlab-ctl reconfigure` run went without issues, but your GitLab instance is still giving 500 error page with an error in the log. For this reason, I will close this issue and you can check on [how to find further help](/get-help/) on the GitLab website. /close
If someone opened a ticket without enough information, make sure they use the
Bug template, and fill it in
We can't reproduce the issue with the information you provided here. Can you please use our `Bug` template to help gather more details? 1. Click on the pencil icon near the issue title to edit the description 1. From the **Choose a template** drop down, select the **Bug** template 1. Read the template, and provide as much information as you can that we ask for 1. Click on the **Save changes** button to apply your changes. 1. Add a comment mentioning you updated the description. /label ~"awaiting feedback"
If an issue has been labeled
awaiting feedback for two weeks, and we haven't received a response, it can be closed
We haven't heard back from you, so we're going to go ahead and close the issue. If you're still experiencing the problem, please re-open the issue and provide the requested information. /close
If an issue was closed for no reply and someone comments who is not the original reporter, we ask them to open a new issue. Be sure to tag the contributor who made the comment.
Thank you for letting us know about your issue COMMENTOR. Unfortunately, this issue was already closed. Please [open a new issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/new?issue) following the ***BUG*** template and mark this closed issue as related.
If an issue appears to need review directly by a project maintainer to ascertain relevance,
I'm going to ask that this issue be reviewed by the project maintainers directly. This is so that we can make the most accurate decision regarding further work and viability. /label ~maintainer-discussion