Backlog. They should have appropriate group, priority and product category labels applied.
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 2 weeks.|
|needs investigation||Information has been provided by the user, but is waiting on the team to further dive in||The team member who added the label should try to find some time to investigate or engage other team members within 4 weeks.|
During triage additional labels should be added to indicate what part of the product is impacted by the issue. Descriptions for the labels that Distribution often uses can be found the Distribution Frequently Used Labels Page.
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
We are sorry you are having troubles. The provided issue description seems to indicate that the problem is not related to this project. Commonly this indicates other troubles such as network connectivity or filesystem permissions. For this reason, I will close this issue and recommend checking out [how to get further help](https://about.gitlab.com/get-help/) on the GitLab website. /close
If someone is asking for help with a bug that seems related to GitLab code other than Omnibus
We are sorry you are having troubles. The provided issue description seems to indicate that the problem is not related to Omnibus. For this reason, we are moving this report to a more appropriate issue queue. Please review the bug templates for the new project in case they require additional information to help diagnose the problem. We also recommend checking out [how to get further help](https://about.gitlab.com/get-help/) on the GitLab website.
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
Pipeline failures are a shared team responsibility and need to be handled as soon as possible by whomever is available. That said, the team member on triage duty has a responsibility to follow up on any failures which occured and provide a summarized tally in the Triage notes. Failures requiring follow up issue(s) should also be noted to increase team awareness. Those issues should be labeled with
Details on the various pipelines and jobs implemented by different projects under Distribution are listed below: