Github reviews are cannibalizing BPO
Hi all,
since our move to Github I noticed a major increase in incoming patches. I like it. It clearly shows that it was a good decision.
But I don't like the fact that Github reviews are cannibalizing issues on BPO. Before the migration decisions regarding a new feature or bug fix were made on the ticket system. For larger changes we used mailing lists or the PEP process. Rietveld, our previous code review tool, was just used to discuss code and implementation details. All important decisions still happened on BPO. We also used BPO to keep the experts or module maintainers in the loop.
With Github I'm seeing a major paradigm shift. New contributors tend to use BPO as ticket number dispenser. Actual discussion seems to happen mostly on Github PRs. For me it makes it harder to follow discussion or to see discussions at all. I find Github notifications inferior to compared BPO's email notification -- mostly because Github spams me with notifications. For me it's not uncommon to have more than 1,000 open notifications waiting for my attention.
This brings me to my questions
Should we try to move discussion back to BPO or are we fine with having major decisions just in Github PRs?
How can we retain enough information on BPO to keep it useful as research database for past decisions?
How can we keep module maintainers and experts in the loop? For example I don't have the resources to read all Github PRs, but I still like to keep an eye on the ssl and hashlib module.
Christian
On Mon, May 1, 2017 at 3:32 PM, Christian Heimes <christian@python.org> wrote:
- Should we try to move discussion back to BPO or are we fine with having major decisions just in Github PRs?
How will you do that? For Github, a PR and issue request ( an equivalent of BPO issue) is same. And we cannot disable review comments in Github PR and force people to discuss in BPO only.
-- Senthil
On May 1, 2017, at 6:32 PM, Christian Heimes <christian@python.org> wrote:
- How can we keep module maintainers and experts in the loop? For example I don't have the resources to read all Github PRs, but I still like to keep an eye on the ssl and hashlib module.
Add yourself to https://github.com/python/cpython/blob/master/.mention-bot <https://github.com/python/cpython/blob/master/.mention-bot> using:
"alwaysNotifyForPaths": [ {"name": "tiran", "files": ["Lib/ssl.py", "Lib/hashlib.py"]} ]
Include all the paths you want to _always_ be notified for globbing works as well.
Then anytime someone sends a PR that touches that, the mention bot with @tiran you (unless we turned it off….).
— Donald Stufft
On 05/01/2017 03:32 PM, Christian Heimes wrote:
With Github I'm seeing a major paradigm shift. New contributors tend to use BPO as ticket number dispenser. Actual discussion seems to happen mostly on Github PRs. For me it makes it harder to follow discussion [...]
I don't have any answers, but I will chime in with a "me, too" comment about the difficulty of following Github PRs with code and comments intertwined.
-- ~Ethan~
On 2 May 2017 at 08:32, Christian Heimes <christian@python.org> wrote:
This brings me to my questions
Should we try to move discussion back to BPO or are we fine with having major decisions just in Github PRs?
How can we retain enough information on BPO to keep it useful as research database for past decisions?
It's OK to have the discussions on GitHub, but one of the responsibilities of reviewers is to ensure that significant design decisions are summarised on the related tracker issue for future reference.
If GitHub looks like it is at risk of disappearing as a public historical archive at some point in the future (or if the problem bothers someone enough in the meantime for them to spend time on addressing it), then it should be possible to use https://www.githubarchive.org/ to maintain a full streaming mirror of a GitHub repository in a self-hosted GitLab instance.
- How can we keep module maintainers and experts in the loop? For example I don't have the resources to read all Github PRs, but I still like to keep an eye on the ssl and hashlib module.
As Donald describes, mention-bot should be able to handle this (and more reliably than the nosy list on BPO, since it's based on the actual files touched by a PR).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 02.05.2017 04:25, Nick Coghlan wrote:
On 2 May 2017 at 08:32, Christian Heimes <christian@python.org> wrote:
This brings me to my questions
Should we try to move discussion back to BPO or are we fine with having major decisions just in Github PRs?
How can we retain enough information on BPO to keep it useful as research database for past decisions?
It's OK to have the discussions on GitHub, but one of the responsibilities of reviewers is to ensure that significant design decisions are summarised on the related tracker issue for future reference.
I don't think that's a good idea, since the core devs then have to check what's good discussion to have on Github PRs and what not.
IMO, it's much easier for everyone to just always point people to BPO for discussions and keep PRs reserved for code reviews.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 02 2017)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal@egenix.com> wrote:
On 02.05.2017 04:25, Nick Coghlan wrote:
On 2 May 2017 at 08:32, Christian Heimes <christian@python.org> wrote:
This brings me to my questions
Should we try to move discussion back to BPO or are we fine with having major decisions just in Github PRs?
How can we retain enough information on BPO to keep it useful as research database for past decisions?
It's OK to have the discussions on GitHub, but one of the responsibilities of reviewers is to ensure that significant design decisions are summarised on the related tracker issue for future reference.
I don't think that's a good idea, since the core devs then have to check what's good discussion to have on Github PRs and what not.
IMO, it's much easier for everyone to just always point people to BPO for discussions and keep PRs reserved for code reviews.
I agree with Mark-Andre here. It will take effort on our part to make our culture be "discuss on BPO", but it will produce a much superior history to what github PRs produce, so I think it is worth it.
--David
On 5/2/17 10:07 AM, R. David Murray wrote:
On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal@egenix.com> wrote:
On 02.05.2017 04:25, Nick Coghlan wrote:
On 2 May 2017 at 08:32, Christian Heimes <christian@python.org> wrote:
This brings me to my questions
Should we try to move discussion back to BPO or are we fine with having major decisions just in Github PRs?
How can we retain enough information on BPO to keep it useful as research database for past decisions?
It's OK to have the discussions on GitHub, but one of the responsibilities of reviewers is to ensure that significant design decisions are summarised on the related tracker issue for future reference.
I don't think that's a good idea, since the core devs then have to check what's good discussion to have on Github PRs and what not.
IMO, it's much easier for everyone to just always point people to BPO for discussions and keep PRs reserved for code reviews.
I agree with Mark-Andre here. It will take effort on our part to make our culture be "discuss on BPO", but it will produce a much superior history to what github PRs produce, so I think it is worth it.
I agree with David and MAL. github PR's should replace Rietveld for code reviews, and should not replace BPO for discussions.
Eric.
I'm not necessarily disagreeing, I'm just skeptical that we can stop this tide. New contributors are familiar with GitHub and GitHub only, and for them, BPO looks and feels like a legacy system. And honestly, for smaller projects, I've found GitHub a very effective place to have discussions (e.g. most mypy design work is done there). Though I agree that GitHub currently doesn't scale to the size of CPython unless you work hard on setting up filtering (which *is* possible, just done very differently).
On Tue, May 2, 2017 at 10:24 AM, Eric V. Smith <eric@trueblade.com> wrote:
On 5/2/17 10:07 AM, R. David Murray wrote:
On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal@egenix.com> wrote:
On 02.05.2017 04:25, Nick Coghlan wrote:
On 2 May 2017 at 08:32, Christian Heimes <christian@python.org> wrote:
This brings me to my questions
Should we try to move discussion back to BPO or are we fine with having major decisions just in Github PRs?
How can we retain enough information on BPO to keep it useful as research database for past decisions?
It's OK to have the discussions on GitHub, but one of the responsibilities of reviewers is to ensure that significant design decisions are summarised on the related tracker issue for future reference.
I don't think that's a good idea, since the core devs then have to check what's good discussion to have on Github PRs and what not.
IMO, it's much easier for everyone to just always point people to BPO for discussions and keep PRs reserved for code reviews.
I agree with Mark-Andre here. It will take effort on our part to make our culture be "discuss on BPO", but it will produce a much superior history to what github PRs produce, so I think it is worth it.
I agree with David and MAL. github PR's should replace Rietveld for code reviews, and should not replace BPO for discussions.
Eric.
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
On 5/2/17 2:13 PM, Guido van Rossum wrote:
I'm not necessarily disagreeing, I'm just skeptical that we can stop this tide. New contributors are familiar with GitHub and GitHub only, and for them, BPO looks and feels like a legacy system. And honestly, for smaller projects, I've found GitHub a very effective place to have discussions (e.g. most mypy design work is done there). Though I agree that GitHub currently doesn't scale to the size of CPython unless you work hard on setting up filtering (which *is* possible, just done very differently).
I grant that it's an uphill battle. But even github has a separate issue tracker, we're just not using it. So even github black belts should be familiar with the concept of an issue tracker being used for a different purpose than code reviews are.
Eric.
On May 2, 2017, at 2:37 PM, Eric V. Smith <eric@trueblade.com> wrote:
On 5/2/17 2:13 PM, Guido van Rossum wrote:
I'm not necessarily disagreeing, I'm just skeptical that we can stop this tide. New contributors are familiar with GitHub and GitHub only, and for them, BPO looks and feels like a legacy system. And honestly, for smaller projects, I've found GitHub a very effective place to have discussions (e.g. most mypy design work is done there). Though I agree that GitHub currently doesn't scale to the size of CPython unless you work hard on setting up filtering (which *is* possible, just done very differently).
I grant that it's an uphill battle. But even github has a separate issue tracker, we're just not using it. So even github black belts should be familiar with the concept of an issue tracker being used for a different purpose than code reviews are.
I suspect part of it may simply be that mucking around with b.p.o is far less streamlined then GitHub issues or PRs. One thing we might want to look at is making it possible to login with GitHub to b.p.o, as that is one possible hurdle for someone to cross when looking at making a comment on a PR/issue.
The flip side of that is even prior to using GitHub it wasn’t like all of the discussion was happening on b.p.o either, some of it happened in Reitveld (though less of it than is happening on GitHub because using Reitveld is/was more frustrating than a GitHub comment) and a lot of it happened in random back channels between individuals.
Ultimately, it’s likely to be a Sisyphean battle to stop it from happening unless b.p.o gets updated to have a UX on par with GitHub and the integration between the two of them makes it as low friction as possible.
— Donald Stufft
On 02.05.2017 20:44, Donald Stufft wrote:
I suspect part of it may simply be that mucking around with b.p.o is far less streamlined then GitHub issues or PRs. One thing we might want to look at is making it possible to login with GitHub to b.p.o, as that is one possible hurdle for someone to cross when looking at making a comment on a PR/issue.
The flip side of that is even prior to using GitHub it wasn’t like all of the discussion was happening on b.p.o either, some of it happened in Reitveld (though less of it than is happening on GitHub because using Reitveld is/was more frustrating than a GitHub comment) and a lot of it happened in random back channels between individuals.
I don't think that's a good characterization of what we used to have. We had discussions on bpo and when we felt that things were of a more general nature, we actively moved those discussions to the MLs.
This resulted in a healthy approach to OSS software development, since we had many different people take part in those discussions.
We're losing this if we move away from bpo and towards having PR discussions. Github's notification system is simply not geared up for the high volume Python generates.
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.
Personally, I prefer the latter, since chats are great for getting quick feedback or notifications, but much less so for discussions that go into more detail.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 02 2017)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On May 2, 2017, at 3:09 PM, M.-A. Lemburg <mal@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.
— Donald Stufft
On May 2, 2017, at 3:42 PM, Donald Stufft <donald@stufft.io> wrote:
On May 2, 2017, at 3:09 PM, M.-A. Lemburg <mal@egenix.com <mailto:mal@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.
To touch on this a bit more, arguably GitHub is *more* suited to long form discussion, given that it includes the ability to format your text which is an incredibly important part of producing readable content more then a few sentences long. You can attempt to apply some of this with bpo using ASCII representations, but an inlined URL or a footnote to the URL is never going to be as good as a hyperlink, or an inlined image, or bold, italics, etc.
— Donald Stufft
On May 02, 2017, at 03:54 PM, Donald Stufft wrote:
To touch on this a bit more, arguably GitHub is *more* suited to long form discussion, given that it includes the ability to format your text which is an incredibly important part of producing readable content more then a few sentences long. You can attempt to apply some of this with bpo using ASCII representations, but an inlined URL or a footnote to the URL is never going to be as good as a hyperlink, or an inlined image, or bold, italics, etc.
This might be true w.r.t. GH vs. bpo, but both of them are inferior IMHO to mailing lists or other types of threaded discussions. Personally, I find GitLab to have a better conversational UX than GitHub, but neither is threaded so it forces the discussions to be linear. That's okay for many discussions, but far inferior to more wide ranging discussions.
-Barry
On 2 May 2017 at 20:42, Donald Stufft <donald@stufft.io> wrote:
On May 2, 2017, at 3:09 PM, M.-A. Lemburg <mal@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:
- 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.
- Having formatted text for the discussions is (IMO) a huge win.
- 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).
- 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
On 3 May 2017 at 05:09, M.-A. Lemburg <mal@egenix.com> wrote:
This doesn't have much to do with UX/UI. It's mainly a questions of culture.
It's about the UI/UX for me, as Roundup is missing a few modern collaboration features:
- Easy user mentions: I can't just mention someone inline based on autocompletion, I have to go up and add them to the nosy list
- Easy issue mentions: I don't get autocompletion pop-ups for issue cross-references to help fill in the right ones
- Easy editing: if I post incorrect information, or the goal of an issue changes, that gets buried in a subsequent correction post
- Easy formatting: RoundUp is plaintext only, with no ReST or Markdown support
- Easy reactions: no native +1 support to avoid "Usenet nod syndrome" without spamming folks following the issue
None of them are particularly significant in isolation, but collectively they and similar reductions in UX friction add up to a significantly more fluid collaboration experience in the modern, commercially supported, tools.
That said, those are also all straightforward enough to add that I think the right question to ask is "How can we get them added to either upstream Roundup, or at least our instance of it?", but claiming that these kinds of UI/UX limitations don't matter or don't currently exist won't help anyone.
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 simply isn't an accurate characterisation of the way people use GitHub - I participate in several GitHub and GitLab hosted projects, and the issues and the PR level comments get used exactly the same way that we use bugs.python.org.
The rationale for retaining the latter relates to maintaining URL stability, avoiding breaking our own and third party integrations, preserving current email-based individual workflows, and maintaining a PSF controlled archive of significant design decisions, rather than any particular flaws in alternative issue trackers.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Le 03/05/2017 à 10:06, Nick Coghlan a écrit :
On 3 May 2017 at 05:09, M.-A. Lemburg <mal@egenix.com> wrote:
This doesn't have much to do with UX/UI. It's mainly a questions of culture.
It's about the UI/UX for me, as Roundup is missing a few modern collaboration features:
- Easy user mentions: I can't just mention someone inline based on autocompletion, I have to go up and add them to the nosy list
- Easy issue mentions: I don't get autocompletion pop-ups for issue cross-references to help fill in the right ones
- Easy editing: if I post incorrect information, or the goal of an issue changes, that gets buried in a subsequent correction post
- Easy formatting: RoundUp is plaintext only, with no ReST or Markdown support
- Easy reactions: no native +1 support to avoid "Usenet nod syndrome" without spamming folks following the issue
One growing gripe I have with Github is that their UI has become quite slow to load and render in recent years. It's become a bit grinding to navigate through issues or load long-winded discussions. bpo by contrast is quite snappy (probably by virtue of having a more rudimentary UI, of course).
As for "native" +1 mentions in Github, I tend to find them unhelpful, as I don't know why people say "+1" at all. So I usually ignore them.
Regards
Antoine.
On 3 May 2017 at 09:18, Antoine Pitrou <antoine@python.org> wrote:
As for "native" +1 mentions in Github, I tend to find them unhelpful, as I don't know why people say "+1" at all. So I usually ignore them.
The point is that it's easier to ignore +1s in github, because they don't trigger notification emails, and they don't add an extra conversation element :-) On bpo, +1's are indistinguishable (except for content) from substantive comments.
Paul
I've had another look at some of the PRs we do have on Github and must say, that it seems we're discussing a problem which doesn't really exist predominantly on our PR tracker:
https://github.com/python/cpython/pulls?page=2&q=is%3Apr+is%3Aopen
I haven't checked all PRs, but the ones which have a few more comments do mostly deal with code reviews.
On 03.05.2017 10:06, Nick Coghlan wrote:
On 3 May 2017 at 05:09, M.-A. Lemburg <mal@egenix.com> wrote:
This doesn't have much to do with UX/UI. It's mainly a questions of culture.
It's about the UI/UX for me, as Roundup is missing a few modern collaboration features:
- Easy user mentions: I can't just mention someone inline based on autocompletion, I have to go up and add them to the nosy list
- Easy issue mentions: I don't get autocompletion pop-ups for issue cross-references to help fill in the right ones
- Easy editing: if I post incorrect information, or the goal of an issue changes, that gets buried in a subsequent correction post
- Easy formatting: RoundUp is plaintext only, with no ReST or Markdown support
- Easy reactions: no native +1 support to avoid "Usenet nod syndrome" without spamming folks following the issue
None of them are particularly significant in isolation, but collectively they and similar reductions in UX friction add up to a significantly more fluid collaboration experience in the modern, commercially supported, tools.
That said, those are also all straightforward enough to add that I think the right question to ask is "How can we get them added to either upstream Roundup, or at least our instance of it?", but claiming that these kinds of UI/UX limitations don't matter or don't currently exist won't help anyone.
For the quality of discussions, I don't think the UI/UX matters much. Having a better UI will help simplify discussions, but not necessarily result in better content :-)
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 simply isn't an accurate characterisation of the way people use GitHub - I participate in several GitHub and GitLab hosted projects, and the issues and the PR level comments get used exactly the same way that we use bugs.python.org.
Well, it's my personal experience with Github. The UI often attracts a lot of noise, causing the experience to not always be great. They have added the +1 feature to at least reduce the number of me-too comments.
And BTW: you do have the same problem we're discussing here on Github as well: design discussions happening on the PRs instead of on the issue tracker :-) Github supports this even more, since the distinction between a PR thread and an issue discussion is not all that clear - both are "issues" in the context of Github and can be referenced using the same #ticket logic.
The rationale for retaining the latter relates to maintaining URL stability, avoiding breaking our own and third party integrations, preserving current email-based individual workflows, and maintaining a PSF controlled archive of significant design decisions, rather than any particular flaws in alternative issue trackers.
I don't think we should open a discussion of whether to move away from bpo or not.
The thread topic only refers to how we deal with discussions which should be had on bpo rather than Github PRs and I think we mostly agree that having them on bpo is better, regardless of how we view Github discussions in general.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 03 2017)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On 3 May 2017 at 10:30, M.-A. Lemburg <mal@egenix.com> wrote:
I don't think we should open a discussion of whether to move away from bpo or not.
Agreed...
The thread topic only refers to how we deal with discussions which should be had on bpo rather than Github PRs and I think we mostly agree that having them on bpo is better, regardless of how we view Github discussions in general.
I don't agree, but as you said above, that's not the topic of this thread.
Paul
On Wed, May 03, 2017 at 06:06:59PM +1000, Nick Coghlan wrote:
- Easy reactions: no native +1 support to avoid "Usenet nod syndrome" without spamming folks following the issue
All platforms (except maybe Stackoverflow) who have voting use +1 more in a "high five" sense than for actual agreement.
A lot of folks don't use these buttons out of principle so one will never get an accurate "popular opinion".
Other people don't post at all because they don't like downvoting (there goes the often cited inclusiveness).
Would you have liked those buttons in a memorable mailing list thread about a trivial unittest change a couple of years ago? I wouldn't.
Voting should be reserved for concrete finished proposals.
Stefan Krah
On 5/2/2017 10:07 AM, R. David Murray wrote:
On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal@egenix.com> wrote:
IMO, it's much easier for everyone to just always point people to BPO for discussions and keep PRs reserved for code reviews.
I agree with Mark-Andre here. It will take effort on our part to make our culture be "discuss on BPO", but it will produce a much superior history to what github PRs produce, so I think it is worth it.
It would easier to move discussion to bpo if there were a clickable link from PR to bpo, just as there is in the opposite direction. I believe that there is a workflow issue to add this, but last I knew, it was bogged down in where to put the link, or something.
tjr
On 2017-05-02 20:28, Terry Reedy wrote:
On 5/2/2017 10:07 AM, R. David Murray wrote:
On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal@egenix.com> wrote:
IMO, it's much easier for everyone to just always point people to BPO for discussions and keep PRs reserved for code reviews.
I agree with Mark-Andre here. It will take effort on our part to make our culture be "discuss on BPO", but it will produce a much superior history to what github PRs produce, so I think it is worth it.
It would easier to move discussion to bpo if there were a clickable link from PR to bpo, just as there is in the opposite direction. I believe that there is a workflow issue to add this, but last I knew, it was bogged down in where to put the link, or something.
All recent PRs have a clickable link to BPO. It's in the box with CI results. Click on "Details" for "bedevere/issue-number".
Christian
On 5/2/2017 2:36 PM, Christian Heimes wrote:
On 2017-05-02 20:28, Terry Reedy wrote:
On 5/2/2017 10:07 AM, R. David Murray wrote:
On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal@egenix.com> wrote:
IMO, it's much easier for everyone to just always point people to BPO for discussions and keep PRs reserved for code reviews.
I agree with Mark-Andre here. It will take effort on our part to make our culture be "discuss on BPO", but it will produce a much superior history to what github PRs produce, so I think it is worth it.
It would easier to move discussion to bpo if there were a clickable link from PR to bpo, just as there is in the opposite direction. I believe that there is a workflow issue to add this, but last I knew, it was bogged down in where to put the link, or something.
All recent PRs have a clickable link to BPO. It's in the box with CI results.
Not until one clicks 'Show all checks'. This is rather obscure. Who would know? Thanks for the info.
Click on "Details" for "bedevere/issue-number".
Neither was it obvious to me that 'details' takes me to the issue, rather than revealing a clickable issue-number, so that I need to middle click to open a new tab.
So this is still considerable friction.
tjr
On Tue, 2 May 2017 at 11:29 Terry Reedy <tjreedy@udel.edu> wrote:
On 5/2/2017 10:07 AM, R. David Murray wrote:
On Tue, 02 May 2017 09:36:02 +0200, "M.-A. Lemburg" <mal@egenix.com> wrote:
IMO, it's much easier for everyone to just always point people to BPO for discussions and keep PRs reserved for code reviews.
I agree with Mark-Andre here. It will take effort on our part to make our culture be "discuss on BPO", but it will produce a much superior history to what github PRs produce, so I think it is worth it.
It would easier to move discussion to bpo if there were a clickable link from PR to bpo, just as there is in the opposite direction. I believe that there is a workflow issue to add this, but last I knew, it was bogged down in where to put the link, or something.
The idea is being tracked at https://github.com/python/bedevere/issues/3 and it isn't bogged down so much as the people typically writing these bots/integrations having the time to implement the idea. I should also mention I'm hoping to have the link be accompanied with a short blurb reminding people to keep discussions on GH to just code reviewing and everything else going to bpo.
On 5/3/2017 1:25 PM, Brett Cannon wrote:
On Tue, 2 May 2017 at 11:29 Terry Reedy <tjreedy@udel.edu <mailto:tjreedy@udel.edu>> wrote:
It would easier to move discussion to bpo if there were a clickable link from PR to bpo, just as there is in the opposite direction. I believe that there is a workflow issue to add this, but last I knew, it was bogged down in where to put the link, or something.The idea is being tracked at https://github.com/python/bedevere/issues/3 and it isn't bogged down so much as the people typically writing these bots/integrations having the time to implement the idea. I should also mention I'm hoping to have the link be accompanied with a short blurb reminding people to keep discussions on GH to just code reviewing and everything else going to bpo.
I saw that and like the idea.
Moving on ... The next issue I have run into is that people can submit, review, or otherwise comment on the PR without being nosy on the issue. They will thus miss any further bpo discussion. One could not submit or comment on a bpo patch without becoming nosy on the issue (and the same might have been true for Rietveld reviews). Is there any possibility of making people nosy on bpo automatically if nosy on a PR?
On Wed, 3 May 2017 at 13:42 Terry Reedy <tjreedy@udel.edu> wrote:
On 5/3/2017 1:25 PM, Brett Cannon wrote:
On Tue, 2 May 2017 at 11:29 Terry Reedy <tjreedy@udel.edu <mailto:tjreedy@udel.edu>> wrote:
It would easier to move discussion to bpo if there were a clickablelink
from PR to bpo, just as there is in the opposite direction. Ibelieve
that there is a workflow issue to add this, but last I knew, it was bogged down in where to put the link, or something.The idea is being tracked at https://github.com/python/bedevere/issues/3 and it isn't bogged down so much as the people typically writing these bots/integrations having the time to implement the idea. I should also mention I'm hoping to have the link be accompanied with a short blurb reminding people to keep discussions on GH to just code reviewing and everything else going to
bpo.
I saw that and like the idea.
Moving on ... The next issue I have run into is that people can submit, review, or otherwise comment on the PR without being nosy on the issue. They will thus miss any further bpo discussion. One could not submit or comment on a bpo patch without becoming nosy on the issue (and the same might have been true for Rietveld reviews). Is there any possibility of making people nosy on bpo automatically if nosy on a PR?
Possible, yes. Trick with this is getting the change made. People need to realize that basically Maciej and Ezio have done all of the bugs.python.org code changes as of late (although a lot of the initial work was done by Anish Shah as a GSoC project). So you basically need to either convince one of those two to make this work or it's time to start learning the Roundup code base :)
(And just so I can claim I stated this publicly at some point; our Roundup installation I think runs on Python 2.6 and Roundup itself has not been ported to Python 3, so I don't know what we want to do if Roundup doesn't make the switch by 2020.)
On Thu, May 04, 2017 at 05:44:46PM +0000, Brett Cannon wrote:
(And just so I can claim I stated this publicly at some point; our Roundup installation I think runs on Python 2.6 and Roundup itself has not been ported to Python 3, so I don't know what we want to do if Roundup doesn't make the switch by 2020.)
Perhaps that's a good use-case for the PSF to (partially?) fund the porting effort.
On the other hand... I can imagine some developers thinking "I just spent all this time porting my library to Python 3 for free, if I had known I would have waited".
-- Steve
On May 05, 2017, at 10:58 AM, Steven D'Aprano wrote:
On the other hand... I can imagine some developers thinking "I just spent all this time porting my library to Python 3 for free, if I had known I would have waited".
Except, think of the costs in mental anguish staying on Python 2. :)
-Barry
On 5 May 2017 at 10:58, Steven D'Aprano <steve@pearwood.info> wrote:
On Thu, May 04, 2017 at 05:44:46PM +0000, Brett Cannon wrote:
(And just so I can claim I stated this publicly at some point; our Roundup installation I think runs on Python 2.6 and Roundup itself has not been ported to Python 3, so I don't know what we want to do if Roundup doesn't make the switch by 2020.)
Perhaps that's a good use-case for the PSF to (partially?) fund the porting effort.
On the other hand... I can imagine some developers thinking "I just spent all this time porting my library to Python 3 for free, if I had known I would have waited".
Funded Python 3 ports aren't a new idea, as the PSF has been offering & facilitating Python 3 porting grants since 2011: http://pyfound.blogspot.com.au/2011/12/psf-proffers-payment-to-port-to-pytho...
I know at least one former upstream Roundup developer recently moved into freelance software development & consulting, so I'll chat to him to see if he has any suggestions for possible ways forward here.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Thu, 04 May 2017 17:44:46 -0000, Brett Cannon <brett@python.org> wrote:
(And just so I can claim I stated this publicly at some point; our Roundup installation I think runs on Python 2.6 and Roundup itself has not been ported to Python 3, so I don't know what we want to do if Roundup doesn't make the switch by 2020.)
There is intent to port, and some movement, but the number of people actively working on Roundup is small. As in single digits small. Of one hand.
--David
PS: our roundup runs on 2.6 because that's what the host OS version provides. Roundup is planning to drop 2.6 support in the next release, so we're going to have to deal with *that* *before* 2020 :)
On 02.05.2017 00:32, Christian Heimes wrote:
This brings me to my questions
- Should we try to move discussion back to BPO or are we fine with having major decisions just in Github PRs?
We've had that discussion before: discussions always should happen on BPO, not Github PRs. PRs are just for code review, nothing more.
AFAIK, there's no good way to enforce this except core devs pointing people to BPO instead of commenting on PRs.
- How can we retain enough information on BPO to keep it useful as research database for past decisions?
See above.
- How can we keep module maintainers and experts in the loop? For example I don't have the resources to read all Github PRs, but I still like to keep an eye on the ssl and hashlib module.
See above :-)
I have muted all Github notifications since it became impossible to follow them.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, May 02 2017)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
I just touched up https://github.com/python/cpython/blob/master/.github/CONTRIBUTING.rst to explicitly mention that only code review issues should be discussed on GitHub.
On Mon, 1 May 2017 at 15:32 Christian Heimes <christian@python.org> wrote:
Hi all,
since our move to Github I noticed a major increase in incoming patches. I like it. It clearly shows that it was a good decision.
But I don't like the fact that Github reviews are cannibalizing issues on BPO. Before the migration decisions regarding a new feature or bug fix were made on the ticket system. For larger changes we used mailing lists or the PEP process. Rietveld, our previous code review tool, was just used to discuss code and implementation details. All important decisions still happened on BPO. We also used BPO to keep the experts or module maintainers in the loop.
With Github I'm seeing a major paradigm shift. New contributors tend to use BPO as ticket number dispenser. Actual discussion seems to happen mostly on Github PRs. For me it makes it harder to follow discussion or to see discussions at all. I find Github notifications inferior to compared BPO's email notification -- mostly because Github spams me with notifications. For me it's not uncommon to have more than 1,000 open notifications waiting for my attention.
This brings me to my questions
Should we try to move discussion back to BPO or are we fine with having major decisions just in Github PRs?
How can we retain enough information on BPO to keep it useful as research database for past decisions?
How can we keep module maintainers and experts in the loop? For example I don't have the resources to read all Github PRs, but I still like to keep an eye on the ssl and hashlib module.
Christian
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On 2017-05-03 19:54, Brett Cannon wrote:
I just touched up https://github.com/python/cpython/blob/master/.github/CONTRIBUTING.rst to explicitly mention that only code review issues should be discussed on GitHub.
Thanks Brett!
I followed Donalds' advice and just pushed a modification to .mention-bot https://github.com/python/cpython/commit/feec3dc9c308052754f9e4848c1c1ddb007... . Let's wait and see if it actually works. :)
Christian
participants (16)
-
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Christian Heimes -
Donald Stufft -
Eric V. Smith -
Ethan Furman -
Guido van Rossum -
M.-A. Lemburg -
Nick Coghlan -
Paul Moore -
R. David Murray -
Senthil Kumaran -
Stefan Krah -
Steven D'Aprano -
Terry Reedy