Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues
Another essential bit of tooling for the migration:
- Before filing a bug report or feature request, we ask people to search to see if there is already an issue in progress or a resolved issue on the topic. We need to make sure that on GitHub issues, people can still search our voluminous history of already evaluated and decided feature requests.
Raymond
On Tue, Sep 10, 2019, at 06:54, Raymond Hettinger wrote:
Another essential bit of tooling for the migration:
- Before filing a bug report or feature request, we ask people to
search to see if there is already an issue in progress or a resolved issue on the topic. We need to make sure that on GitHub issues, people can still search our voluminous history of already evaluated and decided feature requests.
I think is something that GitHub already does well compared to Roundup. GitHub can suggest related issues as you type into the "new issue" box. https://github.blog/changelog/2018-11-05-related-issues/
On Tue, Sep 10, 2019 at 09:49:00AM +0100, Benjamin Peterson wrote:
On Tue, Sep 10, 2019, at 06:54, Raymond Hettinger wrote:
Another essential bit of tooling for the migration:
- Before filing a bug report or feature request, we ask people to
search to see if there is already an issue in progress or a resolved issue on the topic. We need to make sure that on GitHub issues, people can still search our voluminous history of already evaluated and decided feature requests.
I think is something that GitHub already does well compared to Roundup. GitHub can suggest related issues as you type into the "new issue" box. https://github.blog/changelog/2018-11-05-related-issues/
That's still in beta, and you have to opt-in to use it.
I just tried it, it doesn't work for me. Even if I type the exact same issue title as one already existing, it makes no suggestions. (This doesn't surprise me, hardly anything on github works for me, nor will they until I can afford a new computer.)
In any case, it doesn't answer Raymond's request. Even if the Related Issues feature works for you, it doesn't help you track down an existing issue if you're not trying to create a new issue. E.g. you might be searching for an issue you remember seeing but don't know the URL to, or you might be researching something for a PEP and want to find relevant issues. Or you might just be dissatisfied with Github's suggestion algorithm, and want to try with different keywords.
Having said that, the "Filters" feature does seem to do the trick. I just tried it on a project I picked at random:
https://github.com/sorccu/cufon/issues?q=is%3Aissue+is%3Aopen
and it seems quite good. It is quite prominent, and on a couple of quick tests it seems to do the job well. Although using search options ("is:open") in the search box rather than GUI controls will, I think, increase the barrier to entry for beginners.
Can Github search the past history on b.p.o as well?
On Wed, Sep 11, 2019, at 00:32, Steven D'Aprano wrote:
On Tue, Sep 10, 2019 at 09:49:00AM +0100, Benjamin Peterson wrote:
On Tue, Sep 10, 2019, at 06:54, Raymond Hettinger wrote:
Another essential bit of tooling for the migration:
- Before filing a bug report or feature request, we ask people to
search to see if there is already an issue in progress or a resolved issue on the topic. We need to make sure that on GitHub issues, people can still search our voluminous history of already evaluated and decided feature requests.
I think is something that GitHub already does well compared to Roundup. GitHub can suggest related issues as you type into the "new issue" box. https://github.blog/changelog/2018-11-05-related-issues/
That's still in beta, and you have to opt-in to use it.
I just tried it, it doesn't work for me. Even if I type the exact same issue title as one already existing, it makes no suggestions. (This doesn't surprise me, hardly anything on github works for me, nor will they until I can afford a new computer.)
In any case, it doesn't answer Raymond's request. Even if the Related Issues feature works for you, it doesn't help you track down an existing issue if you're not trying to create a new issue. E.g. you might be searching for an issue you remember seeing but don't know the URL to, or you might be researching something for a PEP and want to find relevant issues. Or you might just be dissatisfied with Github's suggestion algorithm, and want to try with different keywords.
Having said that, the "Filters" feature does seem to do the trick. I just tried it on a project I picked at random:
https://github.com/sorccu/cufon/issues?q=is%3Aissue+is%3Aopen
and it seems quite good. It is quite prominent, and on a couple of quick tests it seems to do the job well. Although using search options ("is:open") in the search box rather than GUI controls will, I think, increase the barrier to entry for beginners.
In other words, vanilla GitHub issue search does address Raymond's request?
Can Github search the past history on b.p.o as well?
That seems unlikely to happen.
On Wed, Sep 11, 2019 at 10:17:48AM +0100, Benjamin Peterson wrote:
[Steven]
Having said that, the "Filters" feature does seem to do the trick. I just tried it on a project I picked at random:
https://github.com/sorccu/cufon/issues?q=is%3Aissue+is%3Aopen
and it seems quite good. It is quite prominent, and on a couple of quick tests it seems to do the job well. Although using search options ("is:open") in the search box rather than GUI controls will, I think, increase the barrier to entry for beginners.
[Benjamin]
In other words, vanilla GitHub issue search does address Raymond's request?
Given that github search is unlikely to be able to search "our voluminous history of already evaluated and decided feature requests" on b.p.o then it probably doesn't.
Besides, I spent about two minutes playing with github's filter/search, not long enough to really test its capabilities and limitations.
On 11Sep2019 1117, Steven D'Aprano wrote:
On Wed, Sep 11, 2019 at 10:17:48AM +0100, Benjamin Peterson wrote:
In other words, vanilla GitHub issue search does address Raymond's request?
Given that github search is unlikely to be able to search "our voluminous history of already evaluated and decided feature requests" on b.p.o then it probably doesn't.
Besides, I spent about two minutes playing with github's filter/search, not long enough to really test its capabilities and limitations.
I've spent a couple of years playing with GitHub's filter/search on much smaller projects than CPython and I find its search woefully inadequate compared to bpo.
But I know some people find it easier, so I'll probably rely on them to do the history searches for me after we switch.
Cheers, Steve
Sorry, but please leave comments in the GitHub issue, one feature request per comment. This will allow people to give +1 reaction to your request
https://github.com/python/core-workflow/issues/359
On Thu, Sep 12, 2019, 2:30 AM Steve Dower steve.dower@python.org wrote:
On 11Sep2019 1117, Steven D'Aprano wrote:
On Wed, Sep 11, 2019 at 10:17:48AM +0100, Benjamin Peterson wrote:
In other words, vanilla GitHub issue search does address Raymond's
request?
Given that github search is unlikely to be able to search "our voluminous history of already evaluated and decided feature requests" on b.p.o then it probably doesn't.
Besides, I spent about two minutes playing with github's filter/search, not long enough to really test its capabilities and limitations.
I've spent a couple of years playing with GitHub's filter/search on much smaller projects than CPython and I find its search woefully inadequate compared to bpo.
But I know some people find it easier, so I'll probably rely on them to do the history searches for me after we switch.
Cheers, Steve _______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/Z... Code of Conduct: https://www.python.org/psf/codeofconduct/
Are you saying that this whole thread of issues will be ignored unless we all go to another forum, post a dozen separate issues, and recreate all of the discussion that already these threads?
That doesn't seem reasonable to me for several reasons: 1) it is unlikely that the full thread content would survive the forum transfer, so that some important aspects of the conversation will be lost, 2) some of us have very few clocks cycles available to allocate because discussion threads and actual core development, 3) this is outside our historical norm -- we normally do PEP level discussions on the lists rather than in many separate issues, 4) the separate issue approach (particularly if it is in core-workflow) won't have much visibility or participation for the folks who currently do most of the work on the tracker, and 5) having separate issues tends to obscure the big picture of how much functionality will be lost as a result of the migration and how much disruption will be caused by breaking existing user conversations and losing searchable history.
I have to say that I agree with Raymond here. I don't think that an issue tracker is a good way to collect this sort of feedback. To be honest, I don't feel that there's going to be much scope to address the sorts of concerns being raised here, so I'm not clear how much value there will be in the discussion, ultimately, but I do think that having a single conversation/thread/topic that covers the "big picture" is important, as for some people the problem is going to be an accumulation of small problems, rather than any one big showstopper. And tracker items have, in my experience, a tendency to dilute the impact of that sort of accumulation.
It seems like the idea here is that we handle the discussion on how to use the github tracker for Python issues, by using a github tracker for the plan. Does that not result in a problem, because people uncomfortable with the github tracker will be uncomfortable with the means they are required to use to express that discomfort, and so their voice won't get heard? Personally, I have a workflow that works (just about) for me, for handling any given github issue tracker (filtering email notifications to a dedicated folder for the tracker) but that method does not scale very well, and it *definitely* doesn't work for following trackers on an adhoc basis. So I'm not going to easily be able to follow discussion on the tracker-for-discussing-issues-with-the-proposed-cpython-issue-tracker (ERROR: Recursion depth exceeded ;-)) So I guess I give up and leave the decision to others. In my case, not that big of a deal, as I don't use the current tracker that heavily - but if someone like Raymond takes that view, that's (IMO) quite a lot more serious.
Paul
On Sun, 13 Oct 2019 at 06:20, raymond.hettinger@gmail.com wrote:
Are you saying that this whole thread of issues will be ignored unless we all go to another forum, post a dozen separate issues, and recreate all of the discussion that already these threads?
That doesn't seem reasonable to me for several reasons: 1) it is unlikely that the full thread content would survive the forum transfer, so that some important aspects of the conversation will be lost, 2) some of us have very few clocks cycles available to allocate because discussion threads and actual core development, 3) this is outside our historical norm -- we normally do PEP level discussions on the lists rather than in many separate issues, 4) the separate issue approach (particularly if it is in core-workflow) won't have much visibility or participation for the folks who currently do most of the work on the tracker, and 5) having separate issues tends to obscure the big picture of how much functionality will be lost as a result of the migration and how much disruption will be caused by breaking existing user conversations and losing searchable history. _______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/2... Code of Conduct: https://www.python.org/psf/codeofconduct/
TBH, for me it's quite the opposite. There are too many mailing list threads and it's often hard to catch up on them because there's a lot of pointless back and forth and quite frequently the discussion diverges to topics that are not of interest. I am used to having many important design discussions in GitHub issues and frankly it works well.
I'm not saying that it will or should feel the same for everyone. But I do want to emphasize that not everyone experiences the same dread when requested to use a GitHub issue that you and Raymond seem to feel.
--Guido
On Sun, Oct 13, 2019 at 4:04 AM Paul Moore p.f.moore@gmail.com wrote:
I have to say that I agree with Raymond here. I don't think that an issue tracker is a good way to collect this sort of feedback. To be honest, I don't feel that there's going to be much scope to address the sorts of concerns being raised here, so I'm not clear how much value there will be in the discussion, ultimately, but I do think that having a single conversation/thread/topic that covers the "big picture" is important, as for some people the problem is going to be an accumulation of small problems, rather than any one big showstopper. And tracker items have, in my experience, a tendency to dilute the impact of that sort of accumulation.
It seems like the idea here is that we handle the discussion on how to use the github tracker for Python issues, by using a github tracker for the plan. Does that not result in a problem, because people uncomfortable with the github tracker will be uncomfortable with the means they are required to use to express that discomfort, and so their voice won't get heard? Personally, I have a workflow that works (just about) for me, for handling any given github issue tracker (filtering email notifications to a dedicated folder for the tracker) but that method does not scale very well, and it *definitely* doesn't work for following trackers on an adhoc basis. So I'm not going to easily be able to follow discussion on the tracker-for-discussing-issues-with-the-proposed-cpython-issue-tracker (ERROR: Recursion depth exceeded ;-)) So I guess I give up and leave the decision to others. In my case, not that big of a deal, as I don't use the current tracker that heavily - but if someone like Raymond takes that view, that's (IMO) quite a lot more serious.
Paul
On Sun, 13 Oct 2019 at 06:20, raymond.hettinger@gmail.com wrote:
Are you saying that this whole thread of issues will be ignored unless
we all go to another forum, post a dozen separate issues, and recreate all of the discussion that already these threads?
That doesn't seem reasonable to me for several reasons: 1) it is
unlikely that the full thread content would survive the forum transfer, so that some important aspects of the conversation will be lost, 2) some of us have very few clocks cycles available to allocate because discussion threads and actual core development, 3) this is outside our historical norm -- we normally do PEP level discussions on the lists rather than in many separate issues, 4) the separate issue approach (particularly if it is in core-workflow) won't have much visibility or participation for the folks who currently do most of the work on the tracker, and 5) having separate issues tends to obscure the big picture of how much functionality will be lost as a result of the migration and how much disruption will be caused by breaking existing user conversations and losing searchable history.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/2...
Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/C... Code of Conduct: https://www.python.org/psf/codeofconduct/
Hi Guido,
But I do want to emphasize that not everyone experiences the same dread
when requested to use a GitHub issue that you and Raymond seem to feel.
If I understand this correctly, it was not about the dread, but the overall context already preserved in this discussion. The feedback provided by Raymond were multiple discussion points for us to accept or counter in this proposal. These might lose context if taken individually as separate issues. This was the first and an important objection. I am pretty sure, some of the actionable items will be translated to Github issues and no one will mind it.
Thanks, Senthil
On Sun, Oct 13, 2019 at 10:11 AM Guido van Rossum guido@python.org wrote:
TBH, for me it's quite the opposite. There are too many mailing list threads and it's often hard to catch up on them because there's a lot of pointless back and forth and quite frequently the discussion diverges to topics that are not of interest. I am used to having many important design discussions in GitHub issues and frankly it works well.
I'm not saying that it will or should feel the same for everyone. But I do want to emphasize that not everyone experiences the same dread when requested to use a GitHub issue that you and Raymond seem to feel.
--Guido
On Sun, Oct 13, 2019 at 4:04 AM Paul Moore p.f.moore@gmail.com wrote:
I have to say that I agree with Raymond here. I don't think that an issue tracker is a good way to collect this sort of feedback. To be honest, I don't feel that there's going to be much scope to address the sorts of concerns being raised here, so I'm not clear how much value there will be in the discussion, ultimately, but I do think that having a single conversation/thread/topic that covers the "big picture" is important, as for some people the problem is going to be an accumulation of small problems, rather than any one big showstopper. And tracker items have, in my experience, a tendency to dilute the impact of that sort of accumulation.
It seems like the idea here is that we handle the discussion on how to use the github tracker for Python issues, by using a github tracker for the plan. Does that not result in a problem, because people uncomfortable with the github tracker will be uncomfortable with the means they are required to use to express that discomfort, and so their voice won't get heard? Personally, I have a workflow that works (just about) for me, for handling any given github issue tracker (filtering email notifications to a dedicated folder for the tracker) but that method does not scale very well, and it *definitely* doesn't work for following trackers on an adhoc basis. So I'm not going to easily be able to follow discussion on the tracker-for-discussing-issues-with-the-proposed-cpython-issue-tracker (ERROR: Recursion depth exceeded ;-)) So I guess I give up and leave the decision to others. In my case, not that big of a deal, as I don't use the current tracker that heavily - but if someone like Raymond takes that view, that's (IMO) quite a lot more serious.
Paul
On Sun, 13 Oct 2019 at 06:20, raymond.hettinger@gmail.com wrote:
Are you saying that this whole thread of issues will be ignored unless
we all go to another forum, post a dozen separate issues, and recreate all of the discussion that already these threads?
That doesn't seem reasonable to me for several reasons: 1) it is
unlikely that the full thread content would survive the forum transfer, so that some important aspects of the conversation will be lost, 2) some of us have very few clocks cycles available to allocate because discussion threads and actual core development, 3) this is outside our historical norm -- we normally do PEP level discussions on the lists rather than in many separate issues, 4) the separate issue approach (particularly if it is in core-workflow) won't have much visibility or participation for the folks who currently do most of the work on the tracker, and 5) having separate issues tends to obscure the big picture of how much functionality will be lost as a result of the migration and how much disruption will be caused by breaking existing user conversations and losing searchable history.
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at
https://mail.python.org/archives/list/python-committers@python.org/message/2...
Code of Conduct: https://www.python.org/psf/codeofconduct/
python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/C... Code of Conduct: https://www.python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/ _______________________________________________ python-committers mailing list -- python-committers@python.org To unsubscribe send an email to python-committers-leave@python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/I... Code of Conduct: https://www.python.org/psf/codeofconduct/
participants (9)
-
Benjamin Peterson -
Guido van Rossum -
Mariatta -
Paul Moore -
Raymond Hettinger -
raymond.hettinger＠gmail.com
-
Senthil Kumaran -
Steve Dower -
Steven D'Aprano