As a mere user I'd like to thank the developer team for biting this bullet. Remembering the transition to Git I am sure that the further democratisation (?) of the development process will similarly increase the diversity and scope of the development effort. It will indeed be a significant effort to effect this migration. While it's inevitable this will involve significant dev time, perhaps there roles can be identified specifically as to be filled by _other_ than core devs. On Wed, May 15, 2019 at 2:43 AM Victor Stinner wrote:

Congrats Mariatta :-)

Victor

Le mer. 15 mai 2019 à 03:14, Barry Warsaw a écrit :

...

As the BDFL-Delegate for PEP 581, and with the unanimous backing of the

rest of the Steering Council, I hereby Accept this PEP.

...

We would like to thank Mariatta for championing PEP 581, and to all the

contributors to the discussion, both pro and con. We appreciate your candor and respect for your fellow developers. The SC believes that this migration is in the best interest of the Python community, and we look forward to the elaboration of the detailed migration plan (PEP 588).

...

We also extend our heartfelt thanks Berker, Ezio, and everyone who has

helped develop and maintain Roundup and bugs.python.org over the years. bpo has been a critical component for Python development for a very long time, and we all greatly appreciate the time, effort, and devotion you have put into this resource.

...

https://www.python.org/dev/peps/pep-0581/

Onward we go! The migration will be a large effort, with much planning,

development, and testing, and we welcome volunteers who wish to help make it a reality. I look forward to your contributions on PEP 588 and the actual work of migrating issues to GitHub.

...

Cheers, -Barry (BDFL-Delegate, and on behalf of the Python Steering Council)

_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com

-- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve%40holdenweb.com

On Tue, 14 May 2019 18:11:14 -0700 Barry Warsaw wrote:

As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of the Steering Council, I hereby Accept this PEP.

For future reference, is it possible to post the Steering Council's reflection and rationale on the PEP? Thank you Regards Antoine.

On 15/05/2019 10.55, Ivan Pozdeev via Python-Dev wrote:

On 15.05.2019 11:48, Antoine Pitrou wrote:

...

On Tue, 14 May 2019 18:11:14 -0700 Barry Warsaw wrote:

...

As the BDFL-Delegate for PEP 581, and with the unanimous backing of the rest of the Steering Council, I hereby Accept this PEP. For future reference, is it possible to post the Steering Council's reflection and rationale on the PEP? +1. Specifically, I'd like to know if the risks and the potential for GitHub missing any needed features were estimated. The PEP says nothing about this.

I'm not happy with the fact, that the PEP does not mention any arguments or concerns that were raised against the current feature set of Github's issue tracker. In the past, PEPs also listed risks and arguments against a change, then weighted the arguments. What are the next step? Will there be another PEP that explores how we are going to deal with migration, workflow changes, and how we plan to map current BPO features to Github? Christian

Le mer. 15 mai 2019 à 11:31, Christian Heimes a écrit :

What are the next step? Will there be another PEP that explores how we are going to deal with migration, workflow changes, and how we plan to map current BPO features to Github?

Yes, it's the: PEP 588 -- GitHub Issues Migration Plan https://www.python.org/dev/peps/pep-0588/ Victor -- Night gathers, and now my watch begins. It shall not end until my death.

On Wed, 15 May 2019 at 15:56, Victor Stinner wrote:

Hi Paul, Le mer. 15 mai 2019 à 11:40, Paul Moore a écrit :

...

Also, is there an archive of the discussions anywhere? The PEP says discussions happened on Zulip, but I don't follow that and I don't know where I can find an archived copy of the discussions.

Well, the PEP has been discussed a lot at many places since May 2018.

Thanks for all of these. I appreciate the time you took locating them for me. But I do have to say that I still can't really follow any useful "thread of discussion" - it all seems very fragmented, and it's difficult to see the progress towards consensus. Maybe that's just because I'm too used to mailing lists :-)

The PEP 581 has been (first?) discussed at the Language Summit which was part of Pycon US 2018 (May 2018).

Was that written up, or is it all just from people's memories by now?

https://github.com/python/peps/pull/681/

Ah - I don't really follow this sort of PR discussion, as the github emails don't tend to have sufficient context on what's being said, so I (mostly) gave up a long time ago. Also, I tend to assume that discussions on PRs are mostly about details of wording, and substantive changes will be dealt with in a wider forum. I wonder if I should be following PRs on the PEPs repository more closely...?

Multiple threads on Discourse:

https://discuss.python.org/t/move-pep-581-discussion/873 https://discuss.python.org/t/pep-581-using-github-issues/535 https://discuss.python.org/t/what-are-next-steps-for-pep-581/864 https://discuss.python.org/t/pep-process-after-pep-8016/558/4

Thread on python-dev:

https://mail.python.org/pipermail/python-dev/2019-March/156626.html

Threads on python-committers:

https://mail.python.org/pipermail/python-committers/2018-May/005428.html https://mail.python.org/pipermail/python-committers/2018-June/005506.html https://mail.python.org/pipermail/python-committers/2018-July/005657.html

I saw these, but didn't get much of a sense of progress towards agreement. Again, maybe just because they were lots of fragmented threads and locations.

Discussion on Zulip Chat:

https://python.zulipchat.com/#narrow/stream/130206-pep581

I can't see this without logging in :-(

The Steering Council discussed it internally as well:

https://github.com/python/steering-council/blob/master/updates/2019-04-26_st...

I did see that, I was more wondering what led to that decision (whether it was a general consensus from the core devs that it was a good move, or mainly the SC's own view that prevailed).

The PEP 581 and 588 have been discussed at the Language Summit which was part of Pycon US 2019 (2 weeks ago).

Again, has there been any write up of that (yet)? As I say, I don't object to the decision, I'm more just trying to better understand the process of being involved under the new regime of the SC, combined with multiple fragmented forums for discussion. It feels a lot harder these days to keep track of all the discussions/decisions going on. But maybe that's a good thing - only people with a genuine interest get involved, and I can spend less of my time reading mailing lists! :-) Paul

On Wed, May 15, 2019 at 5:38 AM Victor Stinner wrote:

Le mer. 15 mai 2019 à 11:31, Christian Heimes a écrit :

...

What are the next step? Will there be another PEP that explores how we are going to deal with migration, workflow changes, and how we plan to map current BPO features to Github?

Yes, it's the:

PEP 588 -- GitHub Issues Migration Plan https://www.python.org/dev/peps/pep-0588/

And to be very clear here, PEP 588 is *not* accepted yet, so it's open for changes. I personally would consider the accepting of PEP 581 as a signal that the SC thinks it's worth putting the effort into migrating to GitHub for issues and so now we can focus our efforts as a team in trying to make this result in the workflow that we want. And I suspect everyone knows this, but just in case, I want to personally state that I hope everyone understands that there is no way everyone will be happy with the outcome of this transition and that's okay. :) Workflow is one of those things where people are very often opinionated (just look at all of us and our preference in programming language ;) . Obviously we can all do what we can to be accommodating and come up with a solution that works for as many people as possible (including external folks like triagers and issue reporters), but I hope everyone goes into this being as understanding as possible so we can try to get the best outcome we can.

Hello, On Wed, May 15, 2019 at 5:18 PM Paul Moore wrote:

On Wed, 15 May 2019 at 15:56, Victor Stinner wrote:

...

Hi Paul, Le mer. 15 mai 2019 à 11:40, Paul Moore a écrit :

...

Also, is there an archive of the discussions anywhere? The PEP says discussions happened on Zulip, but I don't follow that and I don't know where I can find an archived copy of the discussions.

Well, the PEP has been discussed a lot at many places since May 2018.

Thanks for all of these. I appreciate the time you took locating them for me. But I do have to say that I still can't really follow any useful "thread of discussion" - it all seems very fragmented, and it's difficult to see the progress towards consensus. Maybe that's just because I'm too used to mailing lists :-)

I share the same concerns: 1) the discussion was fragmented between zulip/discuss/github/python-dev/python-committers/sprints/pycons and very difficult to follow, even for interested people (Victor already posted several links but missed a few others); 2) the progress toward consensus was not clear and the approval came somewhat unexpectedly (it was mentioned a couple of weeks ago on https://mail.python.org/pipermail/python-committers/2019-April/006705.html and AFAICT no further discussion took place in public forums since then); In addition: 1) the PEP contains several factual errors. I pointed this out during the core-sprints last year and more recently Berker pointed out some on GitHub: https://github.com/python/peps/pull/1013 ; 2) the "discussions-to" header of the PEP points to the zulip stream. The stream has not been active for 6 months (it got a few new messages today, the previous activity was in Dec 2018); 3) most of the discussions linked by Victor happened last year. Unless I missed some, the only discussions happened this year are the two on Discuss from February (with 3 messages each from a total of 5 authors), and the python-dev thread from March (with 12 messages from 7 authors). One of the two Discuss threads was a inquiry about the process (https://discuss.python.org/t/move-pep-581-discussion/873); 4) Berker is/was writing a competing PEP, in order to address the problems of PEP 581 more effectively since his comments on GitHub haven't been addressed; 5) next week a student is supposed to start working for the PSF on b.p.o and Roundup as part of Google Summer of Code (http://python-gsoc.org/psf_ideas.html); 6) PEP 8016 says "The council should look for ways to use these powers as little as possible. Instead of voting, it's better to seek consensus. Instead of ruling on individual PEPs, it's better to define a standard process for PEP decision making."; To summarize, I feel the approval of this PEP is premature and that consensus was reached in a way that wasn't very transparent, without considering some of the concerns. (This might also be a symptom of a wider problem caused by the fragmentation of the discussions between the old MLs, discuss, zulip, IRC, GitHub PRs and issues, and IRL meetings, but this is a separate topic.) Best Regards, Ezio Melotti

...

The PEP 581 has been (first?) discussed at the Language Summit which was part of Pycon US 2018 (May 2018).

Was that written up, or is it all just from people's memories by now?

...

https://github.com/python/peps/pull/681/

Ah - I don't really follow this sort of PR discussion, as the github emails don't tend to have sufficient context on what's being said, so I (mostly) gave up a long time ago. Also, I tend to assume that discussions on PRs are mostly about details of wording, and substantive changes will be dealt with in a wider forum. I wonder if I should be following PRs on the PEPs repository more closely...?

...

Multiple threads on Discourse:

https://discuss.python.org/t/move-pep-581-discussion/873 https://discuss.python.org/t/pep-581-using-github-issues/535 https://discuss.python.org/t/what-are-next-steps-for-pep-581/864 https://discuss.python.org/t/pep-process-after-pep-8016/558/4

Thread on python-dev:

https://mail.python.org/pipermail/python-dev/2019-March/156626.html

Threads on python-committers:

https://mail.python.org/pipermail/python-committers/2018-May/005428.html https://mail.python.org/pipermail/python-committers/2018-June/005506.html https://mail.python.org/pipermail/python-committers/2018-July/005657.html

I saw these, but didn't get much of a sense of progress towards agreement. Again, maybe just because they were lots of fragmented threads and locations.

...

Discussion on Zulip Chat:

https://python.zulipchat.com/#narrow/stream/130206-pep581

I can't see this without logging in :-(

...

The Steering Council discussed it internally as well:

https://github.com/python/steering-council/blob/master/updates/2019-04-26_st...

I did see that, I was more wondering what led to that decision (whether it was a general consensus from the core devs that it was a good move, or mainly the SC's own view that prevailed).

...

The PEP 581 and 588 have been discussed at the Language Summit which was part of Pycon US 2019 (2 weeks ago).

Again, has there been any write up of that (yet)?

As I say, I don't object to the decision, I'm more just trying to better understand the process of being involved under the new regime of the SC, combined with multiple fragmented forums for discussion. It feels a lot harder these days to keep track of all the discussions/decisions going on. But maybe that's a good thing - only people with a genuine interest get involved, and I can spend less of my time reading mailing lists! :-)

Paul _______________________________________________ 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/

IMO the text of PEP 581 could use some improvements to capture more of the debate. For example: - If people want to submit PRs to the peps repo that correct *factual* mistakes in PEP 581, they're welcome to (and I will personally see that they will be merged). For example, IIRC you *can* reply to a bpo issue via email, so that bullet should probably be struck. - If someone wants to volunteer a PR to the peps repo that adds a list of objections against the move, e.g. losing certain bpo capabilities, or specific undesirable behaviors or properties of GitHub, that will also be entertained (but be reasonable). But trust me that the SC didn't take this decision lightly. It was unanimous, and we have all thought about this a great deal (and listened to long arguments pro and con). It's also impossible to satisfy everyone -- some people find GitHub unacceptable (I've heard about 1-2 people who refused to create GitHub accounts), but others find bpo unusable (the need to have a bpo account in order to accept the CLA has been brought up repeatedly). A successful migration will take a lot of work, and PEP 588 is where we keep track of tasks to be accomplished. (There are more that haven't made it to that PEP, e.g. the mechanics of the actual move.) We're also hoping to get professional help managing the migration so that not everything relies on volunteers. (Speaking of relying on volunteers, if you haven't seen Russel Keith-Magee's keynote at the most recent PyCon US, please watch it. It is an amazing thing. https://www.youtube.com/watch?v=ftP5BQh1-YM -- start at 21:00 to skip the conference opening remarks.) -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him/his **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...

Frankly, multiple long meandering threads in s single mailing list are not s very good archive either. Ideally, the PEP is updated with a summary of the issues discussed as the discussion unfolds. (And links to the main discussion threads?) It founds like that didn’t happen in this case, but it’s not necessarily too late. As the community seems to be moving to a wider variety of fora, this will become all the more critical. - CHB

On May 15, 2019, at 1:09 PM, Stephen J. Turnbull wrote:

Stripping the list of addressees, since I'm pretty sure all the people who will *make* the decision read Python-Dev regularly, except perhaps Carol.

Paul Moore writes:

...

Thanks for all of these. I appreciate the time you took locating them for me. But I do have to say that I still can't really follow any useful "thread of discussion" - it all seems very fragmented, and it's difficult to see the progress towards consensus. Maybe that's just because I'm too used to mailing lists :-)

Please, let's not start by privileging any particular type of channel in this discussion. I know what I like, but it's far more important to have a single place to refer to past discussion IMO. It's bad enough with python-ideas and python-dev.

Maybe this fragmentation is OK in the long run, but at least while the Steering Council is shaking down (say, until release of 3.9?), the Council should consider anointing two archived "channels of record", one for private deliberations of the Council itself (for the sake of future members), and one for PEP discussions.

Of course if the SC chooses Discourse for the PEP channel, people *will* discuss PEPs on Python-Dev and IRL. The point is "no fair pointing people to *other* channels for reference". If you want to make a public argument, make it in the proper place. Everything else is effectively private. If you want to refer to that in the public discussion, read it into the public record.

The stricture for the Council deliberation channel is different, since I expect the archives would be private to Council members: if you came into this discussion in the middle, what conversations would you want to be able to review?

While I'm here, is there a place where general Pythonistas can bring matters to the attention of the Council?

Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov

On Wed, May 15, 2019 at 1:10 PM Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp> wrote: [SNIP]

While I'm here, is there a place where general Pythonistas can bring matters to the attention of the Council?

https://github.com/python/steering-council is where we're asking people to ask stuff so it's recorded in a central location that's publicly visible. -Brett

Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org

Chris Barker - NOAA Federal writes:

Frankly, multiple long meandering threads in s single mailing list are not s very good archive either.

True, but I have no idea how to address that administratively, except to have a *very* strong moderator.

Ideally, the PEP is updated with a summary of the issues discussed as the discussion unfolds.

The point of "channel of record" is not that it would replace the PEPs themselves. It's that PEP authors are people with time limitations, too. For example, there's at least one person currently requesting a review on a PEP who has in the past loudly and publicly announced their unsubscription from python-ideas and IIRC even python-dev. I think it's a good idea to have *one* place that is the principal source for PEP protagonists who don't have time for or simply dislike participating in some (or even all) of the channels du jour. With a designated channel of record, if discussions take place elsewhere, the PEP protagonist *may*, but would be under *no obligation* to, follow them or search for them. In the current situation, there's an implicit obligation for the protagonist to check all the channels, maybe even to do a Google search. Or at least some of the posters seem to feel that way.

As the community seems to be moving to a wider variety of fora, this will become all the more critical.

It would also be possible, I suppose, for the PEP protagonist to designate a channel in the PEP. That has its problems too (they can choose a channel that is inconvenient for the majority of interested participants, for example), but with a designated channel system of either kind the problems are predictable and bounded. Steve