[core-workflow] My initial thoughts on the steps/blockers of the transition

[Brett Cannon]

On Wed, 6 Jan 2016 at 23:56 Ezio Melotti <ezio.melotti at gmail.com> wrote:

> On Wed, Jan 6, 2016 at 8:18 PM, Brett Cannon <brett at python.org> wrote:
> >
> >
> > On Tue, 5 Jan 2016 at 23:46 Ezio Melotti <ezio.melotti at gmail.com> wrote:
> >> ...
> >> If you agree, this is what needs to be done:
> >> 1) automatically add PRs to b.p.o issues;
> >
> >
> > This is a blocker.
> >
> >>
> >> 2) automatically add a message on b.p.o when a review is posted on
> github;
> >
> >
> > With the way GitHub does reviews, this won't make sense. Each comment on
> a
> > PR is essentially its own review (as Eric complained about because that
> > means each comment is treated as a separate thing and thus generates its
> own
> > email). It isn't like with Rietveld where there is a "Review + Email"
> step
> > to send draft reviews and hence a review is a group of comments.
> >
>
> Good to know.
> I can think of two alternative solutions:
> 1) have a "number of comments" and "date/time of the last comment"
> next to the PR, and update it whenever a new comment is posted;
> 2) check periodically for new comments, aggregate them somehow, and
> post a "X new comments have been added to PR Y." message;
>

Either of those ideas work for me. Would option #2 be done as a comment and
thus send out what amounts to a summary email of PR review comments? As
long as we do that **only** when there have been changes and not blindly
doing it every day (e.g., no "0 comments since yesterday" email), that
would be acceptable to me in terms of email volume. Do the other people who
wanted to follow PRs on b.p.o like that level of frequency?


>
> >>
> >> 3) add a "github username" field to b.p.o users to link accounts;
> >
> >
> > That's a blocker for CLA enforcement.
> >
> >>
> >> 4) automatically add the PR author (during step 1) and reviewers
> >> (during step 2) to the issue nosy list on b.p.o;
> >
> >
> > I view this as a great nicety but not a blocker.
> >
>
> OK, I considered this a blocker because otherwise PR authors and
> reviewers might miss b.p.o comments, but we can let them know manually
> until it's implemented.
>

Yep, exactly. I want to block on key stuff that would make GitHub worse
than what we have now, but not on stuff that makes it better. This is
obviously not to say that I don't want to see all of these great
improvements happen, but I do want to get over to the new workflow sooner
rather than later as I suspect contributors will find it much easier to
work with.

-Brett


>
> Best Regards,
> Ezio Melotti
>
> >>
> >> 5) add an option to disable review emails (optional);
> >
> >
> > This will have to be discussed in connection with the emails per PR
> comment
> > in case there is a misunderstanding of what a review on GitHub is.
> >
> >>
> >>
> >> I would consider all these points except the 5th as blockers.
> >
> >
> > Obviously I don't think they all are, but definitely some.
> >
> > -Brett
> >
> >>
> >>
> >> Best Regards,
> >> Ezio Melotti
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160107/3a5cc1b2/attachment.html>