I'm interested to try out Gitmate, and I've requested the permission for it to be installed in Python GitHub organization. https://gitmate.io/ 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) - apply stale label for inactive pull requsts gitmate has been used by coala. Here is an example of a PR where it automatically add stale, size labels, and also checks of PEP 8 compliance: https://github.com/coala/coala/pull/4818 I find the code analysis feature of gitmate (checking for PEP 8 etc) is too noisy, so I don't think we should add it now. If it works for the devguide or core workflow, perhaps later we can try adding this to cpython too? Mariatta
On Fri, Jul 20, 2018 at 9:49 PM, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
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.
- apply stale label for inactive pull requsts
When will we apply the stale label? Is there a way to apply it for multiple reasons? For example, 1) PRs older than a year 2) PRs need rebase 3) PRs update Misc/NEWS --Berker
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.
On Tue., 24 Jul. 2018, 5:17 am Carol Willing, <willingc@gmail.com> wrote:
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.
+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 <ncoghlan@gmail.com> wrote: On Tue., 24 Jul. 2018, 5:17 am Carol Willing, <willingc@gmail.com> wrote:
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
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 <emilyemorehouse@gmail.com> wrote:
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 ;-)
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 <willingc@gmail.com> wrote:
On 27 July 2018 at 03:56, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
Aye, that's the kind of breakdown I had in mind when I suggested using muted colours (but didn't express very well). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
As an update, I've configured gitmate in devguide and core-workflow repos as an experiment. I have not added it to CPython yet. Disabling gitmate is as simple as one click. I've made it to apply `status-stale` labels on pull requests, and `size-{XS,S,M,L,XL}` to pull requests.
When will we apply the stale label?
The number of days can be configured. For now I've set it to apply the `status-stale` label if it has no activities after 60 days. Stale PRs in core-workflow and devguide: https://github.com/python/core-workflow/pulls?q=is%3Aopen+is%3Apr+label%3Ast... https://github.com/python/devguide/pulls?q=is%3Aopen+is%3Apr+label%3Astatus-... PRs don't get automatically closed, but I would like for maintainers and bug triagers to go over PRs with such labels periodically, and either ask for an update, or make judgement to close them due to inactivity. Especially if a core dev has requested changes, but the PR author did not respond. Is there a way to apply it for
multiple reasons? For example, 1) PRs older than a year
Yes if people think 1 year is more reasonable than 2 months, then I can update it to 1 year.
2) PRs need rebase
There is an open PR [1] to detect this, sadly it is also stale (waiting for me to review) 3) PRs update Misc/NEWS You mean if it is missing news file? We already have it as a status check, if would also like a `needs misc/news` label, it won't be too difficult to do. More and more PR look like a blinking christmas
tree :-) IMHO labels doesn't add much value for the reviews.
Thanks for sharing your point of view. I find labels useful, especially when needing to search for issues in specific categories. For example, periodically I would go over all PRs that have the labels: `CLA not signed`, `needs backport to `, `awaiting merge`, `awaiting core review`. Without labels like those I would have to go over each PR one by one. It might seem more messy when viewing all PRs but I can live with it. When reviewing an individual PR, the labels are on the right side and not interfering with the discussion on the left. About the size labels, the idea is to quickly identify the size of the PR (based on number of lines changed), and people looking to help review PRs can use the labels to help decide which PR they want to review. For example, when I know I don't have a lot of free time available, I'll be able to look for PRs with labels size-XS or size-S. When I have more free time, I can look into size-L PRs. New contributors and new reviewers might be more comfortable reviewing size-XS and size-S PRs to start, and they can use the labels to filter PRs. While smaller size PRs don't always not necessarily mean easier decision making time, but sometimes it can be a good indication. Mariatta
Update: I've disabled gitmate's ability to automatically add size labels based on the size of the PR. When it applied the "size-XS" label, it removed the "CLA signed" label already applied by the-knights-who-say-ni. ni is smart enough to reapply the label, but I don't think this feature is ready for us, and definitely not for CPython, where we have other bots applying other labels. I've filed a bug: https://gitlab.com/gitmate/open-source/gitmate-2/issues/393 I've enabled gitmate's ability to detect duplicate issues across Python projects. It will post a message like this: "GitMate.io <https://gitmate.io/> thinks possibly related issues are #1 (issue 1 title), #2 (issue 2 title), and #3 (issue 3 title)" I don't yet know how accurate it will be, but that's why I'm experimenting. gitmate is currently only installed in devguide, core-workflow, and miss-islington. If there is interest in adding it in other repos, please let me know. Mariatta On Fri, Jul 20, 2018 at 11:49 AM Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
On Fri, Jul 20, 2018 at 9:49 PM, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
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.
- apply stale label for inactive pull requsts
When will we apply the stale label? Is there a way to apply it for multiple reasons? For example, 1) PRs older than a year 2) PRs need rebase 3) PRs update Misc/NEWS --Berker
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.
On Tue., 24 Jul. 2018, 5:17 am Carol Willing, <willingc@gmail.com> wrote:
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.
+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 <ncoghlan@gmail.com> wrote: On Tue., 24 Jul. 2018, 5:17 am Carol Willing, <willingc@gmail.com> wrote:
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
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 <emilyemorehouse@gmail.com> wrote:
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 ;-)
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 <willingc@gmail.com> wrote:
On 27 July 2018 at 03:56, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
Aye, that's the kind of breakdown I had in mind when I suggested using muted colours (but didn't express very well). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
As an update, I've configured gitmate in devguide and core-workflow repos as an experiment. I have not added it to CPython yet. Disabling gitmate is as simple as one click. I've made it to apply `status-stale` labels on pull requests, and `size-{XS,S,M,L,XL}` to pull requests.
When will we apply the stale label?
The number of days can be configured. For now I've set it to apply the `status-stale` label if it has no activities after 60 days. Stale PRs in core-workflow and devguide: https://github.com/python/core-workflow/pulls?q=is%3Aopen+is%3Apr+label%3Ast... https://github.com/python/devguide/pulls?q=is%3Aopen+is%3Apr+label%3Astatus-... PRs don't get automatically closed, but I would like for maintainers and bug triagers to go over PRs with such labels periodically, and either ask for an update, or make judgement to close them due to inactivity. Especially if a core dev has requested changes, but the PR author did not respond. Is there a way to apply it for
multiple reasons? For example, 1) PRs older than a year
Yes if people think 1 year is more reasonable than 2 months, then I can update it to 1 year.
2) PRs need rebase
There is an open PR [1] to detect this, sadly it is also stale (waiting for me to review) 3) PRs update Misc/NEWS You mean if it is missing news file? We already have it as a status check, if would also like a `needs misc/news` label, it won't be too difficult to do. More and more PR look like a blinking christmas
tree :-) IMHO labels doesn't add much value for the reviews.
Thanks for sharing your point of view. I find labels useful, especially when needing to search for issues in specific categories. For example, periodically I would go over all PRs that have the labels: `CLA not signed`, `needs backport to `, `awaiting merge`, `awaiting core review`. Without labels like those I would have to go over each PR one by one. It might seem more messy when viewing all PRs but I can live with it. When reviewing an individual PR, the labels are on the right side and not interfering with the discussion on the left. About the size labels, the idea is to quickly identify the size of the PR (based on number of lines changed), and people looking to help review PRs can use the labels to help decide which PR they want to review. For example, when I know I don't have a lot of free time available, I'll be able to look for PRs with labels size-XS or size-S. When I have more free time, I can look into size-L PRs. New contributors and new reviewers might be more comfortable reviewing size-XS and size-S PRs to start, and they can use the labels to filter PRs. While smaller size PRs don't always not necessarily mean easier decision making time, but sometimes it can be a good indication. Mariatta
Update: I've disabled gitmate's ability to automatically add size labels based on the size of the PR. When it applied the "size-XS" label, it removed the "CLA signed" label already applied by the-knights-who-say-ni. ni is smart enough to reapply the label, but I don't think this feature is ready for us, and definitely not for CPython, where we have other bots applying other labels. I've filed a bug: https://gitlab.com/gitmate/open-source/gitmate-2/issues/393 I've enabled gitmate's ability to detect duplicate issues across Python projects. It will post a message like this: "GitMate.io <https://gitmate.io/> thinks possibly related issues are #1 (issue 1 title), #2 (issue 2 title), and #3 (issue 3 title)" I don't yet know how accurate it will be, but that's why I'm experimenting. gitmate is currently only installed in devguide, core-workflow, and miss-islington. If there is interest in adding it in other repos, please let me know. Mariatta On Fri, Jul 20, 2018 at 11:49 AM Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
participants (7)
-
Berker Peksağ -
Brett Cannon -
Carol Willing -
Emily Morehouse -
Mariatta Wijaya -
Nick Coghlan -
Victor Stinner