Set up a labeling system for this repo for sortability/discoverability

[jessicaschilling]

Per the SIG weekly call on 8 May, I'm thinking about best ways to organize content in this repo. Some "fundamental considerations" off the top of my head:

1. Right now, the package-managers repo is being used primarily as a discussion board for talking about high-level things like the state of the current package manager landscape, details on existing package managers, how existing package managers may benefit from being IPFSified, audience segments, problem statements, use cases, etc etc.
2. Within that general high-level discussion, discrete categories or areas of effort are starting to emerge; we should start to organize on these for purposes of current/future discoverability and sortability.
3. Eventually, issues in those categories will likely turn into more formal user stories or even (maybe?) migrate up into the main IPFS repo to be used against changes/commits in code.

As @andrew noted, GitHub's built-in wiki is kind of lame, particularly in that it doesn't play well with issues, and that breaks fundamental no. 3 above.

Without roping in any third-party solution, that probably leaves us with using labels for these purposes. I think we can achieve all of these by setting up a robust labeling system, maybe a combination of these two:

• https://medium.com/@dave_lunny/sane-github-labels-c5d2e6004b63 for nomenclature of label-type: label-name
• https://robinpowered.com/blog/best-practice-system-for-organizing-and-tagging-github-issues/ for use of color (which is redundant to use of label-type above, but extremely clear)

Label types could include

• functional focus like identity, dependencies, discoverability as outlined in issue 52
• specific package managers like npm, rubygems etc (though this may result in a huge list of labels eventually)
• as well as "normal" things like status, priority etc

Thoughts?

[jessicaschilling]

Copypasting @andrew's comment from #53 (comment) for continuity :)

@jessicaschilling proper labeling would be 👌, I personally prefer simple word labels rather than but don't really mind how they end up. One thing that would be good to include with a new label system would be a labeling document in the repo so people know how to label their issues correctly.

We added one to our CONTRIBUTING.md on Octobox: https://github.com/octobox/octobox/blob/master/docs/CONTRIBUTING.md#our-labels

[andrew]

Ah beat me to it!

One thing to note is that with label-type: label-name style, you can't filter or group by label-type in the GitHub UI, so it's purely just more explicit descriptions.

Also since that blog post was published back in 2016 GitHub has added the ability to add descriptions to different labels which should up on hover.

You can also use emoji in labels to add a little extra visual flair:

[jessicaschilling]

Good points about the emoji and descriptions ...

As for use of label-type: label-name, agreed that it's a bummer that you can't do a more fine-grained search in GitHub to search by "label contains". That said, using that syntax would mean that they're alphabetized in a useful way in the "apply labels to this issue" dialog; plus, you can use values for label-type as a search string to drill down on a long list of labels, like so:

[jessicaschilling]

Note: This gets complicated by the fact that any labels we set up will be visible to everyone in the IPFS repo.

ETA: If you look at the number of currently assigned labels in the IPFS repo - https://github.com/ipfs/package-managers/labels - it at least looks like labeling isn't really currently being utilized by the repo at large.

[andrew]

No idea what is going on with the comment ordering in this issue 😬

[jessicaschilling]

For the sake of discussion, tossing out some possible label categories and values below. Items in italics are ones currently in active use in the IPFS repo — note that there are more labels currently living in the repo, particularly GitHub's default ones, that aren't in use.

Thoughts? particularly considering this impacts the entire IPFS repo?

Labels applicable to entire IPFS repo, including package managers

Status: abandoned, accepted, available, backlog, blocked, completed, experiment, in progress, on hold, pending, review needed, revision needed

Type: bug, discussion topic, documentation, feature, maintenance, outreach, UI, UX, research, testing

Priority: low, medium, high, critical (or P0, P1 ...) -- also would suggest including OKR in this one

Difficulty: very easy, easy, medium, hard, extra hard

Impact: very small, small, medium, large, extra large

Labels specific to our package managers effort

Audience: package consumers, package publishers, package manager maintainers -- does this take care of issues currently tagged maintainer-call?

Focus: dependencies, identity, discovery (separate out into search, resolution, updates?), standards/compatibility

Package manger: npm, rubygems, etc etc etc

[andrew]

The labels we set on https://github.com/ipfs/package-managers/labels won't affect anything other than this repository, so we can add/edit/remove as we like, it won't affect anyone else.

[jessicaschilling]

Added the labels noted earlier in this thread (with a few revisions as discussed with @andrew) ... I'll go through the existing open issues and take a bash at labeling, but otherwise this one is good to close out.

[andrew]

Looks like the ordering has been fixed 🎉

[jessicaschilling]

Labels all added, closing issue.