-
Notifications
You must be signed in to change notification settings - Fork 436
Tracer Gardening
"Gardening" in open source projects refers to the background maintenance tasks done to keep the project healthy & growing & nice looking.
This details how the tracer team performs "gardening" on the dd-trace-go repository.
Before doing any gardening work, especially on the issue tracker, remember to familiarize yourself with the issues life-cycle, described here: Handling Issues - Issue States.
Look at the badges on the README.md and investigate any test failures on the main branch. Forward failures in other teams' tests to them via #guild-dd-trace-go
Look at the untriaged issues.
While triaging the issue:
- is it a duplicate? Close it, moving to
donestate & leave an appropriate comment from a template. - is the subject the correct format?
- If it is a bug, the title should start with the package path and a colon: "net/http: fix crash in Server during foo operation".
- If it is a proposal, the title should be "proposal: [brief description of the proposed feature]".
- What team does this work belong to?
- apply one of the team labels.
When the issue has been triaged, if the work is for the tracer team, add an appropriate label per https://github.com/DataDog/dd-trace-go/wiki/Handling-Issues-(Go-Tracer)#issue-states to mark it as such.
Find issues that are in state waiting-for-info and ping them, remove the label if there have been replies, or close issues that have not received a reply in 3 months or more. You do not have to respond to the new info. We can do that later. Merely removing the waiting-for-info label is enough.
Find issues that are questions without the waiting-for-info label and answer them, shifting them to either waiting-for-info or done as appropriate.
Find issues that are in the needs-investigation state (without the waiting-for-info label) and decide if it is valid, and what kind of issue (bug, proposal, question) it is. Issues should be moved out of this state according to the guidelines here
Any issues in the proposal/rejected, done, or fixed states which are not closed should be closed with a comment such as one of the templates in the Handling Issues doc.