On Aug 27, 2019, at 10:44 AM, Mariatta <mariatta@python.org> wrote:
(cross posting to python-committers, python-dev, core-workflow)
PEP 581: Using GitHub Issues has been accepted by the steering council, but PEP 588: GitHub Issues Migration plan is still in progress.
I'd like to hear from core developers as well as heavy b.p.o users, the following:
• what features do they find lacking from GitHub issues, or • what are the things you can do in b.p.o but not in GitHub, or • Other workflow that will be blocked if we were to switch to GitHub today By understanding your needs, we can be better prepared for the migration, and we can start looking for solutions.
Thanks for soliciting input and working on this. I'm a heavy BPO user (often visiting many times per day for almost two decades). Here are some things that were working well that I would miss: * We controlled the landing page, giving us - A professional, polished appearance - A prominent Python Logo - A search bar specific to the issue tracker - A link to Python Home and the Dev Guide - Hot links to Easy Issues, Issues created by You, Issues Assigned to You * The display format was terse so we could easily view the 50 most recent active issues (this is important because of the high volume of activity) See https://mail.python.org/pipermail/python-bugs-list/2019-July/date.html for an idea of the monthly volume. * The page used straight HTML anchor tags so my browser could mark which issue had been visited. This is important when handing a lot of issues which are constantly being reordered. * The input box allowed straight text input in a monospace font so it was easy to paste code snippets and traceback without incorporating markup. * Our page didn't have advertising on it. * Having a CSV download option was occasionally helpful. * BPO was well optimized for a high level of activity and high information density. * BPO existed for a very long time. It contains extensive internal links between issues. There are also a huge number of external deep links to specific messages and whatnot. Innumerable tweets, blog posts, code comments, design documents, and stack overflow questions all have deep links to the site. It would be a major bummer if these links were broken. It is my hope that they be preserved basically forever. Things that I look forward to with Github Issues: * Single sign-on * Better linkage between issues and PRs What I really don't want: * The typical Github project page prominently shows a list of files and directories before there is any description. If the CPython issues pages looks like this, it will be a big step backwards, making it look more like a weekend project than a mature professional project. It would be something I would not want to show to clients. It would not give us the desired level of control over the end-user experience. * If there are advertisements on the page that we don't control, that would be unprecedented and unwelcome. * On the one hand, we want issues to be easier to file. On the other hand, if the volume of low quality issues reports goes up, it will just add to the total labor and contribute to negativity (denying someone's request isn't fun for either the rejector or rejectee). * We need to retain control over our data so that we're free to make other migration decisions in the future. We can make a change now *because* we have the freedom. The migration needs to avoid vendor lock-in. I have high hopes for this being a successful migration but have to confess major disappointment that the steering committee approved this without talking with the heavy BPO users and without seeing what the new landing page would look like. In the end, the success of the migration depends on how the site works for the most active issue responders. If the workload goes up and becomes more awkward to do in volume, then heavy volunteer participation will necessarily decline. Perhaps a half-dozen individuals do more than half of the work on the tracker. I have high hopes for the success of the migration but success isn't a given. Raymond