-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document requirements for a language color change #4487
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It took all my effort not to review this with only s/color/colour/
, but I managed.
If there are official branding guidelines to support the colour choice, please link to those too. | ||
|
||
Please note that Linguist currently implements a [color proximity test][color-proximity-test] to ensure colors are sufficiently different from one another so you may not be able to use the precise color you want - reds and blues are really popular. | ||
As such, we recommend you test the color change locally before making your plea to the wider language community. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before we promulgate this as a restriction, we should really wait for the final consensus as to whether or not the colour-proximity requirements will ever be axed in future.
We have no idea how long it might take to reach a consensus. Members of a language's community could spend weeks bikeshedding as to whether a compromise for their project's official branding should be taken, simply their shade of red was too close to 5-6 other shades of red. How bad would we (GitHub/Linguist) look if the colour restriction was suddenly abolished the day after they reached an agreement?
Obviously we can't expect it to take that long to decide on a hex colour value, but you know what people are like...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before we promulgate this as a restriction, we should really wait for the final consensus as to whether or not the colour-proximity requirements will ever be axed in future.
We may be waiting a while. I've given my issue a nudge to see if I can get a quick response, but it's in a long list of other higher priority issues. The best thing to do is assume the status quo for now, we can easily remove the note when we remove the test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, then.
I might be getting anxious for the outcome because there's a lot hanging on the removal of proximity requirements. We can finally degroup the languages touched on in #4291, add official colours for data/prose formats (which matters now that we have linguist-detectable
), and a whole heap of other nags...
😆 It really hurt to write "color" so many times but it's GitHub's preferred version of English so we gotta use it. |
Description
Changing a language's colour has become a bit of a hot topic recently so I'm adding a section to the CONTRIBUTING.md, PR template and issue template advising on what is now required for a colour change.
Checklist:
Doesn't apply as this is a documentation change.