+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Github Label System Explained (/thread-2801.html)
Github Label System Explained - LogicParrot - 01-16-2017
Colors meaning:
Blue - "ingame/" - Things that can be seen in-game by players.
Pink - "poweruser/" - Things that are relevant to server owners or plugin devs.
Yellow - "internals/" - Things that cannot be seen in-game and aren't "poweruser/"
Cyan - "type/" - The type of the issue. (proposal / question / meta).
Purple - "status/" - The status of the issue.
Red and green are special. Green is used to mark newbie-friendly tasks and some filters to those labels are linked to from the Cuberite Manual. Red is for crashes or for serious issues.
RE: Github Label System Explained - LogicParrot - 01-16-2017
(01-16-2017, 02:20 AM)sphinxc0re Wrote: I agree with all of you. I also think that if we want to get a little bit more serious about this project that we should start organizing and prioritizing issues so that we can easily distinguish between easy and hard, important and unimportant. That would mean putting issues into GH projects but also touching the messy labels. I like how ruma manages their labels: https://github.com/ruma/ruma/labels
I don't think our labels are messy. In fact they are similar to your example, except the prefixes are omitted from Github. I can add them if you'd like. Also, our "component/" prefix needs to be a lot more finegrained than Ruma's because we have a lot more components and this facilitates fast lookups. So our "component" is "ingame + poweruser + internals".
We don't need a finegrained "type/" because most issues have overlapping types and we've tried this before. It's both messy and meaningless. We rarely need to lookup by type either.
We have no "effort/" currently.
RE: Github Label System Explained - LogicParrot - 01-16-2017
I added the prefixes to Github.
RE: Github Label System Explained - LogicParrot - 01-16-2017
Further finegraining "status/" (e.g. accepted, under discussion, blocked by other issues, rejected, resolved) may or may not be useful.
RE: Github Label System Explained - sphinxc0re - 01-16-2017
I think we should always evaluate the effort of an issue. That makes it easier for us to evaluate the time needed for the solution and also makes it easier to get juniors to work at easier issues
RE: Github Label System Explained - LogicParrot - 01-18-2017
I see you've added effort/. I'll edit the initial post.
I think newbie-friendly labels should remain green though, so I reverted "effort/easy" and "status/ingame-testing-needed" to green.