Skip to content
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

GitHub request for PR/Issue creator assignable labels. #1409

Closed
elmart opened this issue Nov 6, 2014 · 7 comments
Closed

GitHub request for PR/Issue creator assignable labels. #1409

elmart opened this issue Nov 6, 2014 · 7 comments

Comments

@elmart
Copy link
Contributor

elmart commented Nov 6, 2014

A couple of hours ago, I sent this message to GitHub's support:

Hi,

Current labels functionality is great, and we use it a lot at neovim (see our pull requests page, https://github.com/neovim/neovim/pulls).

But there's a glitch. While it's preferrable that most tags can only be assigned/removed/defined by repository owners, it would be great if some tags, while still defined by owners, could however be assigned/removed by PR/Issue creator.

In our case, if you see our PR page above again, we need to encode PR status info in the title, with the following convention, organically developed:
[WIP]: Work in progress. Don't review this yet. It will change. But it's there for others to know there's work going on on some area, and to allow early signaling of potential problems.
[RFC]: Author considers this finished, and is requesting others to review his work before getting merged.
[RDY]: PR has been reviewed by a sufficient number of people and can be merged when maintainers have time to do so.

It would be great if we could use tags too for that PR status info. But, as you see, it's the PR/Issue creator the one who naturally has to decide when a given tag applies.

So, I would ask for the possibility that some of the tags defined by a repo owner could be marked to be assignable by users instead. It could be restricted to PR's and PR creators, or it could be more general.

I just want to let you know that the need for such a thing exists, and a lot of projects could benefit from it.

Thanks, and keep up the hard work. GitHub rocks!
Eliseo Martínez.

They have kindly and swiftly responded just minutes ago, with the following:

Hi Eliseo,

Thanks for getting in touch and taking the time to describe your workflow in detail -- that's incredibly helpful.

I agree with you -- allowing creators of issues and pull requests to assign labels would be helpful. It's something we're considering, but I can't make any promises about if/when this might be available. We deeply care about supporting workflows and I'm happy to pass your feedback to the team for consideration.

In the meantime, you might consider using the API to help you out:

https://developer.github.com/

You could build an OAuth application which allows GitHub users to sign in. Each user that signs in would get a list of issues they created in the neovim repository and would be allowed to add/remove some tags. These tags would be added/removed using the API by a special "machine" account which you would create and which would have push access to the neovim repository (e.g. NeovimRobot). While this would require you to build something new and might be a less elegant solution than you'd like -- it should get the job done.

If there's anything else on your wishlist -- please let us know.

Thanks again (and for the very kind words <3),
Ivan

The idea is nice, and maybe can be tackled at some point. For the time being (rushing to the first release) I think there are many more urgent things to do. So I myself won't be doing this soon. But I leave it here just in case somebody wants to. And just for you to know that, maybe, in future, our workflow could be directly supported by GitHub's tags.

BTW, such a thing would allow, for example:

  • for maintainers to filter PR's to only see those RDY
  • for reviewers to filter PR's to only see those RFC
  • etc.

I will be closing this after a while.
Regards

@justinmk
Copy link
Member

justinmk commented Nov 6, 2014

How about adding this issue to bot-ci?

@elmart
Copy link
Contributor Author

elmart commented Nov 6, 2014

Not sure if I get what you mean.
If you mean that bot-ci could be the user updating tags on behalf of real users, then, yes, that would definitely be the most logical thing to do.
What I don't fully like about the suggested solution is having to go to another site just to change labels. It remain easier just changing the title, as we have been doing, without having to go another place.
A different thing would be that at some point GitHub supports proposed user-changeable labels. Then I would definitely change to using that.

@fwalch
Copy link
Member

fwalch commented Nov 6, 2014

Maybe related: I often see messages such as jszakmeister added the in progress label 13 days ago for some PRs, is this done automatically by waffle.io?

@elmart
Copy link
Contributor Author

elmart commented Nov 6, 2014

Yes. Many times I've seen jszakmeister adding the 'in progress' label just to remove it 10 min later when PR merged. So it must be some automated thing just happening to use jszakmeister user instead of that of Marvim. @jszakmeister It's not possible you are so proactive, are you? ;-)

@elmart
Copy link
Contributor Author

elmart commented Nov 6, 2014

@justinmk @fwalch
Now I get what you meant. Making bot automatically add labels based on title.
That's great, in fact. Much simpler than the previously proposed temporal solution, and better, as you don't have to go another site to change labels.
We continue working as we've always done, but maintainers/reviewers have tags available to make their work easier. And if at some point, GitHub starts supporting user-changeable labels, we can leave it on and people can choose whether to use tags directly or continue working the other way. Both would work.

Perfect!
Thanks, guys.

@elmart
Copy link
Contributor Author

elmart commented Nov 6, 2014

Note: For the bot to do a perfect job, title change notification should be inhibited if the only change is in status heading. We don't want redundant title & tag notifications. Not sure if inhibition of notifications is possible, though.

@jszakmeister
Copy link
Contributor

@elmart I think it's Travis that is doing that, but I'm not certain of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants