search

dask / community

For general discussion and community planning. Discussion issues welcome.
20 stars 3 forks source link

Custom labels workflow? #147

Closed fjetter closed 3 years ago

fjetter commented 3 years ago

Do we have any convention regarding problem specific labels? I have the particular use case that there is a large scale problem bothering us (https://github.com/dask/distributed/issues/4413) for a while now and there are multiple issues connected to this (Example https://github.com/dask/distributed/issues/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 https://github.com/dask/community/issues/50

martindurant commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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).