Closed dcwalk closed 5 years ago
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
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 https://github.com/edgi-govdata-archiving/overview/issues/170 which (if needed) explains what the labels mean.
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 |
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 |
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 |
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.
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 https://github.com/edgi-govdata-archiving/overview/issues/179
here's a link to a gist for automating label creation https://gist.github.com/b5/d3bd0de5aa88842b2455a2e5c1112c87
I like the proposed changes as they currently stand. 👍
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.
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
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.
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.
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.
👍 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 https://github.com/edgi-govdata-archiving/overview/issues/186 ? or should I take the more manual approach per @b5's suggestion at https://gist.github.com/b5/d3bd0de5aa88842b2455a2e5c1112c87 ?
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…
I think the permissions elevation issue @dcwalk pointed out in this comment is a blocker: https://github.com/edgi-govdata-archiving/overview/issues/186#issuecomment-322040219
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.
If the goal is synchronization anyway, the approach in #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.
Bookmarking this script for exporting a json of our GH labels: https://gist.github.com/MoOx/93c2853fee760f42d97f
🎊 I implemented the core labels across repos! We can close this issue as soon as https://github.com/edgi-govdata-archiving/overview/pull/230 is merged, documenting core labels and how to apply them.
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:
and
It was raised during the Aug 14 Archiving/Tech WG meeting.
TODOs: