Create a core set of labels across projects

[dcwalk]

It would be good to have a core set of labels that we document and (attempt to) use in the same way across all our active EDGI projects (and Data Together potentially too!).

Relevant convos are #174:

@patcon: Do you think stalled label can be applied to blocked issues? Should there be a distinction?

and

@patcon: I do lean toward first-timer-only, as I think it's more self-documenting of intention, but happy to kick that convo to a later time in the interest of not bikeshedding (because everything else is very actionable!)

It was raised during the Aug 14 Archiving/Tech WG meeting.

---

TODOs:

• Have shared conversation to generate proposed set of labels
• Decide on implementation (a strong contender is Probot: Settings, see Add probot:settings plugin to EDGI repos #186) and document this
• Roll out to active EDGI project repos
  • overview
  • edgi-scripts
  • edgi-hubot-halpy
  • web-monitoring-processing
  • eis-search
  • web-monitoring-versionista-scraper
  • web-monitoring-ops
  • web-monitoring-db
  • web-monitoring
  • web-monitoring-ui
  • matterbridge-heroku
  • edgi-website
  • archivers-greetingslack
  • halpy-ng
  • 100days
  • awesome-website-change-monitoring
  • edgi-acronym-expander-browser-ext
  • video-call-landing-page
  • eot-nomination-tool

[Frijol]

Re what the label should be for first-timers, I'd like to propose good first issue because it is a default label in Github

[Frijol]

Towards the first of @dcwalk's TODO list, I thought I'd put together a proposal for our core set of labels.
I realized I don't know what most of these labels mean! So please feel free to counter-propose. Ideally we can end up with a standard set per #170 which (if needed) explains what the labels mean.

Proposal for core set of labels

Label	Current Activity	Proposal	Notes
documentation	5 open issues and pull requests	Keep	Might be helpful to highlight as a first thing for newbies to work on!
first-timer		Change to good-first-issue	To match Github defaults
coordination	13 open issues and pull requests	Keep (discussion/organization)
infrastructure	5 open issues and pull requests	Keep (tooling)
[priority-★★★]	3 open issues and pull requests	Keep	It doesn't look like we're using these all that much at the moment, but they seem like a good idea, especially for helping new contributors select issues
[priority-★★☆]	2 open issues and pull requests
[priority-★☆☆]	1 open issue or pull request
stale	7 open issues and pull requests	Keep	New from stale issues policy
stalled		Change to "blocked"	Currently not in use but helpful to show issues blocked by other issues
idea		Add
question		Add

Labels specific to the Overview repo

Label	Current Activity	Proposal	Notes
archiving	5 open issues and pull requests	Keep	Seems useful to have a label for each relevant WG
community-events	1 open issue or pull request	Keep
community	5 open issues and pull requests	Keep	WG label
data-together	1 open issue or pull request	Keep
web-monitoring		Keep	WG
website		Keep	WG

Labels in Overview repo I think we should get rid of

Label	Current Activity	Proposal	Notes
100-days	None	Delete	Since it's not in use
community-toolkit	3 open issues and pull requests	Delete	Seems like these would be better assigned to a WG label (archiving)
gsoc		Delete	Not currently in gsoc
Hacktoberfest		Delete	I have mixed feelings here because #Hacktoberfest can be a great way to get new contributors! But there are currently no issues marked with this, so I say delete until useful
trello	3 open issues and pull requests	Delete	I don't think we're really using the trello anymore, and all the issues marked with this label are stale
wontdo	2 open issues and pull requests	Delete	Other opinions on this welcome, but I think "stale"-ing out makes more sense/feels less aggressive

[lightandluck]

I agree with all of the proposals except merging coordination with infrastructure. I don't know exactly what they were used for prior, but my sense looking at closed issues is that coordination seemed to be for high-level, project management tracking and infrastructure for tooling.

I guess what we do with coordination depends on whether we continue to use issues to track tasks, but I wouldn't want to merge it. I do like having issues with checklists to track things and keeping things in GH where possible, so would be ok with keeping both.

I'm also partial to first-timer because of this site, but really haven't been involved with OSS long enough to know what's easier for newcomers to find. If the default good first issue is what more people look for, let's go for that.

[Frijol]

Thanks, Kevin– will update above to reflect re coordination & infrastructure

X-team dev meeting on 1/9 decided on "good first issue" as something we can implement, so I'm going to go ahead with that for purposes of #179

[b5]

here's a link to a gist for automating label creation https://gist.github.com/b5/d3bd0de5aa88842b2455a2e5c1112c87

[jsnshrmn]

I like the proposed changes as they currently stand. 👍

[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.

[Frijol]

👍 I'll begin to implement per the proposal above, including adding "idea" and "question" to the core set, and will separate out the "code repo" conversation to a separate GH issue.

I added a list for tracking implementation of the core issue set to the issue description (I'll make sure these labels are present, but won't delete labels except in Overview as listed above).

Question: are we comfortable rolling this out through .github/settings.yml as discussed in #186 ? or should I take the more manual approach per @b5's suggestion at https://gist.github.com/b5/d3bd0de5aa88842b2455a2e5c1112c87 ?

[Mr0grog]

are we comfortable rolling this out through .github/settings.yml as discussed in #186 ? or should I take the more manual approach per @b5's suggestion

Two thoughts here…

1. I think the permissions elevation issue @dcwalk pointed out in this comment is a blocker: Add probot:settings plugin to EDGI repos #186 (comment)

   Not sure if new settings have been added since @patcon’s original reply or if I’m misunderstanding, but it certainly seems like it does things now that a non-admin shouldn’t be able to do.

2. If the goal is synchronization anyway, the approach in Add probot:settings plugin to EDGI repos #186 would require a whole lot of duplicated work and would be painful to update, wouldn’t it? (If I understand right, we’d have to list the labels in the settings file of every repo.) I’m thinking this should a script like @b5’s (either in this repo or edgi-scripts) that gets run by CircleCI.

[Frijol]

Bookmarking this script for exporting a json of our GH labels: https://gist.github.com/MoOx/93c2853fee760f42d97f

[Frijol]

🎊 I implemented the core labels across repos! We can close this issue as soon as #230 is merged, documenting core labels and how to apply them.