Handling Issues (Go Tracer)

This document explains how the Go Tracer team handles dd-trace-go's github issues. Other teams (i.e. profiler, appsec) may handle issues differently once issues are transferred to them.

Comment Templates

There are several comment templates throughout this document. These comment templates are there to make things quicker and easier for the gardeners handling issues, not to strictly enforce templated communication. They can be customized or ignored as appropriate for any issue.

Issue States

Any issue must be in one of the following states. States are determined by the labels applied to the issue. Project contributors move issues from one state to another. The intent behind these explicit states is to indicate the (minimum) next steps required to bring the issue to resolution. Issues may move between states in any order, as dictated by the needs of the particular issue.

Issues should ideally be in exactly one of the following states, so when transferring issues, please remember to remove the old state.

(no state)

• Issue does not contain one of the state labels below, or does not contain a team label.
• The issue has been filed.
• May not be correctly formatted (title, etc).
• To transition out of this state, one of the following must happen:
  • It must move into one of the other teams' states (profiler, appsec, apm:ecosystem, tracer), to let them handle it.
  • Someone must clean up the issue according to our Contribution Guidelines, apply the tracer label, and move it into one of the other states.

profiler

• Transition an issue here for it to be handled by the Profiling team.

appsec

• Transition an issue here for it to be handled by the Application Security Management team.

apm:ecosystems

• Transition an issue here if it's related to a tracing library integration (i.e. in contrib/*)

tracer

• Transition an issue here if it's related to the tracer (i.e. in ddtrace/*)

needs-investigation

• Is correctly formatted.
  • The title has a path prefix.
  • The body describes the issue.
  • May also have the label waiting-for-info if the investigator is waiting for more information from someone (e.g., the issue reporter).
• To transition from this state, someone must examine the issue and confirm that it is valid, and not a duplicate of an existing issue.

needs-fix

• This issue is a confirmed bug, but the work to fix it has not been done.
  • May have the labels blocked or waiting-for-info.
• Must create a corresponding Jira ticket in the internal tracker, with a link to the github issue.
• To transition from this state, someone must do the work to fix the issue.

fixed

• The issue is a resolved bug. No further attention is required.
• The issue should be updated with a comment explaining that the bug is resolved and when it will be released.

Template:

This bug has been resolved in [PR number] and will be released in [dd-trace-go version].

• The issue is closed.

question

• The issue is a question from a user, and there is no work to be done.
• The issue can (and will probably usually) have the waiting-for-info label attached to it, indicating that we are waiting for further info from the user.
• Questions answered to satisfaction can be moved to done.

proposal

• The issue is a feature proposal
• May also have the label waiting-for-info if the investigator is waiting for more information from someone (e.g., the issue reporter).
• An issue in proposal state needs a decision on whether or not the work should actually be done.

proposal/accepted

• This proposal has been accepted, and we plan on doing the work.
• This does not mean that the work is scheduled. Once the work is scheduled, the issue should transition into the scheduled state.

proposal/rejected

• This proposal has been rejected, and we do not plan on doing the work.
• When the proposal/rejected label is applied, we should close the issue with a reason.

Template:

We cannot accept this proposal because [short description of rejection reason]. For more assistance or to request features we cannot accept here, please contact Datadog support at https://www.datadoghq.com/support/

scheduled

• This was a proposal, which has now been scheduled as part of our quarterly planning.
• Along with the scheduled label, we should apply a label for the quarter this is scheduled for, in the format {YEAR}Q{N}, i.e. 2023Q3. Create the label if it does not already exist.
• Do not move issues into this state until they are confirmed and approved for the quarter they are in.
• Do not move issues into this state until there are internal tickets created and in the correct quarter.
  • Internal issues should point back to the github issue.

done

• The issue is resolved. No further attention is required.
• The issue should be closed.
• The issue is a proposal/feature that has been done, in which case, add a comment:

Template:

This has been implemented in [PR number] and will be released in [dd-trace-go version].

• The issue is a question or other non-bug that has been resolved for the reporter.

Template:

We are marking this issue as done. If there is more we can do to help, please file an issue or contact Datadog support at https://www.datadoghq.com/support/

• The issue in question is more than 3 months old AND has the waiting-for-info label.

Template:

We are closing this issue since it has gone stale. If you still need help with this, please feel free to re-open the issue or file a new one.

• The issue is a duplicate.

Template:

We are closing this issue as a duplicate of [issue number]. Please follow progress there.

An issue may be closed at any time, with a comment to indicate the reason for closure.