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

[Ezio Melotti]

On Thu, Jan 7, 2016 at 7:21 PM, Brett Cannon <brett at python.org> wrote:
>
>
> 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?
>

The goal is to generate at least 1 message/email if a review (possibly
comprising several comments) is posted.
If there are no new comments, nothing is posted, but if there are new
comments, a new message will be posted at some point.
We just need to find a compromise between delay and number of messages
(and that's something we can figure out later with a bit of trial and
error).
Checking daily might result in hours of delay, but no more than one
daily message.
Checking hourly has less delay, but it might result in more messages.
We can also try to do something smarter by checking e.g. every 15
minutes and posting the message only if no new messages have been
added in the last 15 minutes (so the reviewer has likely finished
commenting).

>>
>>
>> >>
>> >> 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 a good way to see it.

Best Regards,
Ezio Melotti

> 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