2018-07-23 3:28 GMT+02:00 Berker Peksağ :

On Fri, Jul 20, 2018 at 9:49 PM, Mariatta Wijaya wrote:

...

Several of its features I'd like to try out for now: - automatically add size labels on pull requests. It can analyze the content of the pull request, and apply the size labels (xs, s, m, etc)

It would be better if we use less labels, to be honest. Even now, the amount of labels and different colors make the pull request list harder to look at: https://github.com/python/cpython/pulls

And I don't find these labels useful especially if there is no way to ignore auto-generated files such as Python/importlib.h.

I concur with Berker. More and more PR look like a blinking christmas tree :-) IMHO labels doesn't add much value for the reviews. Victor

On Tue., 24 Jul. 2018, 5:17 am Carol Willing, wrote:

A couple of years ago, I completely agreed that the labels were distracting when we were using them on Jupyter. Over time, I found that they were very helpful for triaging issues and viewing status/next actions when you have a large number of PRs.

One thing that I found helped quite a bit with the Christmas tree effect was to standardize the color scheme to either all black lettering on muted color or all white lettering on bright color.

I think this is going to be the key: choosing a deliberately muted display appearance for any informational labels that are intended primarily as search aids rather than as things to pick up on a quick visual scan of the full PR list. Cheers, Nick.

As the person who chose the colour scheme, I'll try to explain why I did it the way I did. :) If you look at https://github.com/python/cpython/labels you will notice all related labels that have the same prefix are the same colour *unless* there is a reason to make it stand out (e.g. type-security). The colours also try to use appropriate colours to represent whether the label requires attention (e.g. the "needs" labels are yellow as essentially that label represents why that PR has not been merged yet). Finally, I'm enough of a visual learner that I can look at an issue and notice by colour when a label is missing. So out of habit I make sure colours are distinct so I can visually notice when an issue is lacking a certain issue type. But I'm not attached to any of this, so if someone wants to come up with a colour scheme that people can generally agree to I'm fine with changing the colours (I would prefer to avoid changing the label names, though, as that potentially will break bots and scripts, plus I hate labels that are not self-describing as they suck for new people). On Tue, 24 Jul 2018 at 06:56 Emily Morehouse wrote:

+1 for consistent muted colors

I also think it may be helpful for labels that are manually managed stand out in some way - perhaps a prefix or different shades of a specific color. That way, a core dev could easily visually filter for any labels they may need to change or care more about for a PR.

On Jul 23, 2018 at 7:22 PM, Nick Coghlan wrote:

On Tue., 24 Jul. 2018, 5:17 am Carol Willing, wrote:

...

A couple of years ago, I completely agreed that the labels were distracting when we were using them on Jupyter. Over time, I found that they were very helpful for triaging issues and viewing status/next actions when you have a large number of PRs.

One thing that I found helped quite a bit with the Christmas tree effect was to standardize the color scheme to either all black lettering on muted color or all white lettering on bright color.

I think this is going to be the key: choosing a deliberately muted display appearance for any informational labels that are intended primarily as search aids rather than as things to pick up on a quick visual scan of the full PR list.

Cheers, Nick.

...

_______________________________________________ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-leave@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

_______________________________________________ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-leave@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

Separate thread :) While I'm not expert in choosing colors, but I think it would be great for labels that indicate "action needed from human" to be more noticable and distinctive than the "informational" labels. For example: awaiting labels, CLA not signed, I consider those to be "action needed": don't merge the PR, someone should review, follow up, etc. type-tests, type-documentation, needs backport to, OS Mac/windows, are "informational" IMO. "needs backport to " are mostly for the bot most of the time, except when there's conflict. Mariatta On Thu, Jul 26, 2018 at 10:07 AM Carol Willing wrote:

...

On Jul 24, 2018, at 9:19 AM, Brett Cannon wrote:

As the person who chose the colour scheme, I'll try to explain why I did it the way I did. :)

If you look at https://github.com/python/cpython/labels you will notice all related labels that have the same prefix are the same colour unless there is a reason to make it stand out (e.g. type-security). The colours also try to use appropriate colours to represent whether the label requires attention (e.g. the "needs" labels are yellow as essentially that label represents why that PR has not been merged yet).

Finally, I'm enough of a visual learner that I can look at an issue and notice by colour when a label is missing. So out of habit I make sure

colours are distinct so I can visually notice when an issue is lacking a certain issue type. > > But I'm not attached to any of this, so if someone wants to come up with a colour scheme that people can generally agree to I'm fine with changing the colours (I would prefer to avoid changing the label names, though, as that potentially will break bots and scripts, plus I hate labels that are not self-describing as they suck for new people).

Thanks for the explanation Brett. Just for clarification, I wasn't suggesting changing label names or basic colors. I just think it is a bit more visually clean to either use all muted or all bold tones for the colors. My personal preference would be to use muted colors as they are good for visual learners as well as less distracting for those of us that get easily distracted ;-) _______________________________________________ core-workflow mailing list -- core-workflow@python.org To unsubscribe send an email to core-workflow-leave@python.org https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/ This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct

On 25 July 2018 at 02:19, Brett Cannon wrote:

As the person who chose the colour scheme, I'll try to explain why I did it the way I did. :)

If you look at https://github.com/python/cpython/labels you will notice all related labels that have the same prefix are the same colour unless there is a reason to make it stand out (e.g. type-security). The colours also try to use appropriate colours to represent whether the label requires attention (e.g. the "needs" labels are yellow as essentially that label represents why that PR has not been merged yet).

Finally, I'm enough of a visual learner that I can look at an issue and notice by colour when a label is missing. So out of habit I make sure colours are distinct so I can visually notice when an issue is lacking a certain issue type.

But I'm not attached to any of this, so if someone wants to come up with a colour scheme that people can generally agree to I'm fine with changing the colours (I would prefer to avoid changing the label names, though, as that potentially will break bots and scripts, plus I hate labels that are not self-describing as they suck for new people).

My comment about choosing neutral colours was mainly aimed at any *new* labels beyond the ones we already have. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia