[python-committers] Github reviews are cannibalizing BPO

[Paul Moore]

On 2 May 2017 at 20:42, Donald Stufft <donald at stufft.io> wrote:
>
> On May 2, 2017, at 3:09 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>
>> This doesn't have much to do with UX/UI. It's mainly a questions
>> of culture. Github is more geared up for a culture of quick chat
>> style comments, whereas bpo has traditionally seen a more elaborate
>> in-depth discussions style.
>
> This is not really accurate to my experience using GitHub. In pip for
> example while we have distutils-sig and a pypa-dev mailing list we hardly
> ever use them for pip focused discussion. The vast bulk of our discussion
> (including quite long ones, and I think most folks who end up in a
> discussion with me know I can produce a fair amount of content in one) occur
> entirely within GitHub and it works just fine. I don’t think this is unique
> to pip either. Pretty much the only time we use anything but GitHub are when
> the blast radius for a change is larger then pip itself (e.g. something that
> touches pip, setuptools, and pypi) which we use distutils-sig for, or when
> something is just a notice that doesn’t require discussion, which we use
> pypa-dev for.
>
> I agree that there are benefits to separating code review and issue tracking
> (although I’m not a purist about it, I think some PRs are too small to
> warrant an issue for instance) and I think that without some effort to
> automate and write a bot GitHub issues are not a good fit for replacing bpo.
> However I think it’s going to be a regular struggle to get people to try and
> primarily use bpo for issue discussion (vs code review) because the friction
> of doing so is fairly high. I think if you want to encourage people to
> utilize bpo better, your best bet is to do everything you can to reduce that
> friction.

I have to agree here. I'm not sufficiently involved in bpo discussions
to have a strong opinion, but my experience with pip is the same as
Donald's - it's pretty easy to have complex design decisions on
github, as well as having review style comments. I'd have to say the
new "create a review" interface in github can make conversations
harder to follow, particularly if you're reading the emails rather
than reading on the github site itself, but I tend to work by reading
emails to spot the interesting topics, then go to GH for the full
story.

One other huge win for me with github over bpo is that the former
allows formatted text. I find having to read plaintext discussions on
bpo *much* more tiring than reading github formatted content.

But the big problem for me with github discussions in Python is the
sheer volume. My normal github workflow (which works fine for pip)
collapses under the volume of Python traffic. That's not to say that
bpo is any better - I basically ignore the majority of bpo traffic
that I['m not automatically nosied on, for exactly the same reason,
that my approach doesn't scale.

To summarise:

1. The traffic for CPython is the biggest issue - expecting people
with established workflows that cope with it to rework those workflows
to work with gh rather than bpo is a big ask.
2. Having formatted text for the discussions is (IMO) a huge win.
3. Apart from familiarity, I don't think there's much difference in
the ability to have design discussions (as long as you don't hide
design comments in the GH review notes, of course, but that's just a
matter of using the tool correctly).
4. Neither interface (in my experience) does a wonderful job of making
the discussion transparent via email. But I tend to see email as a
transient notification medium - we should probably concentrate more on
the UX when interacting with the website directly.

I can't really weight these factors, so I'll leave that to the people
who interact with the trackers more often than I do.

Paul