Allow non contributors to suggest labels

[cirosantilli]

40+ upvotes on StackOverflow often implies wanted feature: http://stackoverflow.com/a/13829505/895245

It would however be useful if you could in some manner propose labels. Then you could mark an issue as what you think is a bug, so the owner can just confirm that.

Related: #875

Update: GitHub issue templates label auto assignment (December 2018)

As I have explained at: https://stackoverflow.com/questions/13829466/how-to-put-a-label-on-an-issue-in-github-if-you-are-not-a-contributor-owner/31366954#31366954 I now feel that this is a very good solution for this problem. Kudos GitHub.

[patcon]

tags = labels in github-speak :)

EDIT: issue title used to say "tags"

[Mithgol]

That's because tags are Git tags, I presume.

[jonathancross]

Up to 136 votes on stackoverflow now: http://stackoverflow.com/a/13829505/895245

[gaborbernat]

👍 definitely a time saver feature

[DirkHoffmann]

👍 This is still up to date.
Certainly contributors want to keep control over the labels, which are assigned to issues.
But in many cases, I think it would save time to issue authors and contributors to have "proposed labels", i.e. to identify "bug", "enhancement request" (while sticking to the existing labels list) etc. more easily.

[yannduran]

I wasted time trying to figure out how to label my "issue". Eventually found the StackOverflow question.

Please either add the ability to suggest a label, or make it clear on the "new issue" page that only contributors can add labels.

[ryanblakeley]

At the very least, please indicate who has permission to label issues on the documentation page.

[jasnow]

It would be REALLY nice to be able to set a label on our OWN Github issues.
The documentation for label setting assume that you know that only write-only repo members can set labels.

[jidanni]

Please somebody make a note on
https://help.github.com/articles/applying-labels-to-issues-and-pull-requests/
about who can add labels to issues and who can't.

Else many people who Google "github issues add labels" will end up trying it over and over and scratching their heads.

Also mention it on
https://help.github.com/articles/creating-and-editing-labels-for-issues-and-pull-requests/

[dtzar]

What was the official answer from GitHub support on this issue?

[paragonie-scott]

I'd love to allow people to assign existing labels to their own issues.

[jaime-olivares]

There can be either 2 states for labels (proposed, assigned) or 2 permission types (everybody, contributor). This covers most cases.

[Mithgol]

Non-contributors might also propose to remove existing labels.

[dongryphon]

Might be nice if label creation/removal was its own permission assignable to teams as well. Since you cannot add a Team as a Collaborator afaik....

[ibrokemypie]

on Feb 7, 2014

Now Nov 18, 2016...

[orome]

For reference (and as a possible workaround for now): What is the minimal OAuth scope required to allow for changing GitHub issue labels?

[lukehefson]

Hello friends 👋

We're (GitHub) currently working to unpack some of the use cases and requests in this tread.

Specifically I've been wondering if any of the folk in this thread who maintain projects for whom 'non contributors' regularly file issues on have set up issue templates that automatically add a label(s)?

If so, did it help? How could it be better?

[jidanni]

All I know is I am a non-contributor who files a lot of issues on other people's projects.

[timokau]

What I would like for nixpkgs is a white-listed set of tags that non-contributors can apply and remove. Just adding them at issue-creation time is not enough for that use-case.

nixpkgs is relatively unique in that it has a lot of contributors and reviewers. That makes dealing with the PR backlog using the standard github workflow quite frustrating. We'd like to experiment with a more trac-like workflow, e.g. users marking PRs as "needs:review", reviewers setting it as "needs:work", repeat until both sides are happy.

[billybooth]

@lukehefson,

I've been wondering if any of the folk in this thread who maintain projects for whom 'non contributors' regularly file issues on have set up issue templates that automatically add a label(s)?

We definitely make use of Issue templates and will investigate the usefulness of this, but on the face of it, other than allowing the reporter to designate labels tied to existing projects or milestones, I don’t think it’s a replacement for permission granularity per-repository with respect to Issues (or better yet, per-label). @timokau’s suggestion is a great one and would cover our needs.

In the meantime, probot is a good option that allows us to parse Issue template fields and apply appropriate labels when the reporter is an employee, and it also allows designated testers to re-open closed Issues or apply the appropriate labels when a fix has been confirmed via Issue comment key phrases. I don’t expect or ask for this sort of flexibility out of the box, but the ability to designate a set of labels that anyone with repository access can apply or remove would get us 90% of the way there. If that were extended to permissions per-label, say by team or individual, that might be sufficient for our workflow and allow us to drop to probot integration entirely.

[lukehefson]

What I would like for nixpkgs is a white-listed set of tags that non-contributors can apply and remove.

@timokau When you say "non-contributors" –  do you mean any user that submits a PR? Or could this be a trusted type/role of person that doesn't have code pushing access, but is able to help you with triage by adding/removing these white listed labels? Thanks!

I don’t expect or ask for this sort of flexibility out of the box, but the ability to designate a set of labels that anyone with repository access can apply or remove would get us 90% of the way there. If that were extended to permissions per-label, say by team or individual, that might be sufficient for our workflow and allow us to drop to probot integration entirely.

Really helpful to know the details of your situation – thanks @billybooth!

[DirkHoffmann]

My immediate use case (which triggered my comment above) is indico.

As a minimal function, I would like that the submitters of a PR or other issue can add or change lables on their issues. (This seems to be solved by the use of template, although they necessitate that all possible cases/labels have been foreseen by the admins.)

Secondly, ideally anybody with the permission to comment could add/remove a label, I consider it is just a very concise form of a comment, like this one could get &addlabel=too_long_standing_issue. Close or Re-open are just special cases of labels in that sense. But this bears the risk that anarchic users then misbehave like removing important labels from other issues and adding them to those they prefer. So this second step may require that some labels need to be restricted for use by project admins.

Of course, one can imagine any kind of more complicated solution. But this one should cover 90% of the use cases.

[timokau]

What I would like for nixpkgs is a white-listed set of tags that non-contributors can apply and remove.

@timokau When you say "non-contributors" – do you mean any user that submits a PR? Or could this be a trusted type/role of person that doesn't have code pushing access, but is able to help you with triage by adding/removing these white listed labels? Thanks!

Preferably the PR author can manage these labels themselves, without any special permissions. This seems to be inline with what @DirkHoffmann is suggesting.

Even better of course would be to have both options, e.g. finer-grained settings per-label.

[waterkip]

This would be sooo helpful for those who contribute to open source projects and don't want or need write access to the repo. You could triage bugs/issues and get an overview on what can or needs to be done. Right now you cannot do anything helpful with open issues.

Having an option to allow groups (contributors, guests, members, whatever) to set labels would be a huge improvement. I'm not in the business of +1 comments, but this one gets a +1.

[boolbag]

+1.
Allow someone from outside the repo to propose a label, e.g. Question.
After all, a question is not really an ïssue!

[cirosantilli]

@billybooth @lukehefson just want to say thanks for the issue template update, it solves the problem nicely.

I hadn't seen the announcement nor your comments due to unsubscribed from thread noise, but I saw the feature live on a repo today and came here and updated the issue description and my Stack Overflow answer.

Keep up the awesome work. 💯

[lukehefson]

just want to say thanks for the issue template update, it solves the problem nicely.

I hadn't seen the announcement nor your comments due to unsubscribed from thread noise, but I saw the feature live on a repo today and came here and updated the issue description and my Stack Overflow answer.

Keep up the awesome work. 💯

@cirosantilli Glad to hear that it helps! Although I'll be honest – I don't think that we quite nail some of the problems here, even with label automation in templates + the triage and maintain roles. We'll be making further investigations and investments into both over the coming months! ❤️

[Kixunil]

@lukehefson my view so far:

• templates are nice and do help but having many templates just to set different labels may be annoying to manage and use. If I wanted to allow every possible combination it'd mean having 2^count(allowed_labels) templates, which blows up rather quickly
• sometimes people don't want to bother with setting up templates, but single checkbox allowing issue creators to modify labels would be easy enough
• I'm thinking of embedding /issues/new?body=...&labels= links in my software error messages with various bits of information pre-filled. I guess this will not work with templates but didn't try yet. (Actually, having hidden templates that are able to process query variables would be cool, but I guess a bit heavy.)
• I have never in my life seen people abusing issues by intentionally writing misleading titles/descriptions and insisting on them after the owner changes it. As such I have no reason to expect (mass) abuse of labels. At worst people will occasionally make mistakes, just like they would in the titles. One change fixes it. In case of abusing user, just block the user.
• Being able to specify the set of allowed labels would be nice but starting with "allow all" is sufficient for me.

[kingdonb]

I am working on a CNCF project which has a formal governance and maintainers onboarding process that is intensive and does not happen overnight. It would be strongly beneficial if the code owners had a facility they could use to assign label rights to individuals or teams without granting reviewer / write access to the repo.

There is so much homework that I can do by exporting the github issues to a CSV and massaging them in a spreadsheet, visiting, reading, and taking notes, then bringing the notes to meetings and responding on the issue when a next action is clear, but in the interest of generating less noise on each issue, I usually refrain from leaving a comment unless the next action is already 100% clear to me.

If I notice an issue is mislabeled or missing some labels (like "blocked-dco") then as long as I can be granted permission to manage labels, while I am visiting these issues I feel like I can make a larger dent in a long backlog of issues in a shorter amount of time, without generating a great deal of noise or extra workload for the maintainers that have intentionally focused elsewhere, and without going outside of the GitHub UI.

I also agree with the previous commenter who said,

I have never in my life seen people abusing issues by intentionally writing misleading titles/descriptions and insisting on them after the owner changes it

In my case I think it would be ideal if I could be granted a role to manage labels, but I see little potential for abuse if it was simply something that maintainers could enable on their repository, that anyone who submitted an issue or PR can manage labels, or that anyone with a "Contributor" or equivalent badge can manage all labels without gaining write access to the repo.

Edit: I totally missed this, thanks for linking the triage and maintain roles which has behind it, repository permission levels for an organization

[ImprovedTube]

Edit: I totally missed this, thanks for linking the triage and maintain roles which has behind it, repository permission levels for an organization

the triage role for a person or team seems not to be available

@kingdonb thank you

[AuracleTech]

This should be allowed by default.
I'm about to open up a ticket for an enhancement in the issue section until someone review it.
this is wrong

[cesare-montresor]

I'm trying out the GitHub "issues template" which can be used as a workaround, but it lacks flexibility on labels.
The ideal would be, to be able to set a "write access level" per label, a list containing: roles, users, groups, "creator"