On Wed, 6 Jan 2016 at 23:56 Ezio Melotti <ezio.melo...@gmail.com> wrote:
> On Wed, Jan 6, 2016 at 8:18 PM, Brett Cannon <br...@python.org> wrote: > > > > > > On Tue, 5 Jan 2016 at 23:46 Ezio Melotti <ezio.melo...@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 >
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
