PEP 581 (Using GitHub issues for CPython) is accepted
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)
Congrats Mariatta :-) Victor Le mer. 15 mai 2019 à 03:14, Barry Warsaw <barry@python.org> 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.
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 <vstinner@redhat.com> wrote:
Congrats Mariatta :-)
Victor
Le mer. 15 mai 2019 à 03:14, Barry Warsaw <barry@python.org> 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 Wed, 15 May 2019 08:40:58 +0100 Steve Holden <steve@holdenweb.com> wrote:
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.
"Similarly"? We still lack some metrics on that point, IIRC. Regards Antoine.
On Tue, 14 May 2019 18:11:14 -0700 Barry Warsaw <barry@python.org> 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 11:48, Antoine Pitrou wrote:
On Tue, 14 May 2019 18:11:14 -0700 Barry Warsaw <barry@python.org> 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. Thank you
Regards
Antoine.
_______________________________________________ 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/vano%40mail.mipt.ru
-- Regards, Ivan
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 <barry@python.org> 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 <christian@python.org> 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, May 15, 2019 at 5:38 AM Victor Stinner <vstinner@redhat.com> wrote:
Le mer. 15 mai 2019 à 11:31, Christian Heimes <christian@python.org> 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.
On Wed, 15 May 2019 at 09:51, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Tue, 14 May 2019 18:11:14 -0700 Barry Warsaw <barry@python.org> 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?
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. It's not as if I'm going to object to the PEP (I'd have participated in the discussions if I had a strong opinion) but I am curious. Paul
Hi Paul, Le mer. 15 mai 2019 à 11:40, Paul Moore <p.f.moore@gmail.com> 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. The PEP 581 has been (first?) discussed at the Language Summit which was part of Pycon US 2018 (May 2018). Discussion on the PR: https://github.com/python/peps/pull/681/ 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 Discussion on Zulip Chat: https://python.zulipchat.com/#narrow/stream/130206-pep581 The Steering Council discussed it internally as well: https://github.com/python/steering-council/blob/master/updates/2019-04-26_st... The PEP 581 and 588 have been discussed at the Language Summit which was part of Pycon US 2019 (2 weeks ago). 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 <vstinner@redhat.com> wrote:
Hi Paul, Le mer. 15 mai 2019 à 11:40, Paul Moore <p.f.moore@gmail.com> 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?
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:
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 8:18 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Wed, 15 May 2019 at 15:56, Victor Stinner <vstinner@redhat.com> wrote:
Hi Paul, Le mer. 15 mai 2019 à 11:40, Paul Moore <p.f.moore@gmail.com> 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?
There's at least https://lwn.net/Articles/754779/. Don't remember if other people wrote up their own summary. [SNIP]
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)?
Not yet, but A. Jesse Jiryu Davis attended so the PSF could blog about it.
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,
I think everyone is. :) In the case of this PEP the various members of the SC have been keeping up with the PEP and its discussions over the year that the PEP has been around, we discussed the pros and cons that people brought up, thought through what will be required for us to do the migration if the PEP was accepted, and in the end decided it was worth the effort.
combined with multiple fragmented forums for discussion.
A PEP is being worked on to try and propose a way to straighten this all out, but travel, life, etc. has been keeping that one from being finished. I've added discussing the status of it to our next meeting's agenda.
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! :-)
Obviously YMMV, but I actually find it easier. :) -Brett
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/
Hello, On Wed, May 15, 2019 at 5:18 PM Paul Moore <p.f.moore@gmail.com> wrote:
On Wed, 15 May 2019 at 15:56, Victor Stinner <vstinner@redhat.com> wrote:
Hi Paul, Le mer. 15 mai 2019 à 11:40, Paul Moore <p.f.moore@gmail.com> 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?
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:
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/
On Wed, May 15, 2019 at 6:44 PM Ezio Melotti <ezio.melotti@gmail.com> wrote:
I share the same concerns:
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 ; 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;
This concerns me a bit. The PEP/announcement acknowledges the work Ezio and Berker. However, it does not express if the PEP had addressed their review comments or had the current maintainers on-board with the proposal. I was of the assumption that if the current maintainers (/domain experts) were on-board, then it will be easier for the rest of us to adopt the new changes.
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
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 <turnbull.stephen.fw@u.tsukuba.ac.jp> 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, 15 May 2019 at 21:34, Chris Barker - NOAA Federal via Python-Dev <python-dev@python.org> wrote:
Frankly, multiple long meandering threads in s single mailing list are not s very good archive either.
They aren't, I agree. But in my view, they constitute the *source material* that the summaries in the PEP should be based on. No-one should need to read the archives if they just want to know the points being made. But for someone who wonders how a particular conclusion was reached, having a single archive of record (to use Stephen's phrase) makes sense - certainly people *can* search multiple sources, but we should be trying to be transparent, and not making it too hard to research the background of a decision is part of that.
Ideally, the PEP is updated with a summary of the issues discussed as the discussion unfolds.
I'm not sure that's just "ideally" - one of the key purposes of a PEP should be to summarise the discussions.
(And links to the main discussion threads?)
That's nice to have, yes.
It founds like that didn’t happen in this case, but it’s not necessarily too late.
Definitely. In fact, I doubt there's much of any real interest that needs to be referenced (workflow debates are not the most interesting reading, in my experience :-))
As the community seems to be moving to a wider variety of fora, this will become all the more critical.
I completely agree here.
On May 15, 2019, at 1:09 PM, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
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.
100% agree. This shouldn't be about whether any particular channel is "better" or "worse" than any other. It's just about not having the original content of the discussions that feed into an accepted PEP be scattered too widely.
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?
In theory, PEP 13 says that the council should look for consensus rather than making decisions on their own. Ideally, the council's private deliberations should be of little interest to anyone else, because either (a) the consensus should be clearly visible from the public record of the debate, or (b) the public record should show that the discussion was getting nowhere, and the council had to make the final decision (at which point, the community has effectively given up the right to argue about why the council chose what they did). The reason the decision on PEP 581 started me thinking about this was precisely because I hadn't seen any signs of that consensus or of a stalled discussion. Maybe I wasn't looking in the right places, but I *thought* I was following the majority of PEP-related discussions (at least skimming them). So I was somewhat startled to see a formal decision come with what felt like no real warning. Paul
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
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
On 15May2019 0240, Paul Moore wrote:
On Wed, 15 May 2019 at 09:51, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Tue, 14 May 2019 18:11:14 -0700 Barry Warsaw <barry@python.org> 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?
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.
I think it would be ideal if the PEP itself summarised the major points of these discussions, or at least the links to the discussions (assuming we trust Zulip and Discourse to never lose them). Right now I have a lot of fundamental problems with this PEP as written. But I'm assured that the Steering Council gave it thorough consideration and that the discussions covered all relevant aspects, so I'm not going to create too much of a fuss about it. If they want to move us completely to GitHub, so be it! Cheers, Steve
On Wed, May 15, 2019 at 9:53 AM Steve Dower <steve.dower@python.org> wrote:
On Wed, 15 May 2019 at 09:51, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Tue, 14 May 2019 18:11:14 -0700 Barry Warsaw <barry@python.org> wrote:
As the BDFL-Delegate for PEP 581, and with the unanimous backing of
On 15May2019 0240, Paul Moore wrote: 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?
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.
I think it would be ideal if the PEP itself summarised the major points of these discussions, or at least the links to the discussions (assuming we trust Zulip and Discourse to never lose them).
Right now I have a lot of fundamental problems with this PEP as written. But I'm assured that the Steering Council gave it thorough consideration
Yes, sorry if that wasn't communicated better. This was in no way a knee-jerk decision. Beyond all of us following this topic personally since it was first brought up last year, we have also been discussing it nearly every meeting in some form or another since we began discussing PEPs (which would be probably since February).
and that the discussions covered all relevant aspects, so I'm not going to create too much of a fuss about it. If they want to move us completely to GitHub, so be it!
I've added to our next meeting's agenda discussing potentially fleshing out PEP 581 a bit more. -Brett
Cheers, 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
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...>
Le mer. 15 mai 2019 à 20:46, Guido van Rossum <guido@python.org> a écrit :
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).
Around me, many people told me that they were awaiting for the PEP 581 to be accepted,. They are now *very kind* that Python issues are moving to GitHub. Honestly, I don't understand why people are excited by bug tracker, for me it's not the most exciting part of development :-) But it seems like many people were unhappy with Roundup. At least, I can say that I'm not a big fan of it's UI (maybe too complex, too many fields) compared to GitHub. I can also understand that it's annoying for contributor to have to create 2 separated accounts (bugs.python.org and GitHub) and link them *carefully* (mistakes are common, you can see that when a contributor waits for the "CLA signed" label). Sometimes, they are some glitches with bugs.python.org <=> GitHub integration: some notifications take longer 30 sec or simply never happen. I understand that GitHub is better to *report* bugs (and maybe to comment an issue), but maybe worse for bug triage, and that we want to make sure that it's easier to contribute to Python for "regular contributors". I also know that GitHub isn't perfect and that it will take time to build a new efficient workflow on top of GitHub.
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.
That would be great! The migration of the code took something like 2 years and it was a little bit painful for everybody at the beginning. Having someone paid for that would make the migration shorter and maybe also smoother. Victor -- Night gathers, and now my watch begins. It shall not end until my death.
participants (14)
-
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Chris Barker - NOAA Federal -
Christian Heimes -
Ezio Melotti -
Guido van Rossum -
Ivan Pozdeev -
Paul Moore -
Senthil Kumaran -
Stephen J. Turnbull -
Steve Dower -
Steve Holden -
Victor Stinner