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

[Ezio Melotti]

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;

>>
>> 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.

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