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

[Antoine Pitrou]

On Fri, 31 May 2019 11:58:22 -0700
Nathaniel Smith <njs at pobox.com> 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.

Indeed, regardless of the exact implementation details, I think "try
first, decide after" is the right procedure here.

Regards

Antoine.