Hi everyone, Here at the yt developers workshop, we're experimenting with bots that will help us with some project management. For example, we're about to enable a bot that will prevent WIP pull requests from being merged. When we're done, we'll send a summary email of everything we've done. If anyone starts seeing weird behavior on the github repo or with PRs, either reply to this email or say something on slack. We'll try to keep the noise down. Britton
I just issued a PR for pep8speaks -- we may try that out too, and hopefully it won't make too much noise... On Tue, Mar 5, 2019 at 2:50 PM Britton Smith <brittonsmith@gmail.com> wrote:
Hi everyone,
Here at the yt developers workshop, we're experimenting with bots that will help us with some project management. For example, we're about to enable a bot that will prevent WIP pull requests from being merged. When we're done, we'll send a summary email of everything we've done. If anyone starts seeing weird behavior on the github repo or with PRs, either reply to this email or say something on slack. We'll try to keep the noise down.
Britton _______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org
One thing we talked about that might be a bit noisier than I would like to champion is using a combination of "triage" with "release notes drafter". What this would mean: 1) We'd enable the Triage bot: https://probot.github.io/apps/triage-new-issues/ 2) We'd add labels for enhancements, bug fixes, etc, and *make sure* we use them. Basically, no accepting PRs unless "triage" is gone. 3) We'd enable the Release Drafter bot: https://probot.github.io/apps/release-drafter/ What this would mean is that for every release, we'd get a release notes drafted for us that would include links to the PRs and would break things out by category and whatnot. I think it could simplify the release process a fair bit. Does anyone have strong objections to doing this? The triage step seems like a more invasive change than the release notes change, but I think that it would certainly help us move toward having a more clearly defined workflow. -Matt On Tue, Mar 5, 2019 at 2:52 PM Matthew Turk <matthewturk@gmail.com> wrote:
I just issued a PR for pep8speaks -- we may try that out too, and hopefully it won't make too much noise...
On Tue, Mar 5, 2019 at 2:50 PM Britton Smith <brittonsmith@gmail.com> wrote:
Hi everyone,
Here at the yt developers workshop, we're experimenting with bots that will help us with some project management. For example, we're about to enable a bot that will prevent WIP pull requests from being merged. When we're done, we'll send a summary email of everything we've done. If anyone starts seeing weird behavior on the github repo or with PRs, either reply to this email or say something on slack. We'll try to keep the noise down.
Britton _______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org
On Tue, Mar 5, 2019 at 3:54 PM Matthew Turk <matthewturk@gmail.com> wrote:
One thing we talked about that might be a bit noisier than I would like to champion is using a combination of "triage" with "release notes drafter". What this would mean:
1) We'd enable the Triage bot: https://probot.github.io/apps/triage-new-issues/ 2) We'd add labels for enhancements, bug fixes, etc, and *make sure* we use them. Basically, no accepting PRs unless "triage" is gone. 3) We'd enable the Release Drafter bot: https://probot.github.io/apps/release-drafter/
What this would mean is that for every release, we'd get a release notes drafted for us that would include links to the PRs and would break things out by category and whatnot. I think it could simplify the release process a fair bit.
Does anyone have strong objections to doing this? The triage step seems like a more invasive change than the release notes change, but I think that it would certainly help us move toward having a more clearly defined workflow.
Do the release notes get drafted only based on github pull request descriptions? Or does it use a file in the repository? If the latter and if there is only one such file for the whole repository this sort of scheme is a recipe for generating merge conflicts. If it's only based on GitHub pull request descriptions that sounds nice.
-Matt
On Tue, Mar 5, 2019 at 2:52 PM Matthew Turk <matthewturk@gmail.com> wrote:
I just issued a PR for pep8speaks -- we may try that out too, and hopefully it won't make too much noise...
On Tue, Mar 5, 2019 at 2:50 PM Britton Smith <brittonsmith@gmail.com>
wrote:
Hi everyone,
Here at the yt developers workshop, we're experimenting with bots that
will help us with some project management. For example, we're about to enable a bot that will prevent WIP pull requests from being merged. When we're done, we'll send a summary email of everything we've done. If anyone starts seeing weird behavior on the github repo or with PRs, either reply to this email or say something on slack. We'll try to keep the noise down.
Britton _______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org
yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org
On Tue, Mar 5, 2019 at 3:56 PM Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Tue, Mar 5, 2019 at 3:54 PM Matthew Turk <matthewturk@gmail.com> wrote:
One thing we talked about that might be a bit noisier than I would like to champion is using a combination of "triage" with "release notes drafter". What this would mean:
1) We'd enable the Triage bot: https://probot.github.io/apps/triage-new-issues/ 2) We'd add labels for enhancements, bug fixes, etc, and *make sure* we use them. Basically, no accepting PRs unless "triage" is gone. 3) We'd enable the Release Drafter bot: https://probot.github.io/apps/release-drafter/
What this would mean is that for every release, we'd get a release notes drafted for us that would include links to the PRs and would break things out by category and whatnot. I think it could simplify the release process a fair bit.
Does anyone have strong objections to doing this? The triage step seems like a more invasive change than the release notes change, but I think that it would certainly help us move toward having a more clearly defined workflow.
Do the release notes get drafted only based on github pull request descriptions? Or does it use a file in the repository? If the latter and if there is only one such file for the whole repository this sort of scheme is a recipe for generating merge conflicts.
If it's only based on GitHub pull request descriptions that sounds nice.
I *believe* it does it based only on the PR descriptions. I'm also pretty sure it does not put it into the repository, but instead into the "Releases" page, so we'd manually copy/paste or something from that to the other. It also puts it in draft mode, so it can be edited at a later time.
-Matt
On Tue, Mar 5, 2019 at 2:52 PM Matthew Turk <matthewturk@gmail.com> wrote:
I just issued a PR for pep8speaks -- we may try that out too, and hopefully it won't make too much noise...
On Tue, Mar 5, 2019 at 2:50 PM Britton Smith <brittonsmith@gmail.com> wrote:
Hi everyone,
Here at the yt developers workshop, we're experimenting with bots that will help us with some project management. For example, we're about to enable a bot that will prevent WIP pull requests from being merged. When we're done, we'll send a summary email of everything we've done. If anyone starts seeing weird behavior on the github repo or with PRs, either reply to this email or say something on slack. We'll try to keep the noise down.
Britton _______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org
participants (3)
-
Britton Smith -
Matthew Turk -
Nathan Goldbaum