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.|
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.
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 at the [GitLab website](/getting-help/). /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 `/unlabel ~"awaiting feedback"` to let us know that the issue is ready for another look /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