On 21 May 2018 at 05:03, Brett Cannon <br...@python.org> wrote: > > > On Sun, 20 May 2018 at 10:43 Barry Warsaw <ba...@python.org> wrote: > >> On May 20, 2018, at 10:19, Nathaniel Smith <n...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
