A different way to focus discussions
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.
PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).
Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.
Thoughts? (We can dogfood this proposal too, if there's interest. :-)
-- --Guido van Rossum (python.org/~guido)
I would like to clarify, what would be a typical time-line for a PEP? Will it look like this:
- Preliminary discussions to determine whether an idea is PEP-worthy (can happen anywhere, python-ideas, SIGs, even offline)
- A PEP number is requested by a champion and assigned by a PEP editor (in python/peps repo)
- PEP is drafted and discussed by a narrow circle of interested participants (happens in a separate repo)
- When PEP is ready and polished make a PR to python/peps repo, and post it to python-dev to get feedback (if any) from a wider audience
- If reasonable objections appear at this step, go to step 2
- Repeat steps 2-4 until accepted/rejected/deferred
Is this what you propose? Or you want to completely avoid posting to python-dev?
-- Ivan
On 18 May 2018 at 18:25, Guido van Rossum <guido@python.org> wrote:
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.
PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).
Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.
Thoughts? (We can dogfood this proposal too, if there's interest. :-)
-- --Guido van Rossum (python.org/~guido)
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 Fri, May 18, 2018 at 3:58 PM, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
I would like to clarify, what would be a typical time-line for a PEP? Will it look like this:
- Preliminary discussions to determine whether an idea is PEP-worthy (can happen anywhere, python-ideas, SIGs, even offline)
- A PEP number is requested by a champion and assigned by a PEP editor (in python/peps repo)
I expect some proposals to get stuck before they're ever in a state acceptable even as draft PEP, so I'd like to put off requesting a PEP number as long as possible.
- PEP is drafted and discussed by a narrow circle of interested participants (happens in a separate repo)
- When PEP is ready and polished make a PR to python/peps repo, and post it to python-dev to get feedback (if any) from a wider audience
I expect there to be a long trajectory where the PEP does exist in the peps repo but should still be discussed in its own repo. Mentions on python-dev should be limited to the occasional link to the PEP's own repo, with strongly worded requests to go to that repo to provide feedback.
- If reasonable objections appear at this step, go to step 2
The process should be clear that objections posted to python-dev will be ignored -- only objections posted to the PEP's own repo's issue tracker will be considered.
- Repeat steps 2-4 until accepted/rejected/deferred
Is this what you propose? Or you want to completely avoid posting to python-dev?
I want to completely avoid discussion on python-dev. This probably means we should never post the full text of the PEP there. (We may have to amend PEP 1 to support this.)
There are probably some other parts needed too, e.g. guidelines as to when a PEP is considered ripe for copying to the peps repo (and scripts/bots to make repeated copies easy -- e.g. there could be a bot that copies a PEP from that PEP's own repo to the peps repo each time a commit is made to the master branch in its own repo). There could also be guidelines to ensure a PEP is in a fairly non-controversial state (probably using the IETF's motto "rough consensus and working code") before being considered for approval. There's definitely some time when a PEP has an assigned number but is still controversial -- during that state debate on python-dev should be strictly redirected to the PEP's own repo.
For some PEPs it may make sense to assign a senior reviewer who decides what's considered non-controversial.
We can borrow more from the IETF process for RFCs: https://www.rfc-editor.org/pubprocess/
--Guido
PS. Carol: Jupyter's process looks great! I just don't have the guts to propose any serious changes to the physical logistics of publishing PEPs, since changes to the structure of the peps repo are so hard. We still haven't converted all PEPs to .rst format, despite efforts by Mariatta and others, and attempts to move all PEPs to a subdirectory have also failed, due to perpetual lack of resources to complete the task (and e.g. the need to update scripts on python.org whenever the peps repo structure changes).
-- Ivan
On 18 May 2018 at 18:25, Guido van Rossum <guido@python.org> wrote:
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.
PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).
Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.
Thoughts? (We can dogfood this proposal too, if there's interest. :-)
-- --Guido van Rossum (python.org/~guido)
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/
-- --Guido van Rossum (python.org/~guido)
Hi,
Note that some PEPs are, still, mostly uncontroversial (PEP 574 is an example).
I agree with Nathaniel : PEP 572 is the poster child for lengthy, heated discussions. I'm still surprised you thought it was a good idea to discuss this. Perhaps it we tried to discourage syntax change and/or builtin change PEPs a little more we'd have less heated PEPs :-)
It would be *very* interesting if someone was willing to do some stats on PEPs over time: e.g. number of PEPs discussed every year, discussion length, number of discusssion participants. I actually expect overall PEP activity to have gone down since the 2000s.
Le 19/05/2018 à 01:41, Guido van Rossum a écrit :
I want to completely avoid discussion on python-dev. This probably means we should never post the full text of the PEP there. (We may have to amend PEP 1 to support this.)
Are you saying PEPs wouldn't even be *validated* by python-dev? If so, it's not a mere change to focus discussions, it's also a change in governance.
And while we may decide to change this piece of the governance model, the replacement process should IMO be something a little less vague than « discussion happens on Github with whoever happens to be interested or available ». Sorry if this is misrepresenting your position.
Regards
Antoine.
There are probably some other parts needed too, e.g. guidelines as to when a PEP is considered ripe for copying to the peps repo (and scripts/bots to make repeated copies easy -- e.g. there could be a bot that copies a PEP from that PEP's own repo to the peps repo each time a commit is made to the master branch in its own repo). There could also be guidelines to ensure a PEP is in a fairly non-controversial state (probably using the IETF's motto "rough consensus and working code") before being considered for approval. There's definitely some time when a PEP has an assigned number but is still controversial -- during that state debate on python-dev should be strictly redirected to the PEP's own repo.
For some PEPs it may make sense to assign a senior reviewer who decides what's considered non-controversial.
We can borrow more from the IETF process for RFCs: https://www.rfc-editor.org/pubprocess/
--Guido
PS. Carol: Jupyter's process looks great! I just don't have the guts to propose any serious changes to the physical logistics of publishing PEPs, since changes to the structure of the peps repo are so hard. We still haven't converted all PEPs to .rst format, despite efforts by Mariatta and others, and attempts to move all PEPs to a subdirectory have also failed, due to perpetual lack of resources to complete the task (and e.g. the need to update scripts on python.org <http://python.org> whenever the peps repo structure changes).
Hi,
2018-05-19 7:45 GMT+02:00 Antoine Pitrou <antoine@python.org>:
It would be *very* interesting if someone was willing to do some stats on PEPs over time: e.g. number of PEPs discussed every year, discussion length, number of discusssion participants. I actually expect overall PEP activity to have gone down since the 2000s.
I counted the number of emails per PEP (sent to python-dev or python-ideas) on the period Jan 2017 - April 2018: https://mail.python.org/pipermail/python-committers/2018-April/005310.html
My script: https://github.com/vstinner/misc/blob/master/python/parse_mailman_mbox_peps....
I downloaded "[ Gzip'd Text 227 KB ]" links from https://mail.python.org/pipermail/python-dev/ and https://mail.python.org/pipermail/python-ideas/ and then uncompressed them.
Victor
On May 18, 2018, at 3:25 PM, Guido van Rossum <guido@python.org <mailto:guido@python.org>> wrote:
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
We have something similar for Project Jupyter. We have a jupyter-incubator org for third party projects that may someday be accepted into the Jupyter core. One repo in particular, https://github.com/jupyter-incubator/proposals <https://github.com/jupyter-incubator/proposals>, keeps track of all the currently active proposals with links out to their repos, if not hosted within the incubator org.
This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.
PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).
Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.
This makes sense - one repo per proposed PEP as PRs can be used to help iterate the wording and issues can focus on specific subtopics. Having one repo that acts as a landing page for all of the in-progress PEPs would help folks keep track of where an in-progress PEP is located.
Thoughts? (We can dogfood this proposal too, if there's interest. :-)
-- --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
python-committers mailing list python-committers@python.org <mailto:python-committers@python.org> https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Fri, May 18, 2018 at 3:28 PM Guido van Rossum <guido@python.org> wrote:
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.
overall I think this idea has merit.
flaws? People who haven't yet given attention to the PEP over in its own world are likely to spawn the same threads on -ideas or -dev when the PEP is introduced there.
So long as something is public, there will always be outsiders. It also seems like using a forum such as a repository full of PRs threads can lose the discussion history as PRs are not a mailing list archive and can disappear at the whim of the corporation hosting them. But do we care about that? In theory all arguments and alternatives for/against are _supposed_ to be captured into the PEP doc itself before it is accepted.
I do like the ability to have a technical code discussion in markdown as PRs allow vs email. But if there are 100 people chiming in, I doubt this would make anything any easier to follow.
PEP authors may also choose to use a different repo hosting site, e.g.
Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).
Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.
It sounds like your primary goals here are (a) to avoid PEP discussions on the -dev and -ideas mailing lists and (b) to have a central place for all discussions spawned from a specific PEP instead of trying to piece together 18 centithreads with varying subjects from python-* list archives.
I think (a) would happen at the start, and (b) would be true in this scenario so it is probably worth a try.
I do expect (a) to overflow to the mailing list anyways at times. But this would give us the opportunity to redirect that away from the list. It should still be better than the common mailing list free for all we have today. It seems a bit more like a "working group" system. (which is what Carol's description of Jupyter incubator reminds me of)
*repos* where PEP discussions take place could optionally be CPython forks with an example implementation to eventually be used to construct the ultimate PRs adding it if the PEP is accepted.
Thoughts? (We can dogfood this proposal too, if there's interest. :-)
I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.
-gps
On 18 May 2018 at 19:46, Gregory P. Smith <greg@krypto.org> wrote:
I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.
Can few related PEPs share the same repository? For example, I want to start writing three PEPs about extensions to PEP 484 type system: literal types, final/const qualifier, and integer generics (simple dependent types). They all are tightly connected (but I don't want a single mega-PEP), can I put these three in the same repo?
-- Ivan
Yes, you can do that.
On Fri, May 18, 2018, 16:51 Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 18 May 2018 at 19:46, Gregory P. Smith <greg@krypto.org> wrote:
I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.
Can few related PEPs share the same repository? For example, I want to start writing three PEPs about extensions to PEP 484 type system: literal types, final/const qualifier, and integer generics (simple dependent types). They all are tightly connected (but I don't want a single mega-PEP), can I put these three in the same repo?
-- Ivan
On Fri, May 18, 2018 at 4:51 PM, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 18 May 2018 at 19:46, Gregory P. Smith <greg@krypto.org> wrote:
I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.
Can few related PEPs share the same repository? For example, I want to start writing three PEPs about extensions to PEP 484 type system: literal types, final/const qualifier, and integer generics (simple dependent types). They all are tightly connected (but I don't want a single mega-PEP), can I put these three in the same repo?
Another common pattern we see with trickier PEPs is the creation of multiple competing proposals. This strikes me as healthy and something we want to encourage. Maybe these should also go in the same repo by default?
This is also a case where assigning PEP numbers earlier rather than later seems useful. Unambiguously referring to PEP 521, PEP 550, PEP 567, and PEP 568 would be difficult without the numbers :-).
-n
-- Nathaniel J. Smith -- https://vorpus.org
On Fri, May 18, 2018 at 3:25 PM, Guido van Rossum <guido@python.org> wrote:
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
PEP 572 seems like something of a perfect storm... it's simultaneously a bikeshed and a nuclear power plant [1], and also the rare proposal that you like but that significant numbers of core devs find deeply objectionable; any one of these would tend to produce a lot of email, and then the combination is something else again. Is this proposal mostly responding to that, or something that you've been thinking for a while?
[1] For those unfamiliar with this example: https://en.wikipedia.org/wiki/Law_of_triviality#Examples
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
To some extent this has been happening informally for a while. Just off the top of my head:
PEP 465: https://github.com/numpy/numpy/pull/4351 PEP 543: https://github.com/python-hyper/pep543/issues/2#issuecomment-309199376 PEP 513: https://github.com/pypa/manylinux#the-pep-itself A repo full of packaging PEPs: https://github.com/pypa/interoperability-peps
For a lot of us these days, putting a document in a repo is just the default way to work on it (and get feedback, etc.).
Managing the relationship between these repos and the main peps repo is currently pretty awkward. They tend to get out of sync in both directions – people make edits directly to the PEP repo – plus in general some pieces of information are in one place and some in another, there's no link between them, the original repo can get misplaced over time...
This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.
PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).
I'd be somewhat tempted to require people to use Github and to move the repo into the python/ organization when it gets a number, so that there's one canonical place to look for the history and we have some control over its lifecycle.
More radical idea: what if the PEPs index just linked to the Github rendering of each file? That's always going to be up to date, it comes with a link to the issue tracker at the top, it has a nice "Edit" button if someone wants to submit small fixes as a PR...
Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.
Thoughts? (We can dogfood this proposal too, if there's interest. :-)
Rust's RFC process is a bit different, but may be of interest: https://github.com/rust-lang/rfcs
One thing people might worry about is missing out on discussion they're interested in – there wouldn't be one central place to subscribe to see discussions. Rust's concept of a "final comment period" is a nice way to manage this.
-n
-- Nathaniel J. Smith -- https://vorpus.org
19.05.18 01:25, Guido van Rossum пише:
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.
PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).
What will happen with these repos after accepting or rejecting corresponding PEPs?
On 18 May 2018 at 23:25, Guido van Rossum <guido@python.org> wrote:
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
It's not scalable, certainly. But it's still (IMO) fine for all but the larger PEPs - the trick is spotting which PEPs are "too big" :-)
I'm not sure that the issue with python-ideas is that bad. That list is *designed* for incomplete and unformed proposals, and so long threads are common (and accepted) on there. People on python-ideas are used to skimming or ignoring/blocking threads they aren't interested in. So by the time things are ready to go to python-dev (or wherever) there's a good sense of whether the PEP is likely to be controversial. I'd suggest that this is the point when the decision to go to python-dev or github could be made.
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.
PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).
I would prefer that PEP repos remain on github, and that once the PEP is finalised (accepted, rejected, whatever) moved under the CPython organisation (the whole repo, issue tracker, history, everything) so that the history of discussion isn't lost. Current PEP discussions are retained on the list archives, and I think the discussion history is valuable (even if a lot of it ends up being noise at the moment). I'd rather not have to maintain extra accounts for bitbucket or gitlab, and learn how notifications and tracking work on those platforms. A common interface is important. Adding barriers to contribution does filter out casual commenters, but I'm sure we don't want to be seen to be deliberately making it *hard* for outsiders to get involved.
Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.
Thoughts? (We can dogfood this proposal too, if there's interest. :-)
(Later)
I want to completely avoid discussion on python-dev. This probably means we should never post the full text of the PEP there. (We may have to amend PEP 1 to support this.)
Avoiding *discussion* is probably OK. But regular summaries of progress would, I think, be critical. Otherwise python-dev is essentially cut out of the loop, and this becomes more of a change in governance, as Antoine mentioned.
I'm not quite sure what your intention was, but I'd like to see a series of announcements on python-dev for a PEP which is being discussed offline:
- An initial announcement of the creation of the PEP repo, giving a summary of the PEP (the abstract from the proposal), and a pointer to where interested parties should go to participate in discussions.
- Progress announcements, maybe once a month, repeating the summary and adding a "what has changed" summary.
- Preliminary announcement of the decision on the PEP (a "release candidate" if you like) stating that the decision has been made, what that decision is, and that it will be officially announced in (say) a week.
- Final announcement, giving the summary, the decision, and pointers to the final PEP text and the discussion (now hosted permanently under the cpython org on github).
The point of the "release candidate" stage is the same as the RC for a release - last chance to raise showstopper problems, plus announcing the start of the "release" work (moving the repo, specifically).
I'm not that wedded to the RC announcement, but it will avoid the final decision coming as a complete surprise to python-dev. As a data point, I currently have no idea whether the discussions on the binding expression PEP are still just rumbling on, or whether a decision is imminent. Of course, if the progress announcements are sufficiently good, the RC may not be necessary (it would effectively just be the last in a series of summaries).
Paul
On Fri, May 18, 2018 at 03:25:37PM -0700, Guido van Rossum wrote:
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
Do we have a reason to think that moving to Github will help discussions scale better?
At the moment, a controversial PEP generates a flood of email on Python-Ideas and a flood of email on Python-Dev. If all we do is add a third flood of posts on Github, that's not much of a win :-)
Aside from the nuisance value of having to sign up to yet another forum (Github as well as a mailing list), which isn't that big a nuisance given that these days most people have a Github account, I'm not too clear on the benefit of this.
This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.
Isn't that a bit of a contradiction?
- moving to GitHub doesn't attract outsiders
- while making it easier for outsiders
-- Steve
Hi,
2018-05-19 0:25 GMT+02:00 Guido van Rossum <guido@python.org>:
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
Which problem do you want to solve? Reduce the number of emails per month on python-ideas and python-dev? Reduce the number of messages per PEP?
If the number of messages per PEP is the problem, I don't see how replacing emails with GitHub would help. GitHub allows to add comments on:
- commits
- issues
- pull requests
Anyone can open new issues and new pull requests. It might be harder to follow discussions if they are occur at different parts of a single repository.
I guess that your motivation is to prevent another PEP 572 mess.
IMHO the discussions on the PEP 572 became a mess because nobody wanted to moderate the discussion. I asked on python-committers how to calm down the discussion, but no action has been taken and the flow of emails didn't stop.
A moderator can try to summarize the discussion or can ask to stop discussing the PEP until the PEP is updated. For the PEP 572, it seems like a few issues have been spotted in the PEP, but I don't recall an email saying "these points must be fixed in the PEP, please wait until the PEP is updated".
Will it be simpler to moderate discussions on GitHub? Or do you expect that less people will go to GitHub, than on python-dev/python-ideas, to discuss?
I like emails because it's plain text, it's easily readable on all devices, there are archives (controlled by Python) which are readable online, etc. I also like threads in emails. It's easy to see if I missed messages. On GitHub, there is no markers of unread messages, only notifications (well, there are also notifications with messages ;-)).
IMHO a PEP should summarize the most important discussed points. Otherwise, each time that someone who don't know the PEP will read it, the same discussion will restart from scratch. And I don't think that PEP 572 made that.
Thoughts? (We can dogfood this proposal too, if there's interest. :-)
Apart the PEP 572, I recalled that I have been annoyed by the fspath protocol before a PEP has been written. I also recall that the discussions stopped when I asked to wait until Brett (and someone else, sorry I forgot) writes a PEP. For other PEPs, I think that the volume of emails is acceptable.
I also like the idea of getting all PEPs in python-dev because it's easier for me to be aware of currently discussed PEPs, even if I don't read the discussions.
But it seems like I'm getting old and resist to the shiny new GitHub which will solve all our issues ;-)
Victor
On May 22, 2018, at 5:50 PM, Victor Stinner <vstinner@redhat.com> wrote:
IMHO the discussions on the PEP 572 became a mess because nobody wanted to moderate the discussion. I asked on python-committers how to calm down the discussion, but no action has been taken and the flow of emails didn't stop.
FWIW, I think this is a key thing— Mailing lists are not easily moderatable. There’s no way to pause discussion, redirect, etc besides generating *more* email (and the tooling to do it is lackluster, it’s pretty much just asking people to do something, and hope everyone complies). Fracturing the discussion amongst multiple repos is one way of handling that, another option is better tooling for moderation.
2018-05-22 23:58 GMT+02:00 Donald Stufft <donald@stufft.io>:
FWIW, I think this is a key thing— Mailing lists are not easily moderatable. There’s no way to pause discussion, redirect, etc besides generating *more* email (and the tooling to do it is lackluster, it’s pretty much just asking people to do something, and hope everyone complies). Fracturing the discussion amongst multiple repos is one way of handling that, another option is better tooling for moderation.
Another solution is to use Special Interest Group (SIG) mailing lists to discuss PEPs.
distutils-sig accepted many PEPs which were never posted to python-dev. Someone told me that PEPs are not posted to python-dev to avoid restarting discussions from scratch ;-) I have been told when I asked why TOML has been chosen instead of YAML for a PEP ;-) It was maybe the PEP 518, I don't recall.
Do we need a new more specific mailing lists to discuss PEPs changing the Python language?
Or a generic noisy-pep mailing lists for PEPs with high traffic? :-)
Victor
On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote:
On May 22, 2018, at 5:50 PM, Victor Stinner <vstinner@redhat.com> wrote:
IMHO the discussions on the PEP 572 became a mess because nobody wanted to moderate the discussion. I asked on python-committers how to calm down the discussion, but no action has been taken and the flow of emails didn't stop.
FWIW, I think this is a key thing— Mailing lists are not easily moderatable.
*Unmoderated* mailing lists are not easily moderated.
There’s no way to pause discussion, redirect, etc
Does Github allow us to do these things? Not a rhetorical question.
besides generating *more* email (and the tooling to do it is lackluster, it’s pretty much just asking people to do something, and hope everyone complies). Fracturing the discussion amongst multiple repos is one way of handling that, another option is better tooling for moderation.
It is one thing to identify a problem, another thing to state that something is a solution to that problem, and a completely different thing to actually solve the problem. How does fracturing the discussion help?
One of the problems with PEP 372 was that the discussion was fractured across multiple threads on two mailing lists, leading to the same points being raised over and over again. (I think Chris was premature in taking it to Python-Dev while it was still be actively argued on Python-Ideas.)
It seems to me that "fracturing the discussion amongst multiple repos" will have the same effect: increase the total volume, not decrease it, as well as increasing the chances that salient points will be missed. Am I wrong?
As for better tooling for moderation, I asked earlier in this thread how moving to Github will help. What is this tooling?
I think the problem with PEP 572 was that it was a perfect storm of a number of factors:
it relates to a feature simple enough that everyone has an opinion;
the statement/expression divide ("assignment is NOT an expression, and that's a feature!") has been a point of distinction between Python and "the competition" for 20+ years;
hence some very strong feelings;
legitimate concerns over complexity and the assign/equals bug;
bike-shedding and arguments over syntax;
distraction over unrelated proposal to change the way scoping works inside classes;
lots of newcomers to the community.
I count at least three discussions about this on Reddit:
https://redd.it/8fpv3f https://redd.it/8fokpw https://redd.it/8ex72p
Most PEPs don't get even one.
Trialling Github with a simpler, less emotional and bike-sheddy PEP may not demonstrate how well the process works when everyone and their pet cat has an opinion.
-- Steve
On 05/22/2018 06:06 PM, Steven D'Aprano wrote:
On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote:
On May 22, 2018, at 5:50 PM, Victor Stinner wrote:
One of the problems with PEP 572 was that the discussion was fractured across multiple threads on two mailing lists, leading to the same points being raised over and over again. (I think Chris was premature in taking it to Python-Dev while it was still be actively argued on Python-Ideas.)
I have to take the blame for that. It looked to me like the PEP was as good as it was going to get on -ideas so I encouraged Chris to move it over to -dev.
-- ~Ethan~
On Tue, 22 May 2018 at 18:07 Steven D'Aprano <steve@pearwood.info> wrote:
On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote:
On May 22, 2018, at 5:50 PM, Victor Stinner <vstinner@redhat.com>
wrote:
IMHO the discussions on the PEP 572 became a mess because nobody wanted to moderate the discussion. I asked on python-committers how to calm down the discussion, but no action has been taken and the flow of emails didn't stop.
FWIW, I think this is a key thing— Mailing lists are not easily moderatable.
*Unmoderated* mailing lists are not easily moderated.
There’s no way to pause discussion, redirect, etc
Does Github allow us to do these things? Not a rhetorical question.
Locking/pausing issues and PRs yes (both temporarily and permanently), redirection not specifically beyond cross-referencing to another issue/PR in a comment.
-Brett
besides generating *more* email (and the tooling to do it is lackluster, it’s pretty much just asking people to do something, and hope everyone complies). Fracturing the discussion amongst multiple repos is one way of handling that, another option is better tooling for moderation.
It is one thing to identify a problem, another thing to state that something is a solution to that problem, and a completely different thing to actually solve the problem. How does fracturing the discussion help?
One of the problems with PEP 372 was that the discussion was fractured across multiple threads on two mailing lists, leading to the same points being raised over and over again. (I think Chris was premature in taking it to Python-Dev while it was still be actively argued on Python-Ideas.)
It seems to me that "fracturing the discussion amongst multiple repos" will have the same effect: increase the total volume, not decrease it, as well as increasing the chances that salient points will be missed. Am I wrong?
As for better tooling for moderation, I asked earlier in this thread how moving to Github will help. What is this tooling?
I think the problem with PEP 572 was that it was a perfect storm of a number of factors:
it relates to a feature simple enough that everyone has an opinion;
the statement/expression divide ("assignment is NOT an expression, and that's a feature!") has been a point of distinction between Python and "the competition" for 20+ years;
hence some very strong feelings;
legitimate concerns over complexity and the assign/equals bug;
bike-shedding and arguments over syntax;
distraction over unrelated proposal to change the way scoping works inside classes;
lots of newcomers to the community.
I count at least three discussions about this on Reddit:
https://redd.it/8fpv3f https://redd.it/8fokpw https://redd.it/8ex72p
Most PEPs don't get even one.
Trialling Github with a simpler, less emotional and bike-sheddy PEP may not demonstrate how well the process works when everyone and their pet cat has an opinion.
-- Steve
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 Tue, May 22, 2018 at 2:50 PM, Victor Stinner <vstinner@redhat.com> wrote:
2018-05-19 0:25 GMT+02:00 Guido van Rossum <guido@python.org>:
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
Which problem do you want to solve? Reduce the number of emails per month on python-ideas and python-dev? Reduce the number of messages per PEP?
Both. The lists have gotten out of hand, and it's clear that many people don't bother to read much of the discussion before posting an outraged response to something they disagree with.
If the number of messages per PEP is the problem, I don't see how replacing emails with GitHub would help. GitHub allows to add comments on:
- commits
- issues
- pull requests
Anyone can open new issues and new pull requests. It might be harder to follow discussions if they are occur at different parts of a single repository.
That's why I propose one repo per new PEP (or small cluster of related PEPs). I agree that just having one PR per PEP in the peps repo would not be an improvement.
The single repo puts all related discussion together (all issues in that repo are about the same topic). This makes it easier for the PEP author to read all traffic related to their PEP without forcing them to read all of python-{ideas,dev}, while making it easier for others to create new threads (no worries that the PEP author won't see your comment). It also lets the PEP author effectively moderate the discussion (they can close issues and even delete off-topic messages). It also makes it possible for interested 3rd parties to read all traffic related to a repo (just subscribe to the repo).
I guess that your motivation is to prevent another PEP 572 mess.
IMHO the discussions on the PEP 572 became a mess because nobody wanted to moderate the discussion. I asked on python-committers how to calm down the discussion, but no action has been taken and the flow of emails didn't stop.
What action *can* you take on mailing lists like python-{ideas,dev}?
A moderator can try to summarize the discussion or can ask to stop discussing the PEP until the PEP is updated. For the PEP 572, it seems like a few issues have been spotted in the PEP, but I don't recall an email saying "these points must be fixed in the PEP, please wait until the PEP is updated".
Will it be simpler to moderate discussions on GitHub? Or do you expect that less people will go to GitHub, than on python-dev/python-ideas, to discuss?
GitHub has superior moderation abilities over our mailing lists, plus the volume per topic (PEP or cluster of PEPs) is lower than the entire volume of python-{ideas,dev}.
If it discourages drive-by comments by people not really invested in the discussion but eager to show off their opinions, well, that's just an added benefit.
I like emails because it's plain text, it's easily readable on all devices, there are archives (controlled by Python) which are readable online, etc. I also like threads in emails. It's easy to see if I missed messages. On GitHub, there is no markers of unread messages, only notifications (well, there are also notifications with messages ;-)).
Maybe you should learn more about how to use GitHub? I find the experience superior, and I routinely keep up with it on my phone.
IMHO a PEP should summarize the most important discussed points. Otherwise, each time that someone who don't know the PEP will read it, the same discussion will restart from scratch. And I don't think that PEP 572 made that.
That's an unreasonable requirement when the discussion gets out of hand like it got in that case. I hope to make it easier for the PEP author(s) to keep up in part so they will have an easier time summarizing (and won't be drawn into fruitless arguments as much by semi-troll comments).
Thoughts? (We can dogfood this proposal too, if there's interest. :-)
Apart the PEP 572, I recalled that I have been annoyed by the fspath protocol before a PEP has been written. I also recall that the discussions stopped when I asked to wait until Brett (and someone else, sorry I forgot) writes a PEP. For other PEPs, I think that the volume of emails is acceptable.
That was a long time ago. Note that the cluster around PEP 550 was #2 on your list, this was also fairly recent. I feel that traffic *in general* has been up (I routinely see threads on python-ideas now where I think "dumb idea" and mute the conversation).
I also like the idea of getting all PEPs in python-dev because it's easier for me to be aware of currently discussed PEPs, even if I don't read the discussions.
But it seems like I'm getting old and resist to the shiny new GitHub which will solve all our issues ;-)
To the contrary, *I* am getting old and I no longer have the energy to deal with mailing lists. Since most PEPs pass through my inbox, I hope I still have some say on how the discussion should be kept sane.
-- --Guido van Rossum (python.org/~guido)
On May 22, 2018, at 5:21 PM, Guido van Rossum <guido@python.org <mailto:guido@python.org>> wrote:
On Tue, May 22, 2018 at 2:50 PM, Victor Stinner <vstinner@redhat.com <mailto:vstinner@redhat.com>> wrote: 2018-05-19 0:25 GMT+02:00 Guido van Rossum <guido@python.org <mailto:guido@python.org>>:
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
Which problem do you want to solve? Reduce the number of emails per month on python-ideas and python-dev? Reduce the number of messages per PEP?
Both. The lists have gotten out of hand, and it's clear that many people don't bother to read much of the discussion before posting an outraged response to something they disagree with.
If the number of messages per PEP is the problem, I don't see how replacing emails with GitHub would help. GitHub allows to add comments on:
- commits
- issues
- pull requests
Anyone can open new issues and new pull requests. It might be harder to follow discussions if they are occur at different parts of a single repository.
That's why I propose one repo per new PEP (or small cluster of related PEPs). I agree that just having one PR per PEP in the peps repo would not be an improvement.
The single repo puts all related discussion together (all issues in that repo are about the same topic). This makes it easier for the PEP author to read all traffic related to their PEP without forcing them to read all of python-{ideas,dev}, while making it easier for others to create new threads (no worries that the PEP author won't see your comment). It also lets the PEP author effectively moderate the discussion (they can close issues and even delete off-topic messages). It also makes it possible for interested 3rd parties to read all traffic related to a repo (just subscribe to the repo).
I guess that your motivation is to prevent another PEP 572 mess.
IMHO the discussions on the PEP 572 became a mess because nobody wanted to moderate the discussion. I asked on python-committers how to calm down the discussion, but no action has been taken and the flow of emails didn't stop.
What action *can* you take on mailing lists like python-{ideas,dev}?
A moderator can try to summarize the discussion or can ask to stop discussing the PEP until the PEP is updated. For the PEP 572, it seems like a few issues have been spotted in the PEP, but I don't recall an email saying "these points must be fixed in the PEP, please wait until the PEP is updated".
Will it be simpler to moderate discussions on GitHub? Or do you expect that less people will go to GitHub, than on python-dev/python-ideas, to discuss?
GitHub has superior moderation abilities over our mailing lists, plus the volume per topic (PEP or cluster of PEPs) is lower than the entire volume of python-{ideas,dev}.
If it discourages drive-by comments by people not really invested in the discussion but eager to show off their opinions, well, that's just an added benefit.
I like emails because it's plain text, it's easily readable on all devices, there are archives (controlled by Python) which are readable online, etc. I also like threads in emails. It's easy to see if I missed messages. On GitHub, there is no markers of unread messages, only notifications (well, there are also notifications with messages ;-)).
Maybe you should learn more about how to use GitHub? I find the experience superior, and I routinely keep up with it on my phone.
IMHO a PEP should summarize the most important discussed points. Otherwise, each time that someone who don't know the PEP will read it, the same discussion will restart from scratch. And I don't think that PEP 572 made that.
That's an unreasonable requirement when the discussion gets out of hand like it got in that case. I hope to make it easier for the PEP author(s) to keep up in part so they will have an easier time summarizing (and won't be drawn into fruitless arguments as much by semi-troll comments).
Thoughts? (We can dogfood this proposal too, if there's interest. :-)
Apart the PEP 572, I recalled that I have been annoyed by the fspath protocol before a PEP has been written. I also recall that the discussions stopped when I asked to wait until Brett (and someone else, sorry I forgot) writes a PEP. For other PEPs, I think that the volume of emails is acceptable.
That was a long time ago. Note that the cluster around PEP 550 was #2 on your list, this was also fairly recent. I feel that traffic *in general* has been up (I routinely see threads on python-ideas now where I think "dumb idea" and mute the conversation).
I also like the idea of getting all PEPs in python-dev because it's easier for me to be aware of currently discussed PEPs, even if I don't read the discussions.
But it seems like I'm getting old and resist to the shiny new GitHub which will solve all our issues ;-)
To the contrary, *I* am getting old and I no longer have the energy to deal with mailing lists. Since most PEPs pass through my inbox, I hope I still have some say on how the discussion should be kept sane.
-- --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
python-committers mailing list python-committers@python.org <mailto:python-committers@python.org> https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
FWIW, I'm going to throw out some negotiation tips since most of what is happening before a PEP is approved or rejected is negotiation of some form. Ideally, I would like to add these to the dev guide in a checklist section for Feedback on PEPs. These are all research driven from Harvard.
One-text principle (All parties work from the same document.) Setting ground rules for feedback on the text such as:
What is wrong with this draft as it is presented now?
Do you have important interests that this draft does not adequately address? Which ones? Why are they important?
What else seems wrong or is missing from the draft? Why are these things important?
Do you have other ideas for improvement? What are your reasons for suggesting these items? What key unmet interests do they address?
Do you have other ideas about how conflicting interests can be creatively and fairly resolved?
Understanding why you would like this particular interest met, but given that it has become clear that it is in direct conflict with other's interests, why should meeting your interest take priority over meeting theirs? What standards or fair process might we apply to deciding this?
Keeping emotions from boiling over
- Focus on your physical reaction.
- Listen to what your counterpart is saying
- Show you have heard them
- Show some empathy.
- Find out more.
- Take a break.
It seems like the PEP 572 discussions restarted on python-dev mailing list with more than 100 emails in one week.
Stupid idea: we created a mailing list just to fix os.random(): PEP 522 and PEP 524, whereas these discussions were not the ones with the most emails. Why not creating a new pep572 mailing list for the ones who don't want to follow PEP 572 discussions?
A dedicated mailing list may help to discuss subtopics by opening new threads.
*Maybe* discussions would be more constructive on a dedicated mailing list with less traffic and narrower audience?
Victor
2018-05-19 0:25 GMT+02:00 Guido van Rossum <guido@python.org>:
Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-)
I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes.
This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion.
PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo).
Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic.
Thoughts? (We can dogfood this proposal too, if there's interest. :-)
-- --Guido van Rossum (python.org/~guido)
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/
Le 28/06/2018 à 13:04, Victor Stinner a écrit :
It seems like the PEP 572 discussions restarted on python-dev mailing list with more than 100 emails in one week.
Stupid idea: we created a mailing list just to fix os.random(): PEP 522 and PEP 524, whereas these discussions were not the ones with the most emails. Why not creating a new pep572 mailing list for the ones who don't want to follow PEP 572 discussions?
PEP 572 is a language-wide change. Presumably those who don't want to follow discussions will still want to give their opinion (or informal vote) at the end. Which will give rise to other discussions...
What strikes me is that we have such long-lasting and intense discussion about a feature which, whether approved or not, will not significantly change Python's popularity or appeal or ability to solve real-world problems.
Perhaps this is a case where « Nature abhors a vacuum » : we're getting focussed on whatever comes up to fill the narrative of Python's evolution.
Regards
Antoine.
Sorry to bring up this old topic.
I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) Are we all still content with posting to python-dev? I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new #pep581 stream. Will that be ok?
Mariatta
On Thu, Jun 28, 2018 at 4:34 AM Antoine Pitrou <antoine@python.org> wrote:
Le 28/06/2018 à 13:04, Victor Stinner a écrit :
It seems like the PEP 572 discussions restarted on python-dev mailing list with more than 100 emails in one week.
Stupid idea: we created a mailing list just to fix os.random(): PEP 522 and PEP 524, whereas these discussions were not the ones with the most emails. Why not creating a new pep572 mailing list for the ones who don't want to follow PEP 572 discussions?
PEP 572 is a language-wide change. Presumably those who don't want to follow discussions will still want to give their opinion (or informal vote) at the end. Which will give rise to other discussions...
What strikes me is that we have such long-lasting and intense discussion about a feature which, whether approved or not, will not significantly change Python's popularity or appeal or ability to solve real-world problems.
Perhaps this is a case where « Nature abhors a vacuum » : we're getting focussed on whatever comes up to fill the narrative of Python's evolution.
Regards
Antoine.
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 07/11/2018 09:25 AM, Mariatta Wijaya wrote:
Sorry to bring up this old topic.
I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) Are we all still content with posting to python-dev? I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new #pep581 stream. Will that be ok?
I think this will be a good test of Zulip, as well as incentive for folks to join.
-- ~Ethan~
On Wed, 11 Jul 2018 at 10:31 Ethan Furman <ethan@stoneleaf.us> wrote:
On 07/11/2018 09:25 AM, Mariatta Wijaya wrote:
Sorry to bring up this old topic.
I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) Are we all still content with posting to python-dev? I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new #pep581 stream. Will that be ok?
I think this will be a good test of Zulip, as well as incentive for folks to join.
Fine by me as well since we won't know if it will work until we try it. :)
I like the Zulip idea, though it'll be hard to get permalinks to past discussions.
Also, before going to python-dev it should probably be battle-tested in python-ideas (PEP 572 wasn't ready for python-dev when it was moved there, and I'm still recovering from the resulting brawl).
On Wed, Jul 11, 2018 at 10:31 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 07/11/2018 09:25 AM, Mariatta Wijaya wrote:
Sorry to bring up this old topic.
I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) Are we all still content with posting to python-dev? I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new #pep581 stream. Will that be ok?
I think this will be a good test of Zulip, as well as incentive for folks to join.
-- ~Ethan~
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/
-- --Guido van Rossum (python.org/~guido)
For permalink in zulip, the link from "Copy link to conversation" seems to be sufficient. I've created a stream ( https://python.zulipchat.com/#narrow/stream/130206-.23pep581/subject/hello/n...) but it now has double ## 😅 and it seems I can't rename it to remove the extra "#"
I've been waiting for the "excitement" surrounding PEP 572 to cool down before I want to merge PEP 581 (https://github.com/python/peps/pull/681/)
I was hoping to bypass python-ideas since we've discussed at Python Language Summit :) but if really needed I can start a thread there.
Mariatta
On Wed, Jul 11, 2018 at 10:38 AM Guido van Rossum <guido@python.org> wrote:
I like the Zulip idea, though it'll be hard to get permalinks to past discussions.
Also, before going to python-dev it should probably be battle-tested in python-ideas (PEP 572 wasn't ready for python-dev when it was moved there, and I'm still recovering from the resulting brawl).
On Wed, Jul 11, 2018 at 10:31 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 07/11/2018 09:25 AM, Mariatta Wijaya wrote:
Sorry to bring up this old topic.
I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) Are we all still content with posting to python-dev? I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new #pep581 stream. Will that be ok?
I think this will be a good test of Zulip, as well as incentive for folks to join.
-- ~Ethan~
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/
-- --Guido van Rossum (python.org/~guido)
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/
I just renamed the stream so there's now just a single #. :)
On Wed, 11 Jul 2018 at 11:22 Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
For permalink in zulip, the link from "Copy link to conversation" seems to be sufficient. I've created a stream ( https://python.zulipchat.com/#narrow/stream/130206-.23pep581/subject/hello/n...) but it now has double ## 😅 and it seems I can't rename it to remove the extra "#"
I've been waiting for the "excitement" surrounding PEP 572 to cool down before I want to merge PEP 581 (https://github.com/python/peps/pull/681/)
I was hoping to bypass python-ideas since we've discussed at Python Language Summit :) but if really needed I can start a thread there.
Mariatta
On Wed, Jul 11, 2018 at 10:38 AM Guido van Rossum <guido@python.org> wrote:
I like the Zulip idea, though it'll be hard to get permalinks to past discussions.
Also, before going to python-dev it should probably be battle-tested in python-ideas (PEP 572 wasn't ready for python-dev when it was moved there, and I'm still recovering from the resulting brawl).
On Wed, Jul 11, 2018 at 10:31 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 07/11/2018 09:25 AM, Mariatta Wijaya wrote:
Sorry to bring up this old topic.
I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) Are we all still content with posting to python-dev? I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new #pep581 stream. Will that be ok?
I think this will be a good test of Zulip, as well as incentive for folks to join.
-- ~Ethan~
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/
-- --Guido van Rossum (python.org/~guido)
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/
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, Jul 11, 2018 at 11:22 AM, Mariatta Wijaya <mariatta.wijaya@gmail.com
wrote:
For permalink in zulip, the link from "Copy link to conversation" seems to be sufficient. I've created a stream (https://python.zulipchat.com/ #narrow/stream/130206-.23pep581/subject/hello/near/129486993) but it now has double ## 😅 and it seems I can't rename it to remove the extra "#"
I've been waiting for the "excitement" surrounding PEP 572 to cool down before I want to merge PEP 581 (https://github.com/python/peps/pull/681/)
I'm posting the acceptance later today.
I was hoping to bypass python-ideas since we've discussed at Python Language Summit :) but if really needed I can start a thread there.
From my reading of the summit, most people were okay with exploring this, but many had specific issues they thought needed to be researched and addressed in the PEP. And many core devs (the majority, actually, depending on how you count :-) were not at the summit. I guess since it's mostly the core devs that need to be convinced, announcing the Zulip channel here is good enough, unless we hear from people for whom Zulip doesn't work at all. So if you don't want to go to python-ideas, you have my blessing.
Mariatta
On Wed, Jul 11, 2018 at 10:38 AM Guido van Rossum <guido@python.org> wrote:
I like the Zulip idea, though it'll be hard to get permalinks to past discussions.
Also, before going to python-dev it should probably be battle-tested in python-ideas (PEP 572 wasn't ready for python-dev when it was moved there, and I'm still recovering from the resulting brawl).
On Wed, Jul 11, 2018 at 10:31 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 07/11/2018 09:25 AM, Mariatta Wijaya wrote:
Sorry to bring up this old topic.
I'm trying to decide how to handle discussions for PEP 581, and I'm open to try out new things :) Are we all still content with posting to python-dev? I was thinking in addition to a thread in python-dev, I want to allow discussions to take place in zulip, under a new #pep581 stream. Will that be ok?
I think this will be a good test of Zulip, as well as incentive for folks to join.
-- ~Ethan~
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/
-- --Guido van Rossum (python.org/~guido)
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/
-- --Guido van Rossum (python.org/~guido)
participants (14)
-
Antoine Pitrou -
Brett Cannon -
Carol Willing -
Donald Stufft -
Ethan Furman -
Gregory P. Smith -
Guido van Rossum -
Ivan Levkivskyi -
Mariatta Wijaya -
Nathaniel Smith -
Paul Moore -
Serhiy Storchaka -
Steven D'Aprano -
Victor Stinner