New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Further GitHub labeling improvements #10057
Comments
I think rather than
Last point about CI: Warnings should rather be solved commenting than labeling IMHO, to give more detailed information. Not testing everything is a good idea, but this could also be done mostly automated (e.g. if a file isn't involved in the applications binary, don't compile that application). But I guess a "CI: Doc only" label might also be helpful. |
(this I would however rather discuss with the CI team in a separate issue) |
Do the |
I guess for the future automation of most of the labels would be great, but for now there is no specific plan for that. @danpetry maybe put this onto the list for "Further labeling actions"? |
It would be great because I think this part will be really time consuming for maintainers. Even if not all |
I've put this on the list. The "issue triaging" is my favourite item on the list above in fact. Yes, it will be time consuming, but organizing our "big ball of mud" of issues and PRs will really pay dividends in helping us prioritize our work - in other words, it will save more time in the long run, and is required really if we want to scale.
|
The monthly developer meeting the day before the Hack'n'ACK (ping @kYc0o) could also be a possible candidate.
Mh... I don't think GitHub's permission levels allow for such a fine-grained configuration. A user can either read, write, administrate, or own a repository. Setting labels is allowed from write onwards, but that also means they can push (i.e. merge PRs) and give effective reviews (i.e. an approval results the PR being not blocked anymore for merging). |
Hmm, yeah. This does also head in the direction of stratifying, which doesn't really fit in with our grassroots philosophy as I understand it. |
As stated in #10030 (comment), I think these are very much redundant with the labels from the |
On the flip-side e.g. for |
Actually, this might be an argument for having a distinct |
As discussed offline, I added |
I also added the |
I know that the |
IMHO if this is properly documented and agreed upon amongst maintainers, yes. See also my current documentation on the major label. |
#16476 is related to this issue. Are we happy with our labels and should we consider closing this issue ? |
At least the priority labels I would like to have introduced. Not sure what happened, but in #10057 (comment) I said, I added them, but I can't find them. Can we get a consensus to introduce them before closing? |
+1 for priority labels |
Description
This issue follows on from #10030.
That issue deals only with re-naming current labels, but during the discussion, a number of further points of action are being brought up.
These will be captured below. Feel free to add more points yourself (but preferably not delete).
Further labeling actions:
Add further labels proposed during that discussion. A couple of suggestions:
State: under review
State: inactive
State: blocked
Priority: {high|low|medium}
Review requirement: light
Review requirement: thorough
Type: security flaw
Issue triaging: sorting and re-labelling issues
Extracting useful information for the CI (show warning if there's a new feature with no test, not test everything if there's only a change in documentation, etc).
Automated label-setting
The text was updated successfully, but these errors were encountered: