[python-committers] Comments on moving issues to GitHub (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Mon May 21 06:24:43 EDT 2018
- Previous message (by thread): [python-committers] Comments on moving issues to GitHub
- Next message (by thread): [python-committers] Comments on moving issues to GitHub
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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>
- Previous message (by thread): [python-committers] Comments on moving issues to GitHub
- Next message (by thread): [python-committers] Comments on moving issues to GitHub
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]