[Python-Dev] PEP 595: Improving bugs.python.org

[Carol Willing]

Nathaniel Smith wrote:
>
> On Fri, May 31, 2019 at 11:39 AM Barry Warsaw <barry at python.org> wrote:
>>
>>
>> On May 31, 2019, at 01:22, Antoine Pitrou <solipsis at pitrou.net> wrote:
>>
>>>
>>> I second this.
>>>
>>> There are currently ~7000 bugs open on bugs.python.org.  The Web UI
>>> makes a good job of actually being able to navigate through these bugs,
>>> search through them, etc.
>>>
>>> Did the Steering Council conduct a usability study of Github Issues
>>> with those ~7000 bugs open?  If not, then I think the acceptance of
>>> migrating to Github is a rushed job.  Please reconsider.
>>
>>
>


>
>>
>> Thanks for your feedback Antoine.
>>
>> This is a tricky issue, with many factors and tradeoffs to consider.  
>> I really appreciate Ezio and Berker working on PEP 595, so we can put 
>> all these issues on the table.
>>
>> I think one of the most important tradeoffs is balancing the needs of 
>> existing developers (those who actively triage bugs today), and 
>> future contributors.  But this and other UX issues are difficult to 
>> compare on our actual data right now.  I fully expect that just as 
>> with the switch to git, we’ll do lots of sample imports and 
>> prototyping to ensure that GitHub issues will actually work for us 
>> (given our unique requirements), and to help achieve the proper 
>> balance.  It does us no good to switch if we just anger all the 
>> existing devs.
>>
>> IMHO, if the switch to GH doesn’t improve our workflow, then it 
>> definitely warrants a reevaluation.  I think things will be better, 
>> but let’s prove it.
>
>
> Perhaps we should put an explicit step on the transition plan, after
> the prototyping, that's "gather feedback from prototypes, re-evaluate,
> make final go/no-go decision"? I assume we'll want to do that anyway,
> and having it formally written down might reassure people. It might
> also encourage more people to actually try out the prototypes if we
> make it very clear that they're going to be asked for feedback.
>
> -n
>


As Barry mentioned, there are many considerations.

- Will GitHub provide a similar experience as bpo? Can the features 
valued by existing developers be served in a suitable way by GitHub issues?
- What opportunity costs exist for remaining on bpo? Planning, 
reporting, integration with services, and accessibility are some.
- Chicken and egg question: Are there 7000 open issues because the 
existing workflow with bpo inhibits acting on open issues with patches?

Antoine, as for large projects on GitHub with many issues, TypeScript is 
a reasonable proxy with close to 4000 open issues yet only 126 open PRs. 
There are some nice planning things that have been done in the repo 
https://github.com/microsoft/TypeScript/issues as well as good 
documentation around their process and workflow.

Thanks to Ezio and Berker for raising points in PEP 595.

- Carol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190531/d8c9b4b2/attachment.html>