You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the good end game way to have properly defined colors for each label would be to have a git-bug config where admins could define various properties including what label exist and their colors, define what status exist for a bug and how you can transition from one status to another ... but we are not there yet
migrate the webui color code into the core. That way, a label will have the same color in all UIs, will get simpler and the core APIs will be ready for the end game
when we have the code to define the config, we will just have to plug that in the core and we will have either automatic label colors or configured labels if users care enough to define them.
@j-f1 good point. That should be fairly easy to reduce the color precision to 16 or 8bits. I'm a bit confused as to how one is supposed to detect the terminal capabilities. I have the same question for how to detect the terminal size btw.
Here’s a series of checks (in JavaScript, from the supports-color module) that determine the level of color support. Please @mention me if you have any questions about what it’s doing:
if(env.COLORTERM==='truecolor'){return3;}if('TERM_PROGRAM'inenv){constversion=parseInt((env.TERM_PROGRAM_VERSION||'').split('.')[0],10);switch(env.TERM_PROGRAM){case'iTerm.app':
returnversion>=3 ? 3 : 2;case'Apple_Terminal':
return2;// No default}}if(/-256(color)?$/i.test(env.TERM)){return2;}if(/^screen|^xterm|^vt100|^vt220|^rxvt|color|ansi|cygwin|linux/i.test(env.TERM)){return1;}if('COLORTERM'inenv){return1;}if(env.TERM==='dumb'){returnmin;}
Labels should be displayed everywhere with the correct color, but you can't choose the color yourself. That would require a proper configuration data structured stored in git and shared.
I second @vtexier. On the CLI and TUI, displaying a (coloured) character (e.g. the first letter of the label) would be much more useful than the current square.
I just created 2 labels on a repo and git-bug chose exactly the same colour for them.
it is primarily useful for larger backlogs as a way to indicate where some attention is needed, e.g. what has gone unattended for a long time and should be looked at.
Activity
MichaelMure commentedon Oct 4, 2018
My thought on this:
My proposal:
j-f1 commentedon Oct 4, 2018
For the termui, there needs to be a fallback for the colors since some terminals only support 16 or 256 colors.
MichaelMure commentedon Oct 4, 2018
@j-f1 good point. That should be fairly easy to reduce the color precision to 16 or 8bits. I'm a bit confused as to how one is supposed to detect the terminal capabilities. I have the same question for how to detect the terminal size btw.
j-f1 commentedon Oct 4, 2018
Here’s a series of checks (in JavaScript, from the
supports-colormodule) that determine the level of color support. Please @mention me if you have any questions about what it’s doing:source
MichaelMure commentedon Oct 5, 2018
@j-f1 Thanks
More info on the subject: https://gist.github.com/XVilka/8346728
I found a go implementation: https://github.com/xo/terminfo/blob/master/color.go#L49-L91
MichaelMure commentedon May 22, 2019
Label's color are now defined directly in the core and used in the webUI through the graphQL API.
Next steps are:
MichaelMure commentedon Jul 5, 2019
Code used by Github's hub command to display labels: https://github.com/github/hub/blob/master/utils/color.go
kondanta commentedon Jun 17, 2020
Mind if I ask the current state of this issue?
MichaelMure commentedon Jun 17, 2020
Labels should be displayed everywhere with the correct color, but you can't choose the color yourself. That would require a proper configuration data structured stored in git and shared.
kondanta commentedon Jun 18, 2020
Alright, I understand. Do you planning to support colour selection in near future?
MichaelMure commentedon Jun 18, 2020
Probably not as there is some significant development with higher priority (some being required to implement that feature).
vtexier commentedon Nov 12, 2020
My git-bug choose the same color for two labels on a total of three labels!
A silly idea: replace or add to colors a special character symbol.
Color blind people, and others could distinguish issues more easily...
dllud commentedon Aug 3, 2022
I second @vtexier. On the CLI and TUI, displaying a (coloured) character (e.g. the first letter of the label) would be much more useful than the current square.
I just created 2 labels on a repo and git-bug chose exactly the same colour for them.
github-actions commentedon Jul 23, 2024
This bot triages untriaged issues and PRs according to the following rules:
lifecycle/stalelabel is appliedlifecycle/stalewas applied, the issue is closedTo remove the stale status, you can:
lifecycle/stalelabeldllud commentedon Jul 24, 2024
Well, spamming the issue then…
It's still relevant to me. I wouldn't like it to be closed by a bot.
(I find this kind of bot detrimental. What's the problem with keeping unfixed issues open?…)
sudoforge commentedon Aug 3, 2024
👋 hey there, i added the stale bot workflow. it's since been refactored so that it will never close issues or pull requests.
it is primarily useful for larger backlogs as a way to indicate where some attention is needed, e.g. what has gone unattended for a long time and should be looked at.
github-actions commentedon Nov 4, 2024
This bot triages issues in order to help the maintainers identify what
needs attention, according to the following lifecycle rules:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedThis bot will not automatically close stale issues.
To remove the stale status, you can:
To avoid automatic lifecycle management of this issue, add
lifecycle/frozen.