It will be hard to differentiate bugs from feature proposals automatically across all services.

Some forges have their own labels and some of our service implementations can import those as tags. Can you expand on that?

👍 to adding a 'github' or 'gitlab' label though, independently.

Oh, I wonder if I misunderstood; I had read this as being just a suggestion for how we could categorize the issues in this project.

I find both @ralphbean and @coddingtonbear's interpretations plausible, but I think @coddingtonbear's is most likely correct.

In my opinion service labels aren't a good idea, because:

• Unlike bugs/features, you can easily filter them via search.
• That's a lot more labeling to keep up with and IMO inconsistent labeling is worse than none.
• We'd end up with more label colors than can be easily visually distinguished. You've got the secondary colors and then black and grey but once you go beyond 10 the colors are useless.

This is indeed a meta issue: I meant to add labels to bugwarrior's own issue tracker 😉.

But @ralphbean's interpretation wasn't that far as one use case I thought about would be to have bugwarrior (the software) import issues from bugwarrior's issue tracker only for the services I'm familiar with (i.e. I would be interrested to get unassigned issue for gitlab and bitbucket but not jira for instance). I just see now that filtering by label doesn't seem to be implemented in the github service, but that would be a different issue.

To answer @ryneeverett specific comments

Unlike bugs/features, you can easily filter them via search.

This is actually not as easy as it sounds and I get a poor precision for some services. For instance, this particular issue will appear for a search of bitbucket just because I mentioned it as an example (and try searching for 'github', you'll get half the open issues!)

That's a lot more labeling to keep up with and IMO inconsistent labeling is worse than none.

That's a bit vague but I'd say it depends what you want to use it for. In the case of automatically importing issue in taskwarrior based on labels, I could live with less-than-perfect recall but poor precision is a show stopper. In addition, I can go to github and fix the labels, I can't "fix" the search results.

We'd end up with more label colors than can be easily visually distinguished. You've got the secondary colors and then black and grey but once you go beyond 10 the colors are useless.

I wouldn't try to get one color for each service. Instead I would have one color for bugs, one for feature proposals and only one for all services (a bit like here with languages).

This is actually not as easy as it sounds and I get a poor precision for some services. For instance, this particular issue will appear for a search of bitbucket just because I mentioned it as an example (and try searching for 'github', you'll get half the open issues!)

Fair enough.

That's a bit vague but I'd say it depends what you want to use it for. In the case of automatically importing issue in taskwarrior based on labels, I could live with less-than-perfect recall but poor precision is a show stopper. In addition, I can go to github and fix the labels, I can't "fix" the search results.

Fair enough.

I wouldn't try to get one color for each service. Instead I would have one color for bugs, one for feature proposals and only one for all services (a bit like here with languages).

Awesome, I'd never considered that strategy.

I now added the suggested labels, plus one "need info", and sorted all the open issues (maybe I'll do the closed issues if I have an afternoon to waste someday...).

If someone disagree with my labeling, feel free to change it but then please use this thread to explain why you thought it was mislabeled.