-
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom labels workflow? #147
Comments
No, I don't think we have such a thing. We have tried to use github projects and whatever they called their meta-issues on there. The simple approach does work: an issue listing all the connected issues and their status. |
I am personally pro the proliferation of project-specific labels. For instance, I'd like to have a |
As you can see in #50 I started walking the path of standardization and automating that process. However I think there is a good case to be made for repo specific labels. I would be lost in That added enough complexity to automating the standardization that I got distracted by other things. Ideally I would like to see broad labels like |
Yeah that makes sense. It wasn't clear to me that those were meant to be a subset of total labels. I might go add a |
Yeah, that sounds like a good place to work towards @fjetter you should feel free to add project specific labels to @jsignell a |
Do we have any convention regarding problem specific labels? I have the particular use case that there is a large scale problem bothering us (dask/distributed#4413) for a while now and there are multiple issues connected to this (Example dask/distributed#4698 but there are many more). I do not think the individual issues can be sensibly fixed on their own but I also do not take it for granted that they will be fixed automagically. The root cause issue requires a refactoring of the code base and I'd like to get back to the individual tickets once the refactoring is done. One possibility to keep track of this would be to use labels, either very specific ones
worker-state-machine
or more broader ones likestability
Another way to handle this would be to maintain a list with refs to the individual tickets (w/ or w/out closing them) and I was wondering if there are any best practices or suggestions about smth like this.
Note there is an issue open about standardising issues across projects #50
The text was updated successfully, but these errors were encountered: