Allow me to create a default set of labels for my repos

[mehulkar]

Really want this site wide for my Github Enterprise install, but just for my (or my organizations) repos would be a great start. E.g. docs should be a default label IMO.

update in 2019

• closed Ability to set default issue labels per organization (colors and names) #371 in favor of this.

Adding need for

• default set of labels for the user when they create a repo
• default set of labels for an Org
• default set of labels for an entire GHE org.

You can choose what the fallback order should be, as long as there's a way to force one set over the other when creating a repo.

[sharwell]

So this is not the cleanest solution in the world, but it does open many possibilities (especially things like copy labels from one repository to another).

https://developer.github.com/v3/issues/labels/

[andreimarin90]

+1

[Frug]

👍

[iamerikjolson]

Cross-posted from #371.

--

We use this shell script to delete the default GitHub labels and add our own. You can modify as needed for your purposes.
https://github.com/thisisarray/GitHub-Issues-Process/blob/master/set-github-labels.sh

[usmanismail]

Dead link on https://github.com/80-20/ProcessManagement/blob/master/set-github-lables.sh

[iamerikjolson]

Sorry about. The update URL is at:
https://github.com/thisisarray/GitHub-Issues-Process/blob/master/set-github-labels.sh

I'll update the above comment too to correct the URL.

[desrosj]

Color and label consistency across repositories would be very helpful and useful.

[patcon]

This should be accomodated by https://github.com/apps/settings now! 🎉

Related: repository-settings/app#80

Does this make this issue good to close? :)

[nunorafaelrocha]

IMHO, the probot/settings app it's really good, but the lacking of permission restrictions makes it only usable for organization/repository where everyone as the admin role.

I would say that this should be a core feature under github enterprise first.

[mehulkar]

nice, that's pretty cool @patcon. But not sure how I could use that in an GHE install.

[patcon]

IMHO, the probot/settings app it's really good, but the lacking of permission restrictions makes it only usable for organization/repository where everyone as the admin role.

The warning that I think you're alluding to (on the plugin install page) is perhaps a little overbearing, as I believe its concerns are accommodated by properly setting up protected branch settings on the default branch. And with this PR incoming, that will be possible to configure via the plugin itself soon :)
repository-settings/app#76

[nhooyr]

I think another reason why probot/settings doesn't close this issue is because it'd be hard to keep a large number of repositories's labels in sync. If you make a single sync, it'll be annoying to update it everywhere.

[oprogramador]

@mehulkar

this seems to be a duplicate of #371

[dgw]

@oprogramador If anything, #371 is a duplicate of this, not the other way around.

But this issue talks about "my repos", and #371 is for "per organization". While closely related, the two issues aren't strictly duplicates at all.

[ghost]

Sorry about. The update URL is at:
https://github.com/thisisarray/GitHub-Issues-Process/blob/master/set-github-labels.sh

I'll update the above comment too to correct the URL.

Following this I made a repo. I plan on going further than just adding labels. Label descriptions are also supported! 😄

[sypets]

this seems to be a duplicate of #371

But this issue talks about "my repos", and #371 is for "per organization". While closely related, the two issues aren't strictly duplicates at all.

Strictly, this issue does talk about "my repos" and "my organizations repos":

just for my (or my organizations) repos

I would agree, #371 is a duplicate.

But I suggest, change the title:

Allow me to create a default set of labels for my repos

→ Allow a default set of labels for user / organization.

[mehulkar]

Closed #371 since I probably meant the same thing in both. Added some more details in the top comment that should cover all the cases. Feel free to have more Thoughts and Opinions™ and comment here!

[labrose]

👋 Hi! PM for GitHub here. We recently launched a new setting that will allow you to set the default labels that are created for new repositories in an organization. Right now it does not modify existing repositories, but we are considering ways that you can further standardize labels.

Let me know if you try this out and how it works for you! As we continue to improve label administration across multiple repositories, any and all feedback is appreciated.

[mehulkar]

@labrose awesome! is this available in GHE yet?

[labrose]

We try to keep dotcom and GHES in feature parity as much as possible and ship GHES updates roughly every 3 months. Org label defaults haven't been released in a GHES version yet, but keep an eye on or subscribe to our release notes 😄

[schaib]

Awesome !
Is there any easy way to spread modifications to repositories ?

[labrose]

Right now the labels don't apply back to existing repositories.

Could you elaborate more on what types of modifications you would want to spread and to which repositories?

[sypets]

@labrose It would be very convenient if there was a way to apply the default labels to specific repositories or to all repositories. The solution https://github.com/apps/settings provided a way to migrate existing labels by defining a relation "old label" -> "new label".

[mehulkar]

Closing this down as it seems the main feature is done! Thanks for the updates @labrose!

[Zebiano]

This issue is in my opinion still not 100% resolved, as "default labels" has only been integrated for repositories inside organizations, and not for user repositories. I'd love to have the same feature for users, as it's exactly what I've been searching for.

Since that hasn't been implemented yet, I've decided to develop a small CLI that makes use of the GitHub API to automatically upload custom labels to any repository you have access to.

Posting this in hopes of helping others out so long the feature doesn't get implemented user-wide.