[python-committers] Comments on moving issues to GitHub

[Barry Warsaw]

On May 21, 2018, at 03:24, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Right, one of the outcomes of the discussion at the Summit was that any proposal to migrate to a different issue tracker would need to present a clear statement of the *problems intended to be solved*, such that the folks that would prefer to see us stay on our own issue tracker could present a competing proposal to solve those problems without a wholesale migration to another system.

I’d like to see multiple PEPs for this migration.  The first would clearly outline discussion points that apply regardless of where we migrate to, or whether we migrate at all.  This would include lists of common use cases, the problems with the current system, the features we like (and regularly use!) in the current system, and a list of key points that can be compared against any proposed solution.

E.g. for this latter, let’s say one of the points is “ability to easily ignore all discussions on tickets you don’t care about”.  You could imagine a row in a table that shows how any of the proposed solutions compare to what we have today.  You could color code this on a gradient, say from dark green (“it will be much better on system X”) to dark red (“it’ll be much more difficult on system Y”).

That would be one PEP, and it would be the baseline for making a decision.  Additional PEPs would make specific proposals, e.g. move to GH, stay on bpo as is, significantly invest in bpo, etc.  They’d reference the baseline PEP and include that table with the color coded rows.

Then perhaps after the decision is made, there would maybe be an implementation PEP describing the steps it will take to migrate, and the ETA.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180521/9cfddbfb/attachment.sig>