[Python-Dev] PEP 595: Improving bugs.python.org
willingc at gmail.com
Fri May 31 15:39:41 EDT 2019
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev