Slim down repository labels #3222
Labels
No Label
#P1 CRITICAL
#P2: HIGH
#P3: elevated
#P4 priority: medium
#P6: low
#Review
annoying
API
bug
code quality
combat
commands
compatibility
configurability
contribution inside
controls
core feature
creative mode
delayed for engine release
documentation
duplicate
enhancement
environment
gameplay
graphics
ground content conflict
GUI/HUD
help wanted
incomplete feature
invalid / won't fix
items
looking for contributor
mapgen
meta
mineclone2+
Minecraft >= 1.13
Minecraft >= 1.17
missing feature
mobile
mobs
mod support
model needed
multiplayer
Needs adoption
needs discussion
needs engine change
needs more information
needs research
nodes
non-Minecraft feature
non-mob entities
performance
player
possible close
redstone
release notes
schematics
Skyblock
sounds
Testing / Retest
tools
translation
unconfirmed
mcl5
mcla
Media missing
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: VoxeLibre/VoxeLibre#3222
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
"Needs more information" does sound a bit more diplomatic than "lack of information".
was a lost thought why i renamed it but yea should keep "need more information".
Core feature is a weird one. I would say it's better to indicate that through a higher priority. It is quite vague.
enhancement and non-minecraft feature are probably the same. I prefer the first. It's more positive sounding. Needs discussion can be added if it's a little controversial.
I think incomplete and missing are useful. One is where someone has dev'ed something and left it or it's still a WIP but maybe lower priority. Missing implies it hasn't had any attention or wasn't thought about (maybe newer stuff). I would say incomplete probably needs attention before missing, but it's quite subjective and open to discussion.
I think we should kill off any minecraft version tags. It's not relevant, we have new stuff from any version and I don't think it is that important anymore.
I like gameplay. It indicates it's something that affects the gameplay. People play this for a few reasons:
survival -starting, getting to the ender dragon and farms. This is gameplay for me. Maybe this is a clash with core feature, I do not know.
building - these are more creative and cosmetic but people place value on them.
I think this makes sense.
If you're suggesting merging needs research and needs code research, I think that's a valid call. You can say what research is needed in a comment.
Things I will add in:
Bug - Anything that isn't a missing feature or unconfirmed is a bug. Do we really need it? It will just go on every issue and doesn't really help in any way.
API - I think this just should be tagged as code quality. How things are surfaced (either via API, or other strategy) is quality. It determines how cohesive or coupled something is. API is a strategy, not a classification.
Testing/review needed - All PR's not in WIP need testing and reviewing. I don't think this tag serves it's purpose.
mcla/mcl5 - I don't think these are relevant anymore. They have their own repos, but aren't active.
mcla/mcl5 should be changed to "Not MineClone 2" and is useful for tagging issues that really aren't our game. (Raised due to confusion.)
On the "features" labels, we need a "Requested Feature" for those asking for something to be added in.
"Not Minecraft" -- fair.
"Incomplete feature" - useful because it means that it's something that was put in with the "shoot for good enough, not for perfect" mindset, and should be used to remind someone that "hey, this isn't done yet."
"Missing feature", indicates that this should be in, but isn't... And without the correct labels, "missing feature" gets applied a lot, when it really shouldn't.
An example of this being "I really want hang gliders" -- "missing feature" is tagged, and it's really not appropriate. In this example "Requested Feature" (Or, Feature Request) would be 100x better. Or, a better example... When something looks like it might be a Minecraft thing, but it isn't... Missing Feature becomes it's primary label. Requested feature would work here because it would offer the opportunity to go check, rather than implying "Hey, we missed this and absolutely need to add it in!"
I thought that when it is confirmed to be a valid bug, that's when the bug label gets applied.
Maybe, a discussion post explaining how to use the labels would help? Or, a pr to put that into the CONTRIBUTING.MD so that it's in the game files and doesn't get lost?
Also, the "gameplay" tag is to delineate that this is a game mechanics related issue. As game mechanics directly controls how the gameplay experience occurs. And, it pairs really well with the features or bug labels.
Note, I am not opposed to having a "Gameplay bug" or "gameplay issue" label in it's place.
Also, since these tags are organization wide, we should put in labels specific to the ModPack add on. In doing this we can effectively state that "whatever" is better suited for being placed into the modpack instead of in the core game. Just something to consider.
i'd prefer if someone with maintainer status resolves this. since, they can also update the organisational tags.
correct tagging of old issues and PRs can come later.
I'm only discussing this. I mean, that's what the post is for -- discussion. And, I was sharing how I saw things and I also pointed out that we now have to take into account that we have a modpack and the main game to consider. I pointed to "old issues" from the past two or so weeks as an example of where not having the correct tags has been an issue. Not like I was talking about something from 2 or 3 years ago.
I have started going through issues and looking into labels. I have tried to label things as low priority or elevated or higher, everything else is medium or unclassified atm. I will try to ensure these are processed.
My feelings so far is:
Merge invalid and won't fix. It doesn't need 2 tags.
Merge api and code quality
Remove Minecraft >= 1.13, but added a 1.17 (we're long past 1.13, but 1.17 is still new, and many don't add to the gameplay. We won't refuse these, but it is better to improve what we have before throwing in new stuff. If something adds to the gameplay, and is justifiable, I would have no objections)
Merge configuration and commands maybe, or commands go in with GUI/HUD as it's how people interact/interface with the game (not graphical necessarily)
I created:
environment - there is a lot of weather stuff that crops up, it would be good to group. lighting can go with this
compatibility - Many players upgrade worlds. They invest in and care about their worlds. Now we aren't alpha, we need to think how we can bring players along with us. Losing a world could lose players after they've emotionally invested. Also Mcl5 compatibility for those that migrate over. LBMs for nodes/alias, converting items in invent are problems we'll need to solve and we can roll that pattern out easier once we have these down and agreed.
I am still thinking about a few more.
Any feedback is appreciated. :)
Does fire go into
environment
?And, I always think that I wish that I had.... as a label, usually with Liberty's issues. But, I never write them down... so...
That sounds like the right place for it.