Slim down repository labels #3222

Open
opened 2022-12-31 12:26:15 +01:00 by Ghost · 10 comments
  • core feature: i think this is more confusing than helpful at describing the problem. remove it.
  • enhancement, incomplete feature, missing feature, non-Minecraft feature, Minecraft >= 1.13: some of these have overlapping nuances. I think reducing this to only 2 is enough:
    • missing feature
    • non-minecraft feature
  • gameplay: most egregious of all. this isn't very helpful tbh, and very confusing. remove it.
  • help wanted, looking for contributor: these to me are fine, but the latter should be repurposed for new contributors. for first contributions?
  • needs code research, needs more information, needs research, unconfirmed: Nuances of these 3 are not clear. Here's what I propose:
    • unconfirmed: for when it's unclear about what bug is being reported.
    • needs more information: when it's unclear about what the feature request is about.
    • needs research: when it's clear what the issue is about, but resolving it needs research e.g. MCL2 mob behaviour research, MTE behaviour research, Minecraft research, etc.
- **core feature**: i think this is more confusing than helpful at describing the problem. remove it. - **enhancement**, **incomplete feature**, **missing feature**, **non-Minecraft feature**, **Minecraft >= 1.13**: some of these have overlapping nuances. I think reducing this to only 2 is enough: - **missing feature** - **non-minecraft feature** - **gameplay**: most egregious of all. this isn't very helpful tbh, and very confusing. remove it. - **help wanted**, **looking for contributor**: these to me are fine, but the latter should be repurposed for new contributors. **for first contributions**? - **needs code research**, **needs more information**, **needs research**, **unconfirmed**: Nuances of these 3 are not clear. Here's what I propose: - **unconfirmed**: for when it's unclear about what bug is being reported. - **needs more information**: when it's unclear about what the feature request is about. - **needs research**: when it's clear what the issue is about, but resolving it needs research e.g. MCL2 mob behaviour research, MTE behaviour research, Minecraft research, etc.
Ghost added the
needs discussion
meta
labels 2022-12-31 12:26:15 +01:00
Contributor

"Needs more information" does sound a bit more diplomatic than "lack of information".

"Needs more information" does sound a bit more diplomatic than "lack of information".
Author

was a lost thought why i renamed it but yea should keep "need more information".

was a lost thought why i renamed it but yea should keep "need more information".
  • core feature: i think this is more confusing than helpful at describing the problem. remove it.

Core feature is a weird one. I would say it's better to indicate that through a higher priority. It is quite vague.

  • enhancement, incomplete feature, missing feature, non-Minecraft feature, Minecraft >= 1.13: some of these have overlapping nuances. I think reducing this to only 2 is enough:
    • missing feature
    • non-minecraft feature

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.

  • gameplay: most egregious of all. this isn't very helpful tbh, and very confusing. remove it.

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.

  • help wanted, looking for contributor: these to me are fine, but the latter should be repurposed for new contributors. for first contributions?

I think this makes sense.

  • needs code research, needs more information, needs research, unconfirmed: Nuances of these 3 are not clear. Here's what I propose:
    • unconfirmed: for when it's unclear about what bug is being reported.
    • needs more information: when it's unclear about what the feature request is about.
    • needs research: when it's clear what the issue is about, but resolving it needs research e.g. MCL2 mob behaviour research, MTE behaviour research, Minecraft research, etc.

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.

> - **core feature**: i think this is more confusing than helpful at describing the problem. remove it. Core feature is a weird one. I would say it's better to indicate that through a higher priority. It is quite vague. > - **enhancement**, **incomplete feature**, **missing feature**, **non-Minecraft feature**, **Minecraft >= 1.13**: some of these have overlapping nuances. I think reducing this to only 2 is enough: > - **missing feature** > - **non-minecraft feature** 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. > - **gameplay**: most egregious of all. this isn't very helpful tbh, and very confusing. remove it. 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. > - **help wanted**, **looking for contributor**: these to me are fine, but the latter should be repurposed for new contributors. **for first contributions**? I think this makes sense. > - **needs code research**, **needs more information**, **needs research**, **unconfirmed**: Nuances of these 3 are not clear. Here's what I propose: > - **unconfirmed**: for when it's unclear about what bug is being reported. > - **needs more information**: when it's unclear about what the feature request is about. > - **needs research**: when it's clear what the issue is about, but resolving it needs research e.g. MCL2 mob behaviour research, MTE behaviour research, Minecraft research, etc. 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.
Member

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

  • enhancement, incomplete feature, missing feature, non-Minecraft feature, Minecraft >= 1.13: some of these have overlapping nuances. I think reducing this to only 2 is enough:
    • missing feature
    • non-minecraft feature

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!"

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.

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?

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.) > - **enhancement**, **incomplete feature**, **missing feature**, **non-Minecraft feature**, **Minecraft >= 1.13**: some of these have overlapping nuances. I think reducing this to only 2 is enough: > - **missing feature** > - **non-minecraft feature** 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!" > 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. 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?
Member

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.

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

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'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.
Member

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'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.
ancientmarinerdev added the
#P3: elevated
label 2023-02-02 21:34:54 +01:00

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

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

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

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

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.

> 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.
ancientmarinerdev added this to the 3 - Near future milestone 2023-03-29 01:23:46 +02:00
ancientmarinerdev added
#P4 priority: medium
and removed
#P3: elevated
labels 2023-03-29 01:23:51 +02:00
ancientmarinerdev added the
#Review
label 2023-05-09 16:31:48 +02:00
ancientmarinerdev removed this from the 3 - Near future milestone 2023-05-09 16:41:44 +02:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: VoxeLibre/VoxeLibre#3222
No description provided.