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

Fri Jan 21 09:15:09 PST 2022

aaron.ballman added inline comments.

================
Comment at: llvm/docs/BugLifeCycle.rst:44

-Make sure that you have one or more people on cc on the bug report that you
-think will react to it. We aim to automatically add specific people on cc for
-most products/components, but may not always succeed in doing so.
-
-If you know the area of LLVM code the root cause of the bug is in, good
-candidates to add as cc may be the same people you'd ask for a code review in
-that area. See :ref:`finding-potential-reviewers` for more details.
-
+You can apply labels to the bug to provide extra information to make the bug
+easier to discover, such as a label for the part of the project the bug
----------------
Quuxplusone wrote:
> Argh, sorry for the multi-posting as I keep thinking of things to say here!
> 
> Let's make "labels" a hyperlink to https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels
> which incidentally describes the meanings of GitHub's default labels.
> 
> The only one of them where it appears we're not using it as its "originalist" meaning is [question], which apparently "originally" meant something like "The maintainer has a question for the submitter" but in our case we're clearly using it to tag, duh, questions. https://github.com/llvm/llvm-project/labels/question  I would be very cool with burninating [question] and merging it into [invalid]; is that too harsh? :)
> 
> I'm relatively cool with the idea of tagging everything as either [bug] or [enhancement], but it's going to make for a lot of tough calls in practice. Right now we also have [new-feature] and [missing-feature], which I think are arguably the same as [enhancement]?
> How would you categorize "Your `-std=c++20` mode doesn't support half of C++20" — //bug//, or request for someone to implement the missing //features//? Further, consider "This existing feature is good but it could be better," versus "This feature doesn't exist today but I would like it to exist." Are those both "enhancements" or is there a category difference worth reflecting in the labels?  Basically all [clang:diagnostics] issues are both-bug-and-feature-request in this way.
I added the link to labels and then removed the part about `bug` and `enhancement`.

================
Comment at: llvm/docs/BugLifeCycle.rst:80

-* CC others not already cc’ed that you happen to know would be good to pull in.
-* Add the "beginner" keyword if you think this would be a good bug to be fixed
+* Add the ``beginner`` label if you think this would be a good bug to be fixed
   by someone new to LLVM.
----------------
probinson wrote:
> Quuxplusone wrote:
> > As Tom says, please use [good first issue] here instead. It is meaningful to GitHub: it populates https://github.com/llvm/llvm-project/contribute and several third-party websites aimed at new FOSS contributors.
> > 
> > [beginner], by contrast, came from a Bugzilla keyword during the migration. I don't know for sure what its original intent was, but I agree it seems like a synonym for [good first issue]. (And therefore I suggest we retag all 89 open [beginner] issues as [good first issue] and then burninate the [beginner] tag. But I won't do that unless someone tells me to. ;))
> There's a similar debate on Discourse, https://llvm.discourse.group/t/good-first-issue-vs-beginner/5850
> 
> But I'd say: Do it. :)
My position is also: do it.

================
Comment at: llvm/docs/BugLifeCycle.rst:122-125
+Please add the ``infrastructure`` label to request any changes to be made to
+the labels used by the issue tracker instead of creating your own label. This
+increases consistency when triaging and helps reduce the proliferation of
+labels.
----------------
Quuxplusone wrote:
> Quuxplusone wrote:
> > I think this is saying: Any project member can create new labels, but we discourage it, because we don't want a proliferation of similar or single-use labels. If you are not a project member — or even if you are! — then when you want a new label created, please open a GitHub issue with the subject line "Create issue label [foo]", add the [infrastructure] label to that issue itself, and wait. (For what, exactly?)
> > 
> > My impression is that a better/faster alternative is to speak up in the #infrastructure channel on the Discord.
> Oh, and every new label request should include a description of //what the label is for//, which will be used as its description on https://github.com/llvm/llvm-project/labels . If you're ever unsure of the meaning of a label, visit https://github.com/llvm/llvm-project/labels for more information.
> 
> (And post-migration corollary: if you //know// the intent of label [foo] but it's not actually documented on https://github.com/llvm/llvm-project/labels , then please edit its documentation there so that future readers //will// be able to find it!)
> I think this is saying: Any project member can create new labels, but we discourage it, because we don't want a proliferation of similar or single-use labels.

Correct, that's what I'm going for.

>  and wait. (For what, exactly?)

For someone to add the label for you, at which point you can retrofit it onto your issue if you care that deeply.

I've updated the docs here, thanks for the suggestions (here and elsewhere).

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

https://reviews.llvm.org/D117832