[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Senthil Kumaran]

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  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  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,  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-le...@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/2HWYHURO7XETBZO7YR4V6JDWX3FA2OA5/
>> > 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-le...@python.org
>> 

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Guido van Rossum]

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  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,  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-le...@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/2HWYHURO7XETBZO7YR4V6JDWX3FA2OA5/
> > 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-le...@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/C2RRCOM2XN2D77RWCID72YDOLN5V33I5/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Paul Moore]

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,  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-le...@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/2HWYHURO7XETBZO7YR4V6JDWX3FA2OA5/
> 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-le...@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/C2RRCOM2XN2D77RWCID72YDOLN5V33I5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[raymond . hettinger]

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-le...@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/2HWYHURO7XETBZO7YR4V6JDWX3FA2OA5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Mariatta]

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  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-le...@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/ZQTBEO26FJPJNWXSYTJPIKHYPZBPHJFD/
> 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-le...@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/F2NYJRIL7LITL2ENO7OK6CVPKDSB6J36/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Steve Dower]

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-le...@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/ZQTBEO26FJPJNWXSYTJPIKHYPZBPHJFD/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Steven D'Aprano]

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.

-- 
Steven
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@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/N2LECHG2ZAMRFYCZNDULEWUN4HMR56H5/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Benjamin Peterson]

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.
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@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/KA7EO6JS2RRDMOUQ5DNQA7JIHHKNR6ZZ/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Steven D'Aprano]

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?


-- 
Steven
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@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/GCNBVUFKD4LH6IKKBZCNF43YFC2EUNWW/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Benjamin Peterson]

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/
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@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/HUJMQNJ6FW4DURNRGIXRKQSJ5HSFG5YW/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Raymond Hettinger]

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
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@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/IFSHRRBKRP56NOVI4DDWNWKAUK53C5SK/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Raymond Hettinger]

> On Aug 27, 2019, at 10:44 AM, Mariatta  wrote:
> 
> (cross posting to python-committers, python-dev, core-workflow)
> 
> PEP 581: Using GitHub Issues has been accepted by the steering council, but 
> PEP 588: GitHub Issues Migration plan is still in progress.
> 
> I'd like to hear from core developers as well as heavy b.p.o users, the 
> following:
> 
>   • what features do they find lacking from GitHub issues, or
>   • what are the things you can do in b.p.o but not in GitHub, or
>   • Other workflow that will be blocked if we were to switch to GitHub 
> today
> By understanding your needs, we can be better prepared for the migration, and 
> we can start looking for solutions.

One other bit of workflow that would be blocked if there was a switch to GitHub 
today:

* On the tracker, we have long running conversations, sometimes spanning years. 
  We need to be able to continue those conversations even though the original 
participants may not have Github accounts (also, if they do have a Github 
account, we'll need to be able to link to the corresponding BPO account).  

* I believe some of the accounts are anonymous or have pseudonyms.  Am not sure 
how those can be migrated, we know very little about the participant except for 
their recurring posts.


Raymond


___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@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/MT2PJFS2CVDSWQKCCRUR3BCNXR4OSEKU/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: PEP 581/588 RFC: Collecting feedback about GitHub Issues

[Raymond Hettinger]

> On Aug 27, 2019, at 10:44 AM, Mariatta  wrote:
> 
> (cross posting to python-committers, python-dev, core-workflow)
> 
> PEP 581: Using GitHub Issues has been accepted by the steering council, but 
> PEP 588: GitHub Issues Migration plan is still in progress.
> 
> I'd like to hear from core developers as well as heavy b.p.o users, the 
> following:
> 
>   • what features do they find lacking from GitHub issues, or
>   • what are the things you can do in b.p.o but not in GitHub, or
>   • Other workflow that will be blocked if we were to switch to GitHub 
> today
> By understanding your needs, we can be better prepared for the migration, and 
> we can start looking for solutions.

Thanks for soliciting input and working on this.

I'm a heavy BPO user (often visiting many times per day for almost two 
decades).  Here are some things that were working well that I would miss:

* We controlled the landing page, giving us

   - A professional, polished appearance
   - A prominent Python Logo
   - A search bar specific to the issue tracker
   - A link to Python Home and the Dev Guide
   - Hot links to Easy Issues, Issues created by You, Issues Assigned to You

* The display format was terse so we could easily view the 50 most recent 
active issues (this is important because of the high volume of activity)

  See https://mail.python.org/pipermail/python-bugs-list/2019-July/date.html 
for an idea of the monthly volume.

* The page used straight HTML anchor tags so my browser could mark which issue 
had been visited.  This is important when handing a lot of issues which are 
constantly being reordered.

* The input box allowed straight text input in a monospace font so it was easy 
to paste code snippets and traceback without incorporating markup.

* Our page didn't have advertising on it.

* Having a CSV download option was occasionally helpful.

* BPO was well optimized for a high level of activity and high information 
density.

* BPO existed for a very long time.  It contains extensive internal links 
between issues. There are also a huge number of external deep links to specific 
messages and whatnot.  Innumerable tweets, blog posts, code comments, design 
documents, and stack overflow questions all have deep links to the site. It 
would be a major bummer if these links were broken.  It is my hope that they be 
preserved basically forever.


Things that I look forward to with Github Issues:

* Single sign-on

* Better linkage between issues and PRs


What I really don't want:

* The typical Github project page prominently shows a list of files and 
directories before there is any description.  If the CPython issues pages looks 
like this, it will be a big step backwards, making it look more like a weekend 
project than a mature professional project.  It would be something I would not 
want to show to clients.  It would not give us the desired level of control 
over the end-user experience.

* If there are advertisements on the page that we don't control, that would be 
unprecedented and unwelcome.

* On the one hand, we want issues to be easier to file.  On the other hand, if 
the volume of low quality issues reports goes up, it will just add to the total 
labor and contribute to negativity (denying someone's request isn't fun for 
either the rejector or rejectee).

* We need to retain control over our data so that we're free to make other 
migration decisions in the future.  We can make a change now *because* we have 
the freedom.  The migration needs to avoid vendor lock-in.


I have high hopes for this being a successful migration but have to confess 
major disappointment that the steering committee approved this without talking 
with the heavy BPO users and without seeing what the new landing page would 
look like.

In the end, the success of the migration depends on how the site works for the 
most active issue responders.  If the workload goes up and becomes more awkward 
to do in volume, then heavy volunteer participation will necessarily decline.   
Perhaps a half-dozen individuals do more than half of the work on the tracker.

I have high hopes for the success of the migration but success isn't a given.


Raymond







___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@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/BNHMLY4YEXIG4VANOXSOGNXO5Y7OT3BO/
Code of Conduct: https://www.python.org/psf/codeofconduct/