[PATCH] D53691: Introduce bug life cycle documentation.

[Kristof Beyls via Phabricator via llvm-commits]

kristof.beyls added inline comments.


================
Comment at: docs/BugLifeCycle.rst:68
+
+  * Use the “See also”/”depends on”/”blocks” fields if so.
+  * Close it as a duplicate if so, pointing to the issue it duplicates.
----------------
rnk wrote:
> These seem to render as smart quotes. As long as it's UTF-8, this is probably fine, but they scare me. :) Up to you if you want to keep them.
D'Oh - I'll fix that to use ASCII quotes.


================
Comment at: docs/BugLifeCycle.rst:87-88
+
+Please remember to assign the bug to yourself if you're actively working on
+fixing it and to unassign it when you're no longer actively working on it.
+
----------------
tstellar wrote:
> The alternative would be using the "Assigned" and "New" bug states to indicate that a bug is assigned or not assigned.  The downside of this is that it's an extra step that people might forget when assigning bugs to themselves, but the advantage is that we wouldn't need the pseudo accounts for unassigned bugs which make the bugs more invisible than if they have a real assignee.
> 
> If we do want to keep using the pseudo accounts, I think we should just pick one to use (unassignedbugs at nondot.org) and document that here.
I think we could only remove the pseudo accounts and introduce real assignees if we could find volunteers for every single component that exists to become the default assignee. It seems uncertain to me we'll always have volunteers for that for all components, given the state we are in today.
Therefore, I think I want to opt for continuing to use the pseudo account for now. If we start having evidence that we can assume there will always be a volunteer to be default-assigned to for every component, we can reconsider this.
I agree that we only need a single pseudo account; not two (unassignedclangbugs at nondot.org is the other one I've seen. Not sure if there are more).


================
Comment at: docs/BugLifeCycle.rst:103-104
+* There is a sound reason for not fixing it (WONTFIX).
+* There is a specific and plausible reason to think that a given bug is
+  otherwise inapplicable or obsolete.
+
----------------
rnk wrote:
> rnk wrote:
> > What about this scenario:
> > - User reports bug with vague reproduction instructions
> > - Bug languishes for one year
> > - Developer does a pass over open bugs, tries to reproduce, but is unable to because there never was a clear, confirmed repro in the older version of llvm.
> > 
> > I think our policy should encourage us to close such bugs with some sort of "stale / instructions unclear / needsinfo" status along with a request for more information. The point is to put the bug into a state that says that no further action will be taken by LLVM developers unless the original reporter does something. For old bugs, chances are they won't.
> > 
> > I think as long as we encourage reporters to reopen if they have more info and can still reproduce the bug, this won't be discouraging to reporters. If the bug languished for a year, it's best to acknowledge that nothing happened and nothing is likely to happen without more information.
> > 
> > I believe this would be a better policy than asking developers to ping stale bugs for more info from the OP while leaving the bug open. That just leaves the bug open and means it will come up during the next bug scrub, requiring more developer time to close it out if there was no response.
> > 
> > Looking at our current resolution statuses, I guess I'd close bugs that we were never able to confirm were bugs with "WORKSFORME".
> My previous comment is my opinion, and I don't think it reflects the consensus of the last llvm-dev discussion we had about this, so don't let it block the document, which I think is important. We can keep discussing policy after we have a doc.
Looking back at the last llvm-dev discussion, my impression is actually that most people were in favour of something along the lines of what you're proposing. Let me have a stab at concisely writing something up that hopefully encodes consensus.


Repository:
  rL LLVM

https://reviews.llvm.org/D53691