Nathaniel Smith wrote:
On Fri, May 31, 2019 at 11:39 AM Barry Warsaw <ba...@python.org> wrote:
On May 31, 2019, at 01:22, Antoine Pitrou <solip...@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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
