arcticicestudio
commented
3 years ago Hi @axelitus, documenting my label system is one of the many items on my “get things done“ list, but as always time and other priorities are a blocker 😕 I've created this label system in order to help myself getting a better overview over all the repositories (also using it for projects outside of the Nord scope). The default labels of a new repository on GitHub are indeed really basic and a great way to help newcomers to learn about project management, but for larger scaled projects these are no longer sufficient. Like everyone I've started a small research if there are already some kind of “best practices“ or guidelines, but like often this depends on the use case(s). So I've browsed my repositories to collect some example issues & PRs and tried to “extract“ some basic outline information. Afterwards I've git some inspiration from other larger projects like e.g. Kubernetes or Docker and also checked some (blog) posts like this one or official documentations about other label system like the one from SaltPack.
Long story short: I've added kind of categories for different aspects of an issue/PR like the scope (scope-*, what will be affected or what is the actual “receiver“/target or resulting effect), the current state or actions that are required (status-*), the type (type-*) of the change regarding the actual result (new code, better docs etc.) and many more like resolution-* for support/question issues.
Roughly summarized it's a system that was born and build based on actual needs, otherwise I'd loose track of the amount of information spread over many repositories and projects.
The actual creation on the other hand is quite simple. My main and absolute favorite language is Go and next to the fact that the language is perfect for large scale projects one of it's other outstanding strengths is the creation of CLI tools (single binary like C and no tons of dependencies like Python, Node or whatever script-fuggu 😄). I've created a simple CLI tool that can read some configs (YAML/JSON), includes some options to e.g. omit some labels and then creates the labels by making use of GitHub GraphQL API. The repository is currently private, but there's not reason to not polish it and make it public when there's time.
But of course this idea is not new, there are already a lot of other tools like tonglil/labeler that is also written in Go 💙 or some written in JavaScript (wider integration in Yarn/NPM workflows) like git-labelmaker.
Other solutions might include the use of the fantastic GitHub Actions like documented in the “GitHub Tools and Management“ section of the awesome-actions list.
Overall this was (and still is) a ongoing process based on changing requirements, but I guess you get the base idea of creating different “higher-level“ categories (e.g. type) that consists of labels with “more explicit details“ (e.g. type-feature) or in coding slang also known as “separation of concern“ through interfaces and explicit types that implement them 😄
By the way, there are no “hard rules“ when to apply which label. Sometimes it's not 100% clear and “categorizable“, but you can take this issue as an example where it's almost 100% clear:
The context is clearly something about my/the project's workflow while the scope is that it aids the maintainability. The actual type is a question and when this wall-of-text is enough to answer it the resolution-answered label will help me to know that this issue is ready for the GitHub notification archive (next to the closed issue state 😄 )
axelitus
This has nothing to do with the wonderful Nord theme (that I've been using everywhere I can), but more about the label system you have in place for the repo.
I find it more useful than the usual (default) label system that has Github and I want to implement this system (and colors) for my own repos. Is there any kind of documentation about your workflow that I can read?
Also, is there any way to easily configure the labels in new repos? Doing this by hand is long and tedious!