New bug form and triage workflow (#3058)
This commit is contained in:
Daniel Dyla
GitHub
parent
0727ed74e8
commit
43783038cc
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
name: Bug report
|
||||
about: Create a report to help us improve
|
||||
labels: bug
|
||||
---
|
||||
|
||||
Please answer these questions before submitting a bug report.
|
||||
|
||||
### What version of OpenTelemetry are you using?
|
||||
|
||||
### What version of Node are you using?
|
||||
|
||||
### Please provide the code you used to setup the OpenTelemetry SDK
|
||||
|
||||
### What did you do?
|
||||
|
||||
If possible, provide a recipe for reproducing the error.
|
||||
|
||||
### What did you expect to see?
|
||||
|
||||
### What did you see instead?
|
||||
|
||||
### Additional context
|
||||
|
||||
Add any other context about the problem here.
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
name: Bug Report
|
||||
description: File a bug report
|
||||
labels: ["bug", "triage"]
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
Thanks for taking the time to fill out this bug report!
|
||||
Please make sure to fill out the entire form below,
|
||||
providing as much context as you can in order to help us
|
||||
triage and track down your bug as quickly as possible.
|
||||
|
||||
Before filing a bug, please be sure you have searched through
|
||||
[existing bugs](https://github.com/open-telemetry/opentelemetry-js/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Abug)
|
||||
to see if your bug is already addressed.
|
||||
|
||||
If your bug is related to an instrumentation or plugin in [opentelemetry-js-contrib](https://github.com/open-telemetry/opentelemetry-js-contrib)
|
||||
please be sure to file it there.
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: What happened?
|
||||
description: Please provide as much detail as you reasonably can.
|
||||
value: |
|
||||
## Steps to Reproduce
|
||||
|
||||
## Expected Result
|
||||
|
||||
## Actual Result
|
||||
|
||||
## Additional Details
|
||||
|
||||
validations:
|
||||
required: true
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: OpenTelemetry Setup Code
|
||||
description: Please provide the code you use to set up OpenTelemetry
|
||||
placeholder: | # This comes from our README.md
|
||||
// tracing.js
|
||||
|
||||
'use strict'
|
||||
|
||||
const process = require('process');
|
||||
const opentelemetry = require('@opentelemetry/sdk-node');
|
||||
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
|
||||
const { ConsoleSpanExporter } = require('@opentelemetry/sdk-trace-base');
|
||||
const { Resource } = require('@opentelemetry/resources');
|
||||
const { SemanticResourceAttributes } = require('@opentelemetry/semantic-conventions');
|
||||
|
||||
// configure the SDK to export telemetry data to the console
|
||||
// enable all auto-instrumentations from the meta package
|
||||
const traceExporter = new ConsoleSpanExporter();
|
||||
const sdk = new opentelemetry.NodeSDK({
|
||||
resource: new Resource({
|
||||
[SemanticResourceAttributes.SERVICE_NAME]: 'my-service',
|
||||
}),
|
||||
traceExporter,
|
||||
instrumentations: [getNodeAutoInstrumentations()]
|
||||
});
|
||||
|
||||
// initialize the SDK and register with the OpenTelemetry API
|
||||
// this enables the API to record telemetry
|
||||
sdk.start()
|
||||
.then(() => console.log('Tracing initialized'))
|
||||
.catch((error) => console.log('Error initializing tracing', error));
|
||||
|
||||
// gracefully shut down the SDK on process exit
|
||||
process.on('SIGTERM', () => {
|
||||
sdk.shutdown()
|
||||
.then(() => console.log('Tracing terminated'))
|
||||
.catch((error) => console.log('Error terminating tracing', error))
|
||||
.finally(() => process.exit(0));
|
||||
});
|
||||
render: "JavaScript"
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: package.json
|
||||
description: If possible, please provide your full package.json. If not, please provide at least your list of dependencies and their versions, especially OpenTelemetry versions.
|
||||
render: "JSON"
|
||||
placeholder: |
|
||||
{
|
||||
"name": "my-app",
|
||||
"scripts": {
|
||||
"start": "node -r tracing.js app.js"
|
||||
},
|
||||
"dependencies": {
|
||||
"@opentelemetry/api": "^1.2.0",
|
||||
"@opentelemetry/sdk-trace-base": "~1.3.1",
|
||||
...
|
||||
}
|
||||
}
|
||||
- type: textarea
|
||||
attributes:
|
||||
label: Relevant log output
|
||||
description: |
|
||||
Please copy and paste any relevant log output.
|
||||
render: shell
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
# OpenTelemetry Bug Triage
|
||||
|
||||
This procedure describes the steps project maintainers and approvers should take to triage a bug report.
|
||||
|
||||
Bugs should be created using the [Bug Report](https://github.com/open-telemetry/opentelemetry-js/issues/new?template=bug_report.yaml) issue template.
|
||||
This template automatically applies the `bug` and `triage` labels.
|
||||
|
||||
## Gather Required Information
|
||||
|
||||
The first step is to ensure the bug report is unique and complete.
|
||||
If the bug report is not unique, leave a comment with a link to the existing bug and close the issue.
|
||||
If the bug report is not complete, leave a comment requesting additional details and apply the `information-requested` label.
|
||||
When the user provides additional details, remove the `information-requested` label and repeat this step.
|
||||
|
||||
## Categorize
|
||||
|
||||
Once a bug report is complete, we can determine if it is truly a bug or not.
|
||||
A bug is defined as code that does not work the way it was intended to work when written.
|
||||
A change required by specification may not be a bug if the code is working as intended.
|
||||
If a bug report is determined not to be a bug, remove the `bug` label and apply the appropriate labels as follows:
|
||||
|
||||
- `documentation` feature is working as intended but documentation is incorrect or incomplete
|
||||
- `feature-request` new feature request which is not required by the specification, but is allowable by specification rules
|
||||
- `spec-feature` change required by the specification which adds a new feature or extends an existing feature with new functionality
|
||||
- `spec-inconsistency` an existing feature incorrectly or incompletely implements the specification - may or may not also be a bug
|
||||
|
||||
## Prioritize
|
||||
|
||||
For bugs and specification required changes, apply a priority label as follows.
|
||||
Each bug should have only a single priority label which is the highest priority that applies.
|
||||
For example, a bug which satisfies the conditions for both `p2` and `p3` labels should only receive the `p2` label.
|
||||
|
||||
- `p1` bugs which cause problems in end-user applications such as crashes, data inconsistencies, or memory leaks which grow unbounded
|
||||
- `p2` bugs and specification inconsistencies which cause telemetry to be incorrectly or incompletely reported
|
||||
- `p3` bugs which cause problems in end-user applications not related to correctness such as performance issues or high memory use
|
||||
- `p4` bugs and specification inconsistencies which do not fall into any of the above categories
|
||||
|
||||
## Schedule
|
||||
|
||||
The final step is to determine a reasonable timeline for a bug to be fixed.
|
||||
`p1` and `p2` issues should be fixed as quickly as possible.
|
||||
These bugs should be either immediately assigned to the appropriate person, or added to the agenda for the next SIG meeting where they will be assigned.
|
||||
`p3` and `p4` issues may be addressed less urgently than `p1` and `p2` issues.
|
||||
If they are not urgent the `up-for-grabs`, `good-first-issue`, or other similar labels may be applied as appropriate.
|
||||
|
||||
## Triage Complete
|
||||
|
||||
The final step is to remove the `triage` label.
|
||||
This indicates that all above steps have been taken and an issue is ready to be worked on.
|
||||
Loading…
Reference in New Issue