[Python-Dev] PEP 595: Improving bugs.python.org
On Sat, Jun 1, 2019 at 11:50 AM Antoine Pitrou <solipsis at pitrou.net> wrote:
> 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.
These can be further divided in several groups: from core devs and
release managers, to triagers, to regular and occasional contributors,
to people that just want to report an issue and be done with it, to
people that think the error they just got is a Python bug, each of
them with different goals and needs.
I think that rather than discussing whether GitHub Issues is better or
worse than Roundup, we should first try to understand who is facing
what issues now, and who will face what issues after the switch. This
can be done both by gathering feedback from different types of people
and by testing and comparing the solutions (see below).
Once we know what the issues are, we should evaluate if and how we can
address them, and also -- if we can't make everyone happy -- what
groups of people we want to prioritize (e.g. do we want core devs to
be more effective at dealing with the thousands of already existing
issues, or we want to make it easier for users to report new bugs?).
> > > 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.
Testing a change of this magnitude is not trivial. I can see several
* using the on-demand approach proposed by PEP 588, a full migration,
or some other solution (e.g. parallel, synced trackers);
* doing a throwaway test migration (import zero/some/all existing
issues, then discard any new message/issue at the end of the test) or
using real issues directly (import zero/some/all issues and keep
adding real messages/issues);
* if we do a test migration and it works, we might need to do a
second, real migration, possibly involving the GH staff twice; if it
doesn't work, we discard everything and that's it;
* if we use real issues, we might need to migrate things back to
Roundup if GH doesn't fit our needs and it might be confusing for
* starting from scratch on GH with new issues (at least initially, for
testing purposes) or porting some/all issues from bpo;
* if we start from scratch we don't need to write the tools to
migrate, but we won't have feedback about searching/navigating through
lot of issues;
* if we port some/all the issues, we need to write the tools to do
it, even if it's just for testing purposes and we end going back to
* limiting the test to triagers/core-devs, or involve regular users;
* if we involve regular users we might get better feedback, but
there's risk of confusion (afaik the only way to inform users on
GitHub Issues is writing another bot that adds messages) and backlash;
* doing separate specific tests (e.g. having a read-only repo with all
the issues to test search/navigation, and a separate read-write repo
to test issue creation) or a "real-world" test;
* some specific tests might be easier to setup (e.g. issue creation
test using templates), but for others we still need to import some/all
If we agree on testing, I think we need to discuss the options, define
and document a list of steps, and start working on it.