luke
/
sbt
mirror of https://github.com/sbt/sbt.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated Issues gardening (markdown)

eugene yokota 2018-04-13 15:29:57 -04:00
parent f99efb1eef
commit d4771b29f0
1 changed files with 16 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
Issues-gardening.md

@ -38,7 +38,18 @@ The second phase is breaking the issue apart into smaller pieces; and separating
- Expectations - Expectations
- Notes (or Analysis) - Notes (or Analysis)
This is where an issue gardener can come in to help gather more information. The idea is to go back and figure out what Bob did before he observed the problem X, and also ask Bob what he expected to see. Through these parts, we can separate the facts (repro steps) from opinions (problems, expectations), and opinions from speculation. See also https://github.com/sbt/sbt/blob/1.x/CONTRIBUTING.md#what-to-report This is where an issue gardener can come in to help gather more information. The idea is to go back and figure out what Bob did before he observed the problem X, and also ask Bob what he expected to see. Through these parts, we can separate the facts (repro steps) from opinions (problems, expectations), and opinions from speculation.
A good contribution might be commenting:
> This issue was originally reported 3 years ago. I tried to reproduce this using 1.1.4, and the error message has improved enough.
> ```
> some error message.
> ```
>
> We should close this issue.
See also https://github.com/sbt/sbt/blob/1.x/CONTRIBUTING.md#what-to-report
#### Triage #### Triage
@ -48,6 +59,10 @@ The third phase is recognizing the severity of the issue. A contributor could he
In the fourth phase, we jump into _solution space_ and start adding more analysis to find out the cause, and seek for the bug fix. A useful information is figuring out _when_ the problem started happening, and _which pull request or commits_ introduced the issue. Once they are identified, the source code that was touched in the pull request is likely the first place you would look into for the fix. If you are familiar with the sbt code base, guiding a potential contributor about these information could be helpful. Be sure to use "may" or "might" if it's a guess. In the fourth phase, we jump into _solution space_ and start adding more analysis to find out the cause, and seek for the bug fix. A useful information is figuring out _when_ the problem started happening, and _which pull request or commits_ introduced the issue. Once they are identified, the source code that was touched in the pull request is likely the first place you would look into for the fix. If you are familiar with the sbt code base, guiding a potential contributor about these information could be helpful. Be sure to use "may" or "might" if it's a guess.
### "Help wanted" label
### Good First Issues ### Good First Issues
See [Good First Issues](../Good-First-Issues). See [Good First Issues](../Good-First-Issues).