Updated Issues gardening (markdown)

Issues-gardening.md

@@ -16,7 +16,37 @@ Often, we get into a meta discussion of "ok. but not this forum." Let's call thi
 
 Basically, by the time the problem is happening, it's counter-productive to engage in the Choice of forum discussion. (Exception may be if someone tries to contact you personally without invitation) But let's say if there's a lively discussion going on in Twitter/Gitter, the best you can do would be to gather as much as information there instead of trying to move the forum elsewhere.
 
-Once the discussion has settled, you can then gather up the info, and re-post them yourself; or ask them if they are up for reposting the information to GitHub Issues or Discuss, if you think it needs further investigation.
+Once the discussion has settled, you can then gather up the info, and re-post them yourself; or ask the original reporter if they are up for reposting the information to GitHub Issues or Discuss, if you think it needs further investigation.
+
+### Lifecycle of an Issue
+
+It's important to recognize that an issues goes through a lifecycle, in terms of the completeness of the information. Let's call our user Bob.
+
+1. Something happens on Bob's computer. (Operation X is slow, there's an error etc.)
+2. Bob observes the event, and maybe thinks about it.
+3. Bob verbalizes the event as an issue.
+
+#### Initial capture
+
+Depending on how Bob has been trained as a QA engineer, he might express the problem in a different way. One way Bob may express this is "sbt needs to update Apache DonkeyKick to 1.2." (Note sbt doesn't use Apache DonkeyKick.) Normally, what we get from Bob is his observation like "Operation X is slow" This is the initial phase of the issue.
+
+#### Sifting for the facts
+
+The second phase is breaking the issue apart into smaller pieces; and separating into four parts:
+- Reproduction steps
+- Problems
+- Expectations
+- 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
+
+#### Triage
+
+The third phase is recognizing the severity of the issue. A contributor could help out in highlighting the severity of the issue, by commenting on GitHub issue or get maintainer's attention through Gitter etc. During this phase, prioritization might also take place (Note severity and prioritization are independent, also known as "triage"). Also note that thus far, the issue lives mostly in what I call _problem space._
+
+#### Leaving breadcrumbs
+
+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.
 
 ### Good First Issues