Skip to content
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

Closed
fjetter opened this issue Apr 13, 2021 · 5 comments
Closed

Custom labels workflow? #147

fjetter opened this issue Apr 13, 2021 · 5 comments

Comments

@fjetter
Copy link
Member

fjetter commented Apr 13, 2021

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 like stability
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

@martindurant
Copy link
Member

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.

@jsignell
Copy link
Member

I am personally pro the proliferation of project-specific labels. For instance, I'd like to have a parquet label on dask/dask. I got the sense from #50 that we didn't want to go down that path, so I've held off. What do you think @jacobtomlinson, should we standardize or just let people add labels as convenient?

@jacobtomlinson
Copy link
Member

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 dask-cloudprovider without the vendor labels for sure.

That added enough complexity to automating the standardization that I got distracted by other things.

Ideally I would like to see broad labels like type/bug standardized across all our repos. But leave project specific labels in place.

@jsignell
Copy link
Member

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 parquet label to dask/dask then :) @jrbourbeau is that cool with you?

@jrbourbeau
Copy link
Member

Ideally I would like to see broad labels like type/bug standardized across all our repos. But leave project specific labels in place

Yeah, that sounds like a good place to work towards

@fjetter you should feel free to add project specific labels to distributed directly or raise an issue in the distributed repo if you'd like to engage other folks beforehand.

@jsignell a parquet label seems reasonable. For example, some folks might want to look at parquet issues specifically instead of all I/O-related issues (which we currently use the io label for).

@fjetter fjetter closed this as completed Apr 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants