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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4