What do our github labels mean?

Unknown
Unknown
edited May 2018 in Dev & Ops

Some of our labels are pretty clear, and get used occasionally, but there are others that I never see used. We should use this thread to clarify what they mean, and maybe remove a couple of labels.


^^^
Additionally, github labels now support descriptions, so I'm proposing the following description.

From my perspective this is my understanding/categorization.

Actively used and pretty clear.

  • Awaiting Feedback
    This issue or pull request is awaiting feedback, either from a client, internal or external, and should not be closed or merged yet.

  • Backport
    This pull request is a backport of another pull request. The relevant initial PR(s) should be linked in the pull request description.

  • Needs Backport (proposed)
    This issue requires a backport once it has been fixed.

  • Backported
    The fix for this issue has been successfully backported.

  • Blocker
    This issue or pull request is blocking another issue or pull request from being started or completed.

  • Epic
    This issue is large enough that it has been composed of numerous sub-issues which have been linked using Zenhub's Epics feature.

  • Gimme!
    A pull request so small or minor that it does not require any testing. This is usually reserved fixing of typos in a string or documentation somewhere and should rarely be used for PRs containing code change.

  • Good first contribution
    An issue that is small enough in scope that someone new to the project could tackle it without getting overwhelmed.

  • Hold
    Do NOT merge this Pull Request.

  • Needs Scope / Details
    This issue is not actionable at the moment because it has not been fully scoped out.

  • Revisit
    This pull request requires changes before it can be merged.

  • WIP
    This pull request is currently in progress. Do NOT merge it.

Rarely Used but Very straightforward

  • DB Update
    This pull request contains a database update.

  • Deprecate
    This pull request deprecates something.

  • Due
    This issue or pull request is a top, immediate priority.

  • Needs Testing
    This pull request is risky, and should receive additional manual testing by the reviewer(s).

  • R&D notes
    This issue needs to be discussed with the Vanilla R&D team.

  • Rebase
    ?? Where do we actually use this though?.

Rarely used and confusing

  • Enhancement (I spread a few of these around on issues I filed recently, but I think it needs to be clarified. Having a clearer meaning on this would probably make our backlog of old issues look less scary to newcomers.)
  • Bug (Rarely used. We actually have a lot of bugs filed, that don't have this label on them. Should we be placing this around more liberally?)

Don't seem to fit with our main repo

Since we've moved our proposals to the roadmap repo, which doesn't sync with the other repos, these labels feel a bit out of place.

  • Proposal
  • Accepted
  • Rejected

Summary

Most of our labels seem to indicate status, with almost nothing to indicate categorization. The categorization labels we do have (enhancement, bug) seem to be rarely ever used due to their unclear semantics.

Now part of the reason we tend not to use labels for categorization is because we have zenhub, which we use for categorization instead using epics, and pipelines, so I don't see a particular issue with not having these labels. I just think we could remove a bit of cruft and describe our existing labels a bit more clearly.

Comments

  • Vanilla Forums
    Vanilla Forums
    • Backport
      This pull request is a backport of another pull request. The relevant initial PR(s) should be linked in the pull request description.

    No, it means "This issue requires a backport once it has been fixed." so Needs Backport would be redundant. We prefix PRs that are actually backports with Backport: in the title so we don't mix them up. Note that using this tag usually means you should also comment to clarify which release branch(es) need the backport.

    • DB Update
      This pull request contains a database update.

    This one should probably have the 'radioactive' emoji appended, heh.

    • Due
      This issue or pull request is a top, immediate priority.

    This is from the age before formal sprints and was a promise to the CSMs we were really gonna get something done in an agreed upon timeframe. We could remove it. I use it once in a blue moon now as a generic priority flag.

    • Needs Testing
      This pull request is risky, and should receive additional manual testing by the reviewer(s).

    Yeah this is a bit of a euphemism for "Risky AF". We should be moving toward a process where this tag didn't need to exist.

    • Rebase
      ?? Where do we actually use this though?.

    This is occasionally used in the same way as the 'Revisit' tag to mark a PR for additional action. I'm ambivalent about it.

    Rarely used and confusing

    • Enhancement (I spread a few of these around on issues I filed recently, but I think it needs to be clarified. Having a clearer meaning on this would probably make our backlog of old issues look less scary to newcomers.)
    • Bug (Rarely used. We actually have a lot of bugs filed, that don't have this label on them. Should we be placing this around more liberally?)

    These are 100% for @Todd to use on some library repos for automated release notes generation. Please never use them on the core repos, they drive me crazy because we don't have any use for categorizing issues this way generally.

    Don't seem to fit with our main repo

    Since we've moved our proposals to the roadmap repo, which doesn't sync with the other repos, these labels feel a bit out of place.

    • Proposal
    • Accepted
    • Rejected

    This is exactly why I've resisted syncing that repo. I don't know why those got added to the core, nor had I noticed them at all.

    Summary

    Most of our labels seem to indicate status, with almost nothing to indicate categorization. The categorization labels we do have (enhancement, bug) seem to be rarely ever used due to their unclear semantics.

    Now part of the reason we tend not to use labels for categorization is because we have zenhub, which we use for categorization instead using epics, and pipelines, so I don't see a particular issue with not having these labels. I just think we could remove a bit of cruft and describe our existing labels a bit more clearly.

    This is accurate. We used to use more categorization labels until I discovered we never, ever used them and just spent a bunch of time useless categorizing things because it makes our developer brains happy. The search function is 100% better for all finding of related issues; the focus should be on putting good keywords in your issues/PRs so they consistently relate to other changes in that area.

  • Unknown
    Unknown

    @Linc said:

    • Backport
      This pull request is a backport of another pull request. The relevant initial PR(s) should be linked in the pull request description.

    No, it means "This issue requires a backport once it has been fixed." so Needs Backport would be redundant. We prefix PRs that are actually backports with Backport: in the title so we don't mix them up. Note that using this tag usually means you should also comment to clarify which release branch(es) need the backport.

    • DB Update
      This pull request contains a database update.

    This one should probably have the 'radioactive' emoji appended, heh.

    • Due
      This issue or pull request is a top, immediate priority.

    This is from the age before formal sprints and was a promise to the CSMs we were really gonna get something done in an agreed upon timeframe. We could remove it. I use it once in a blue moon now as a generic priority flag.

    • Needs Testing
      This pull request is risky, and should receive additional manual testing by the reviewer(s).

    Yeah this is a bit of a euphemism for "Risky AF". We should be moving toward a process where this tag didn't need to exist.

    • Rebase
      ?? Where do we actually use this though?.

    This is occasionally used in the same way as the 'Revisit' tag to mark a PR for additional action. I'm ambivalent about it.

    Rarely used and confusing

    • Enhancement (I spread a few of these around on issues I filed recently, but I think it needs to be clarified. Having a clearer meaning on this would probably make our backlog of old issues look less scary to newcomers.)
    • Bug (Rarely used. We actually have a lot of bugs filed, that don't have this label on them. Should we be placing this around more liberally?)

    These are 100% for @Todd to use on some library repos for automated release notes generation. Please never use them on the core repos, they drive me crazy because we don't have any use for categorizing issues this way generally.

    Don't seem to fit with our main repo

    Since we've moved our proposals to the roadmap repo, which doesn't sync with the other repos, these labels feel a bit out of place.

    • Proposal
    • Accepted
    • Rejected

    This is exactly why I've resisted syncing that repo. I don't know why those got added to the core, nor had I noticed them at all.

    Summary

    Most of our labels seem to indicate status, with almost nothing to indicate categorization. The categorization labels we do have (enhancement, bug) seem to be rarely ever used due to their unclear semantics.

    Now part of the reason we tend not to use labels for categorization is because we have zenhub, which we use for categorization instead using epics, and pipelines, so I don't see a particular issue with not having these labels. I just think we could remove a bit of cruft and describe our existing labels a bit more clearly.

    This is accurate. We used to use more categorization labels until I discovered we never, ever used them and just spent a bunch of time useless categorizing things because it makes our developer brains happy. The search function is 100% better for all finding of related issues; the focus should be on putting good keywords in your issues/PRs so they consistently relate to other changes in that area.

    Sounds like this could go in our process docs?

  • Unknown
    Unknown

    I do believe you can try syncing labels to repos without the --delete flag to allow them to have their own labels that aren't in core.

  • Unknown
    Unknown
    edited May 2018

    @slafleche said:
    Sounds like this could go in our process docs?

    I think the best place is just in the github labels tab. The descriptions can live right next to the labels.

    @Linc said:
    Yeah this is a bit of a euphemism for "Risky AF". We should be moving toward a process where this tag didn't need to exist.

    Maybe we should relabel it to Very Risky so it's a bit more clear?

  • Unknown
    Unknown

    Rebase
    ?? Where do we actually use this though?.

    Many moons ago, this was applied to otherwise-approved PRs with a merge conflict that needed resolving by the author.

  • Unknown
    Unknown

    I've updated the descriptions after discussion here, and updated the github-sync tool as well to sync descriptions.

    If anyone updates the descriptions and tries to sync them make sure you have the latest version of vanilla/github-sync.

Categories