raboof/pekko
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions 10

Clarify 'bug' gh tag is for potential prod issues (#28633)

Browse source
This commit is contained in:
Arnout Engelen 2020-03-02 14:32:10 +01:00 • committed by GitHub
parent 01c9ae5499
commit 335d205782
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 2 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

4
CONTRIBUTING.md
View file

@ -46,8 +46,8 @@ Another group of tickets are those which start from a number. They're used to si
The last group of special tags indicate specific states a ticket is in:
- [bug](https://github.com/akka/akka/labels/bug) - bugs take priority in being fixed above features. The core team dedicates a number of days to working on bugs each sprint. Bugs which have reproducers are also great for community contributions as they're well isolated. Sometimes we're not as lucky to have reproducers though, then a bugfix should also include a test reproducing the original error along with the fix.
- [failed](https://github.com/akka/akka/labels/failed) - tickets indicate a Jenkins failure (for example from a nightly build). These tickets usually include a stacktrace + link to the Jenkins failure, and we'll add a comment when we see the same problem again. Since these tickets can either indicate tests with incorrect assumptions or legitimate issues in the production code we look at them periodically. When the same problem isn't seen again over a period of 6 months we assume it to be a rare flaky test or a problem that might have since been fixed, so we close the issue until it pops up again.
- [bug](https://github.com/akka/akka/labels/bug) tickets indicate potential production issues. Bugs take priority in being fixed above features. The core team dedicates a number of days to working on bugs each sprint. Bugs which have reproducers are also great for community contributions as they're well-isolated. Sometimes we're not as lucky to have reproducers though, then a bugfix should also include a test reproducing the original error along with the fix.
- [failed](https://github.com/akka/akka/labels/failed) tickets indicate a Jenkins failure (for example from a nightly build). These tickets usually include a stacktrace + link to the Jenkins failure, and we'll add a comment when we see the same problem again. Since these tickets can either indicate tests with incorrect assumptions or legitimate issues in the production code we look at them periodically. When the same problem isn't seen again over a period of 6 months we assume it to be a rare flaky test or a problem that might have since been fixed, so we close the issue until it pops up again.
Pull request validation states: