Regression on Github labels
#1
I noticed that in the past month the amount of issue and PR labels has grown quite a lot. I don't know how everyone thinks about this but I find this amount of labels rather confusing. I also know that @xoft thinks the same way. So whay I'm suggesting is that we should think of a fixed set of labels that can help us determine bugs, feature requests, bugs that are critical and PRs that need to be tested. I also suggest to never remove nor add any label so that we can get familiar with the ones we are using. Labels are used to mark certain issues not to categorize them.

So what how do you guys think about this?
Reply
Thanks given by:
#2
Labelling "bug", "feature request", etc is completely useless. We did that before and found it to be no help at all.

I think what we should have as labels are:

critical/crash bugs
major area (redstone, worldgen, mobs, protocol etc)
easy issues
proposal

Minor areas of the code should be added as milestones rather than labels (e.g. performance, check if 1.9 only, configuration)
Reply
Thanks given by: sphinxc0re
#3
I haven't used the labelling feature of GitHub much, except for the "Easy" label to mark issues for potential newcomers. So I don't really careTongue
Reply
Thanks given by:
#4
That's odd @xoft at the meetup you told me that you find the current labeling rather confusing, too.
Reply
Thanks given by:
#5
oh yes, it is, that's why I don't use it Smile
Reply
Thanks given by:
#6
I'm the one responsible for the new label system. My motive is pure pragmatism and utility: The system allows very fast issue lookups.

The labeling systems proposed by @bearbin and @sphinxc0re are both completely useless in this regard.

I can write up a post "documenting" the labels, if you'd like.
Reply
Thanks given by:
#7
Quote:Minor areas of the code should be added as milestones rather than labels (e.g. performance, check if 1.9 only, configuration)

I disagree. Milestones are exactly milestones. When you have an finite and ambitious goal and you want to keep track of the progress toward achieving that goal, you use a milestone.

cClientHandle stability is a milstone. One day, it'll be complete and we'll have good stability.

"performance" is not a finite goal. It will never "end". Neither is "Configuration".

"check if 1.9 only" is a temporary tag for marking issues that may be due to the new 1.9 changes. While it's finite, it's not really an "ambitous goal", it's just a tag.
Reply
Thanks given by:
#8
Which is why I think e.g. "AI" is a bad milestone. We already have the label.
"Implement all Vanilla mobs" would have been a good milestone, but in practice we have the "mob progress" post.
Reply
Thanks given by:
#9
The current coloring is like this:

Blue - "visible" - Labels that directly impact gameplay, e.g. achievements, entities, generator.
Yellow - "hidden" - Labels that involve internals and are not as visible to players as above. e.g. storage, protocol.
Pink - "poweruser" - Labels that are relevant to admins, devs, and plugin devs. e.g. docs, lua api, configuration..
Cyan - "meta" - Labels that talk about the issues. e.g. needs-confirm, proposal, question

Green is for things suitable for newbies (namely "easy" and "ingame-testing-needed").
Red is for high priority things (namely "crash" and "important").
Reply
Thanks given by:
#10
LogicParrot, I agree with most of your labels and the system is sensible, I simply feel there are too many. If we removed some that only had 1/2 issues in them, then it would be cleaner but would not significantly affect anything.
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)