Core set of labels for code repos

[Frijol]

Separating out the "code repo labels" discussion from the more general core labels discussion at #193:

@Mr0grog:

Over in web monitoring land we have the following that I find very useful, though they are inconsistently implemented across our repos:

• API for anything that would involve changes to the external API of the project in question (only applicable to 3 out of 5 repos, so maybe not universal?)

• Code Quality for anything focused mainly on code quality, organization, developer happiness, etc, e.g. linting, CI, etc.

• Question for open questions that need feedback before any actual action can happen. (Note: this tends to only apply temporarily—I remove the label from issues when the discussion has been settled.)

• ㊋ furious debate somewhat related to the above.

@b5:

Over at Qri our standard set of labels derived from the Angluar JS contributor guidelines:

label	description	already proposed here
docs	changes & issues with documentation	yes
chore	clerical non-docs related chores (often things like CI, cutting releases, dependency upgrades)
fix	a change, or discussion of a change that removes a bug
bug	software that isn't behaving as expected	yes
feat	a change or proposal that does something new
refactor	a change that neither removes a bug or introduces a feature
perf	a change or issue that impacts the efficency of software

We don't need to do things this way at all, but most of the team has found it much easier to assess PR's and issues when they're filed according to one of these themes, so we include them in our standard set of labels. We also file all commits in one of these themes to sort the intent of a commit, and use it to generate changelogs.

It theoretically would help anyone coming from the commitizen space, but I don't think that's a good enough reason to include these labels here. I'd only include these if someone not from Qri can see merit in including these labels in the standard set.

From @Mr0grog's list I'm a huge fan of API. Sounds like there's overlap between chore from the above list & Code Quality, I'm happy to have that called Code Quality

@Mr0grog:

Sounds like there's overlap between chore from the above list & Code Quality

I think chore is a lot more broad, though it covers most stuff I would tag with Code Quality. The main exception: I always vacillate on whether a refactor qualifies as code quality, but it would not be a chore (obviously commitizen has a specific tag for this). Conversely, release-related tasks (bumping version numbers, fixing package.json/setup.py/etc.) would definitely be a chore but probably not Code Quality. That said, Code Quality probably says a bit more about what you’re going for when it applies.

I’m somewhat ambivalent about the two names ¯\_(ツ)_/¯ and the point about commitizen as a well-known standard is a good one.

I feel like there’s a core set here that is good for all our repos, and a code-specific superset that is good for repos that represent actual software.

@b5:

I feel like there’s a core set here that is good for all our repos, and a code-specific superset that is good for repos that represent actual software.

OoOooOOoh I like this point a lot. Everything I've suggested is code specific, and that's not the way we use GitHub at EDGI. I think we structure "code repos" and "all repos" as separate discussions. I'd hate to see something like perf end up as a tag in an overview repo just b/c it's "standard". Based on that, I think @Frijol's proposal above is great.

@lightandluck:

Agree with the "code repo" vs "all repo" perspective. In that light, question would be good to add to the proposed list. And ㊋ furious debate is just too cool not to have!

Also, in WM it was decided to use idea as an exempt label to tell stale-bot to leave long-term issues alone. I think that makes sense to carry over to the standard set as well.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in seven days if no further activity occurs. If it should not be closed, please comment! Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in seven days if no further activity occurs. If it should not be closed, please comment! Thank you for your contributions.