These guidelines serve as a primary document for triaging incoming issues from contributors to the Traefik project. Projects are welcome to use this guidance as a starting point and customize to address specific triaging needs.
Issue triage is a process by which a project intakes and reviews new GitHub issues and requests, and organizes them to be actioned — usually by its own members. Triaging involves categorizing issues and PRs based on factors such as priority/severity, ownership of the issue, and the issue kind (bug, feature, etc.)
- Each project is responsible for handling their own issues or pull requests
Triaging occurs in regularly scheduled meetings and may occur asynchronously depending on the severity of the issue or PR
OSS maintainers who triage regularly say it:
- speeds up issue management
- keeps contributors engaged by shortening response times
- prevents work from lingering endlessly
- replaces "special requests" and one-offs with a neutral process that acts like a boundary
- leads to greater transparency, interesting discussions, and more collaborative, informed decision-making
- it helps build prioritization, negotiation and decision-making skills, which are critical to most tech roles
- it reinforces community and culture
Triaging empowers projects to maintain a steady, continuous flow of work that is assessed and prioritized based on feedback and value. The community benefits from this work by feeling their contributions and feedback is handled in a timely and professional manner.
This aims to walk you through a standard triaging process, first covering tools and tips.
Traefik utilizes many different automation tools to handle various tasks across our open source projects. In almost all cases, these bots take action based on certain activities being performed on our repositories such as commits, labels being applied, issues, and PRs being opened, and closed.
- Myrmica Aloba 🐜: Add labels and milestone on pull requests and issues.
- Myrmica Lobicornis 🐜: Update and Merge Pull Request
- Myrmica Bibikoffi 🐜: Closes stale issues
Traefiker Bot🐜: Internal bot used to interact with Issues and PRs
Project issues and labels are listed for each project here:
- Traefik issues
- Labels and their description
New, untriaged issues are assigned the label status/0-needs-triage automatically.
During the issue triage meeting, project leads could identify at least one team member to serve as the individual responsible for applying labels and assigning ownership for incoming issues that require any action.
Labels are the primary tools for triaging.
Depending on your permissions, either close or comment on any issues that are identified as support requests, duplicates, or not-reproducible bugs or that lack enough information from the reporter.
Some people mistakenly use GitHub issues to file support requests. Usually, they're asking for help in troubleshooting their configuration. In most cases, our bot will automatically respond to these issues, but not always. It is important we validate instances where the bot steps in and confirm the author is in fact asking a question.
In cases where it's been confirmed the author is asking a question and the bot did not intercede, direct the author to use our community forums, our documentation, or provide an answer directly.
Then apply the kind/question label and close the issue.
In some instances, issues that belong in another project are incorrectly opened by a reporter. These issues should either be closed or moved to the appropriate project.
The contributor/waiting-for-feedback label indicates an issue that needs more information in order to work on it; comment on or close it.
Do a quick duplicate search to see if the issue has been reported already.
If a duplicate is found, let the issue reporter know, reference the original issue, set the label resolution/duplicate, and close the duplicate.
If a reported issue is potentially a bug it should be labeled kind/bug/possible and depending on the potential severity of the issue assigned to a maintainer for investigation.
Maintainers will validate if the problem is a bug by trying to reproduce it.
If the bug can be reproduced:
- Change the label to
kind/bug/confirmed - Define its priority
If you can't reproduce it:
- Contact the issue reporter with your findings
- Close the issue if both the parties agree that it could not be reproduced
If you need additional information to continue working on the issue:
- Let the reporter know it by adding an issue comment followed by the label
contributor/waiting-for-feedback - Issues are automatically closed after 60 days if they receive no feedback from the contributor
Once triaged, issues should be assigned one of the following kind labels:
kind/bug/possibleorkind/bug/confirmedkind/enhancementkind/proposalsee Proposalskind/question
We use GitHub labels for prioritization.
We aim for consistency across the entire project. However, if you notice an issue that you believe to be incorrectly prioritized, please leave a comment offering your counter-proposal and we will evaluate it.
| Priority label | What it means | What that might include |
|---|---|---|
priority/P0 |
Team leaders are responsible for making sure that these issues (in their area) are being actively worked on—i.e., drop what you're doing. Stuff is burning. These should be fixed before the next release. | user-visible bugs in core features, broken builds / tests, and critical security issues |
priority/P1 |
Must be staffed and worked on either currently or very soon—ideally in time for the next release. Important, but wouldn't block a release. | third-party systems and dependencies, bumping ... |
priority/P2 |
Important over the long term, but may not be currently staffed and/or may require multiple releases to complete. Wouldn't block a release. | new providers, components, and enhancements to existing systems |
priority/P3 |
General agreement that this is can be a nice-to-have. Community contributions would be most welcome in the meantime, though it might take a while to get them reviewed if reviewers are fully occupied with higher-priority issue. | less requested features |
Issues that are prioritized at P1 or above should be assigned an owner who is responsible for completing the task and closing the issue.
If you think you can fix the issue, discuss the issue with the team, and only assign it to yourself after discussion. If you cannot self-assign for permissions-related reasons, ask a maintainer who has permissions for assignment and then work on creating a PR.
Any issue which is assigned an owner should be followed up on in a timely manner.
If the issue requires action by another maintainer or requires feedback from another contributor ping them in the issue with a @mention.
Based on the labels applied to the issue, it may be closed for the following reasons:
contributor/waiting-for-feedbackorcontributor/need-more-informationare automatically closed after 60 days of no activitykind/questionare automatically closed after 8 days with no activity- closed issues have
status/5-frozen-due-to-ageapplied automatically after 30 days of no activity
According to our Code of Conduct, abuse reports should be handled during the triage process as well.
These should be directed to the following: