[PATCH] D117832: Update the Bug Life Cycle docs for the switch to GitHub issues

Aaron Ballman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 21 04:32:48 PST 2022


aaron.ballman added inline comments.


================
Comment at: llvm/docs/BugLifeCycle.rst:54-56
+Bugs with a ``new issue`` label indicate that the issue stills need to be
+triaged. When triage is complete, the ``new issue`` label should be replaced by
+a ``confirmed`` label, unless the issue is being closed.
----------------
asl wrote:
> Quuxplusone wrote:
> > Any open bug without the [confirmed] label is a bug that still needs to be triaged. When triage is complete, if the bug isn't simply being closed, the bug should be labeled [confirmed].
> > The goal is that a bug marked [confirmed] is in a good, actionable state.
> > 
> > I would prefer not to mention the [new issue] label at all, here, since it isn't consistently applied to new issues and also isn't consistently removed from triaged issues. Also, we should strive to limit the amount of "process" involved here; "add this label" is 50% less process than "add this label and remove that label," especially when "that label" was merely added by a bot to begin with.
> > https://github.com/llvm/llvm-project/issues?q=label%3A%22new+issue%22
> > 
> > Reductio ad absurdam: We could change the "new issue" bot so that it also //removes// the [new issue] label from any bug that already possesses the [confirmed] tag, and/or from any bug that is closed. (Right now there are 42 closed bugs with the [new issue] tag.) We could also change the bot to //add// the [new issue] tag to any bug that is open but lacks [confirmed]. Basically we can let the bot run free with that label, and leave the humans to ignore it. :)
> As I already stated several times (and you consistently tend to forget / ignore this): the bot only puts "new label" in case if there are no labels at all. Any labels that are set on the issue will prevent labelling by the bot. So, the presence of any label is an indication that the issue was triaged. Note that only those who have write access can assign labels, so the presence of labels is an indication of triage already done by someone. As a result, no dedicated "confirmed" label is even necessary - labels other than "new issue" is such indication.
> As a result, no dedicated "confirmed" label is even necessary - labels other than "new issue" is such indication.

I strongly disagree that a lack of a `new issue` label indicates that something has been triaged properly. Users add labels to their bugs all the time when creating a bug -- a self confirmation is not the same thing as an independent confirmation. As examples:

https://github.com/llvm/llvm-project/issues/53335
https://github.com/llvm/llvm-project/issues/53329

These issues have labels, none of them have been triaged by anyone except the reporter. The latter one also demonstrates that the issue is not agreed upon as being confirmed.

Also, some folks are helpful and add labels to categorize issues after the initial report, but I don't believe this really constitutes a triage that confirms the report:

https://github.com/llvm/llvm-project/issues/53324
https://github.com/llvm/llvm-project/issues/53327

I continue to believe we need a `confirmed` label.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117832/new/

https://reviews.llvm.org/D117832



More information about the llvm-commits mailing list