[python-committers] Comments on moving issues to GitHub

[Nick Coghlan]

On 21 May 2018 at 05:03, Brett Cannon <brett at python.org> wrote:

>
>
> On Sun, 20 May 2018 at 10:43 Barry Warsaw <barry at python.org> wrote:
>
>> On May 20, 2018, at 10:19, Nathaniel Smith <njs at pobox.com> wrote:
>> >
>> > IIRC, the general reaction was that it was definitely worth exploring,
>> but that it would be a lot of work and require solutions to a lot of
>> problems to make sure people's workflows weren't too impacted, so we'd need
>> a much more detailed proposal before any decision could be made.
>>
>> Note too that Bryan Clark from GitHub, who I believe is a product manager
>> there, was at the packaging mini-summit.  If/when we have a specific set of
>> asks for the migration, we can reach out to him and see how they can help.
>> For example, I specifically asked about my favorite GitLab feature “commit
>> when CI passes” and it sounded like they were working on that.
>>
>
> There was also general consensus that the state of maintenance for bpo is
> subpar due to lack of staffing and that more people will need to come
> forward to help maintain it if we decide to not transition to another issue
> tracker like GitHub or GitLab.
>

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.

Some examples of problems that would benefit from attention:

- fixing the SSL/TLS connectivity issues
- making the issue tracker usable on mobile devices
- ability to edit the description for issues that evolve over time, not
just the title
- improved editing support for comments (both in initial formatting, and in
being able to correct errors)
- REST API access to tracker data
- simplifying account creation (especially for folks that already have
GitHub accounts)
- rationalising the metadata fields by asking which ones actually see
significant use

Some examples of problems that in-place enhancement of the tracker would
inherently avoid, but a migration proposal would need to address:

- preservation of existing incoming links to issues
- figuring out which issues to migrate automatically (all of them? None of
them? Open issues only?)
- figuring out a new way to track PSF CLA signatures
- figuring out a replacement for the Experts Index integration into the
Roundup nosy list
- figuring out replacements for the custom metadata fields that we actually
use regularly
- meeting our original GitHub migration commitment to continue offering a
way of engaging with the core development process without requiring
accounts with any entity other than the PSF

It's far from being a foregone conclusion that migrating to a new issue
tracker will be the preferred answer, but there are also genuine problems
with the status quo that need to be addressed somehow.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20180521/ef3b3998/attachment.html>