On Wed, 6 Jan 2016 at 23:56 Ezio Melotti
On Wed, Jan 6, 2016 at 8:18 PM, Brett Cannon
wrote: On Tue, 5 Jan 2016 at 23:46 Ezio Melotti
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