Re: [python-committers] A different way to focus discussions

[Guido van Rossum]

On Wed, Jul 11, 2018 at 11:22 AM, Mariatta Wijaya  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 
> 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 
>> 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)
___
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/

Re: [python-committers] A different way to focus discussions

[Brett Cannon]

I just renamed the stream so there's now just a single #. :)

On Wed, 11 Jul 2018 at 11:22 Mariatta Wijaya 
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 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 
> 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 
>> 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/
>
___
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/

Re: [python-committers] A different way to focus discussions

[Mariatta Wijaya]

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

Re: [python-committers] A different way to focus discussions

[Guido van Rossum]

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

Re: [python-committers] A different way to focus discussions

[Brett Cannon]

On Wed, 11 Jul 2018 at 10:31 Ethan Furman  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. :)
___
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/

Re: [python-committers] A different way to focus discussions

[Ethan Furman]

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/

Re: [python-committers] A different way to focus discussions

[Mariatta Wijaya]

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  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/
>
___
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/

Re: [python-committers] A different way to focus discussions

[Antoine Pitrou]

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/

Re: [python-committers] A different way to focus discussions

[Victor Stinner]

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 :
> 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/
>
___
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/

Re: [python-committers] A different way to focus discussions

[Donald Stufft]

> On May 24, 2018, at 2:05 PM, Antoine Pitrou  wrote:
> 
> 
> Le 24/05/2018 à 20:02, Brett Cannon a écrit :
>>> Just trying to
>>> understand how Discourse would be different enough to solve the issue
>>> you're having.
>> 
>>Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
>>really work for PEP discussions, IMO.  That's why I asked about
>>Discourse.
>> 
>> Fair enough. Would you want a PEPs section and then some naming
>> convention per thread to denote which PEP a thread is about?
> 
> That could work.  I'm not acquainted with Discourse, are there subsections?


Yes, you can nest sections as deeply as you want, but the sections are 
typically static (I mean they can change over time, but making one per PEP 
would be a weird use of discourse).

___
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/

Re: [python-committers] A different way to focus discussions

[Antoine Pitrou]

Le 24/05/2018 à 20:02, Brett Cannon a écrit :
> > Just trying to
> > understand how Discourse would be different enough to solve the issue
> > you're having.
> 
> Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
> really work for PEP discussions, IMO.  That's why I asked about
> Discourse.
> 
> Fair enough. Would you want a PEPs section and then some naming
> convention per thread to denote which PEP a thread is about?

That could work.  I'm not acquainted with Discourse, are there subsections?
___
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/

Re: [python-committers] A different way to focus discussions

[Brett Cannon]

On Thu, 24 May 2018 at 10:45 Antoine Pitrou  wrote:

>
> Le 24/05/2018 à 18:54, Brett Cannon a écrit :
> >
> > I don't think Zulip works for structured discussion.  I also find it
> > slightly less usable than I expected.
> >
> > Why specifically? Do you still find IRC more usable?
>
> Um, no.  But I find Zulip's way of grouping discussions by day *then* by
> topic makes things a bit confusing and not very easy to follow.  It
> seems designed for people who log in every day.
>

Ah, you must be reading Zulip through "All Messages". I personally read
each topic individually by pressing "n" to navigate through each topic with
an unread message, otherwise I too lose too much context.


>
> > Just trying to
> > understand how Discourse would be different enough to solve the issue
> > you're having.
>
> Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
> really work for PEP discussions, IMO.  That's why I asked about Discourse.
>

Fair enough. Would you want a PEPs section and then some naming convention
per thread to denote which PEP a thread is about?
___
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/

Re: [python-committers] A different way to focus discussions

[Antoine Pitrou]

Le 24/05/2018 à 18:54, Brett Cannon a écrit :
> 
> I don't think Zulip works for structured discussion.  I also find it
> slightly less usable than I expected.
> 
> Why specifically? Do you still find IRC more usable?

Um, no.  But I find Zulip's way of grouping discussions by day *then* by
topic makes things a bit confusing and not very easy to follow.  It
seems designed for people who log in every day.

> Just trying to
> understand how Discourse would be different enough to solve the issue
> you're having.

Which issue exactly?  Zulip is decent as a chat system.  It wouldn't
really work for PEP discussions, IMO.  That's why I asked about Discourse.

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/

Re: [python-committers] A different way to focus discussions

[Brett Cannon]

On Tue, 22 May 2018 at 13:52 Barry Warsaw  wrote:

> On May 22, 2018, at 12:44, Guido van Rossum  wrote:
> >
> > Hm, what's the cost of those extra repos? As long as they have
> consistent names (e.g. pep-1234) they're easy to ignore right? Or does
> GitHub have a quota of repos per org?
>
> I think there is a quota for non-paying organizations, but I’m not sure.
> I was just thinking about clutter on https://github.com/python but maybe
> it won’t be so bad with…
>

I don't think there's a quota.

-Brett


>
> > I was thinking of a workflow where the pep author initially creates the
> repo under their own username and directs discussion there. Then when their
> PEP is accepted (or rejected!) they can donate their repo to the python
> org. I know such a thing is possible (we did it for the mypy and typeshed
> repos).
>
> … +1!
>
> > Ironically for me GitHub is less linear than email. It's easier to ask
> people to open a new issue than it is to ask them to start a new thread. So
> e.g. if a discussion starts about a survey of feature X in various
> languages, when it veers off into a tutorial for a specific language that
> could be a separate issue, and the meta-discussion on how the list of
> languages should be selected could be made another issue.
>
> I see what you’re saying.  Yes, that could work if the PEP author is
> really diligent about shunting detours into new issues.  I’ve just found
> that within PRs or issues, the linearity can be quite difficult to follow.
> (FWIW, IMHO, GitLab does better here, but that’s besides the point.)
>

You do realize you are very quickly volunteering to propose to write the
PEP for moving issues to GitLab, right? ;)


>
> > I think Mark Shannon volunteered PEP 576 (though so far he hasn't
> created a separate repo, he's just created a PR for the peps repo IIUC). I
> hope Nick will also volunteer PEP 577 for this.
>
> +1
>
> -Barry
> ___
> 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/

Re: [python-committers] A different way to focus discussions

[Brett Cannon]

On Tue, 22 May 2018 at 18:07 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:
> > >
> > > 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/
>
___
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/

Re: [python-committers] A different way to focus discussions

[Brett Cannon]

On Tue, 22 May 2018 at 13:10 Antoine Pitrou  wrote:

>
> Le 22/05/2018 à 22:06, Brett Cannon a écrit :
> >
> >
> > On Tue, 22 May 2018 at 12:07 Antoine Pitrou  > > wrote:
> >
> >
> > Le 22/05/2018 à 20:58, Barry Warsaw a écrit :
> > >
> > >> Thoughts? (We can dogfood this proposal too, if there's interest.
> :-)
> > >
> > > I don't know whether this will help focus rambling PEP
> > discussions.  I personally don't love the linearity of GH comments.
> > Threading is useful!
> >
> > What has become of the Discourse experiment?
> >
> >
> > A Discourse experiment was never started. If you mean Zulip it's still
> > going at python.zulipchat.com .
>
> I meant this, whatever it was: https://discuss.python.org/ :-)
>

Ah, that never went anywhere because it was just a short experiment that
the overload-sig did. If people wanted to do a serious experiment with it
then we can discuss it over on core-workflow.


>
> I don't think Zulip works for structured discussion.  I also find it
> slightly less usable than I expected.
>

Why specifically? Do you still find IRC more usable? Just trying to
understand how Discourse would be different enough to solve the issue
you're having.

-Brett


>
> 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/
>
___
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/

Re: [python-committers] A different way to focus discussions

[Ethan Furman]

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~
___
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/

Re: [python-committers] A different way to focus discussions

[Carol Willing]

> On May 22, 2018, at 5:21 PM, Guido van Rossum  > wrote:
> 
> On Tue, May 22, 2018 at 2:50 PM, Victor Stinner  > wrote:
> 2018-05-19 0:25 GMT+02:00 Guido van Rossum  >:
> > 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 

Re: [python-committers] A different way to focus discussions

[Steven D'Aprano]

On Tue, May 22, 2018 at 05:58:39PM -0400, Donald Stufft wrote:
> 
> > On May 22, 2018, at 5:50 PM, Victor Stinner  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
___
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/

Re: [python-committers] A different way to focus discussions

[Guido van Rossum]

On Tue, May 22, 2018 at 2:50 PM, Victor Stinner  wrote:

> 2018-05-19 0:25 GMT+02:00 Guido van Rossum :
> > 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 

Re: [python-committers] A different way to focus discussions

[Victor Stinner]

2018-05-22 23:58 GMT+02:00 Donald Stufft :
> 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
___
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/

Re: [python-committers] A different way to focus discussions

[Donald Stufft]

> On May 22, 2018, at 5:50 PM, Victor Stinner  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.___
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/

Re: [python-committers] A different way to focus discussions

[Victor Stinner]

Hi,

2018-05-19 0:25 GMT+02:00 Guido van Rossum :
> 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
___
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/

Re: [python-committers] A different way to focus discussions

[Barry Warsaw]

On May 22, 2018, at 12:44, Guido van Rossum  wrote:
> 
> Hm, what's the cost of those extra repos? As long as they have consistent 
> names (e.g. pep-1234) they're easy to ignore right? Or does GitHub have a 
> quota of repos per org?

I think there is a quota for non-paying organizations, but I’m not sure.  I was 
just thinking about clutter on https://github.com/python but maybe it won’t be 
so bad with…

> I was thinking of a workflow where the pep author initially creates the repo 
> under their own username and directs discussion there. Then when their PEP is 
> accepted (or rejected!) they can donate their repo to the python org. I know 
> such a thing is possible (we did it for the mypy and typeshed repos).

… +1!

> Ironically for me GitHub is less linear than email. It's easier to ask people 
> to open a new issue than it is to ask them to start a new thread. So e.g. if 
> a discussion starts about a survey of feature X in various languages, when it 
> veers off into a tutorial for a specific language that could be a separate 
> issue, and the meta-discussion on how the list of languages should be 
> selected could be made another issue.

I see what you’re saying.  Yes, that could work if the PEP author is really 
diligent about shunting detours into new issues.  I’ve just found that within 
PRs or issues, the linearity can be quite difficult to follow.  (FWIW, IMHO, 
GitLab does better here, but that’s besides the point.)

> I think Mark Shannon volunteered PEP 576 (though so far he hasn't created a 
> separate repo, he's just created a PR for the peps repo IIUC). I hope Nick 
> will also volunteer PEP 577 for this.

+1

-Barry


signature.asc
Description: Message signed with OpenPGP
___
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/

Re: [python-committers] A different way to focus discussions

[Brett Cannon]

On Tue, 22 May 2018 at 12:07 Antoine Pitrou  wrote:

>
> Le 22/05/2018 à 20:58, Barry Warsaw a écrit :
> >
> >> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
> >
> > I don't know whether this will help focus rambling PEP discussions.  I
> personally don't love the linearity of GH comments.  Threading is useful!
>
> What has become of the Discourse experiment?
>

A Discourse experiment was never started. If you mean Zulip it's still
going at python.zulipchat.com.


>
> 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/
>
___
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/

Re: [python-committers] A different way to focus discussions

[Victor Stinner]

Hi,

2018-05-19 7:45 GMT+02:00 Antoine Pitrou :
> 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.py

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
___
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/

Re: [python-committers] A different way to focus discussions

[Guido van Rossum]

On Tue, May 22, 2018 at 11:58 AM, Barry Warsaw  wrote:

> [I think my other response got dropped, so apologies for any duplicates]
>
> Guido van Rossum wrote:
> > 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.
>
> I don't think I'd want to see tons of new PEP repos under the current
> `python` organization.  Maybe we should create a new organization for this
> experiment?
>

Hm, what's the cost of those extra repos? As long as they have consistent
names (e.g. pep-1234) they're easy to ignore right? Or does GitHub have a
quota of repos per org?


> Also, since non-core devs can and do create PEPs, the permission
> management will be different than the normal repos.  Clearly the PEP
> authors should be owners of the individual repos, but they should probably
> also decide how merges happen, and who else can contribute to their repo.
>
> It also means that PEP editors probably have an additional responsibility
> to create the PEP repo.
>

I was thinking of a workflow where the pep author initially creates the
repo under their own username and directs discussion there. Then when their
PEP is accepted (or rejected!) they can donate their repo to the python
org. I know such a thing is possible (we did it for the mypy and typeshed
repos).


> PEP 1's Discussions-To header can probably be co-opted for the URL to the
> GH repo.  Right now, that field is described as an email address, but it
> would be appropriate IMHO to also allow a URL for discussions.
>

Sure.

> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
>
> I don't know whether this will help focus rambling PEP discussions.  I
> personally don't love the linearity of GH comments.  Threading is useful!
>

Ironically for me GitHub is less linear than email. It's easier to ask
people to open a new issue than it is to ask them to start a new thread. So
e.g. if a discussion starts about a survey of feature X in various
languages, when it veers off into a tutorial for a specific language that
could be a separate issue, and the meta-discussion on how the list of
languages should be selected could be made another issue.


> OTOH, it seems like a low-cost experiment to try so if there's a volunteer
> who wants to be the guinea pig, I'm fine with it.
>

I think Mark Shannon volunteered PEP 576 (though so far he hasn't created a
separate repo, he's just created a PR for the peps repo IIUC). I hope Nick
will also volunteer PEP 577 for this.

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

Re: [python-committers] A different way to focus discussions

[Antoine Pitrou]

Le 22/05/2018 à 20:58, Barry Warsaw a écrit :
> 
>> Thoughts? (We can dogfood this proposal too, if there's interest. :-)
> 
> I don't know whether this will help focus rambling PEP discussions.  I 
> personally don't love the linearity of GH comments.  Threading is useful!

What has become of the Discourse experiment?

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/

Re: [python-committers] A different way to focus discussions

[Barry Warsaw]

[I think my other response got dropped, so apologies for any duplicates]

Guido van Rossum wrote:
> 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.

I don't think I'd want to see tons of new PEP repos under the current `python` 
organization.  Maybe we should create a new organization for this experiment?

Also, since non-core devs can and do create PEPs, the permission management 
will be different than the normal repos.  Clearly the PEP authors should be 
owners of the individual repos, but they should probably also decide how merges 
happen, and who else can contribute to their repo.

It also means that PEP editors probably have an additional responsibility to 
create the PEP repo.

PEP 1's Discussions-To header can probably be co-opted for the URL to the GH 
repo.  Right now, that field is described as an email address, but it would be 
appropriate IMHO to also allow a URL for discussions.

> Thoughts? (We can dogfood this proposal too, if there's interest. :-)

I don't know whether this will help focus rambling PEP discussions.  I 
personally don't love the linearity of GH comments.  Threading is useful!

OTOH, it seems like a low-cost experiment to try so if there's a volunteer who 
wants to be the guinea pig, I'm fine with it.

-Barry


signature.asc
Description: Message signed with OpenPGP
___
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/

Re: [python-committers] A different way to focus discussions

[Steven D'Aprano]

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
___
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/

Re: [python-committers] A different way to focus discussions

[Paul Moore]

On 18 May 2018 at 23:25, 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. :-)

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:

1. 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.
2. Progress announcements, maybe once a month, repeating the summary
and adding a "what has changed" summary.
3. 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.
4. 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
___
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/

Re: [python-committers] A different way to focus discussions

[Serhiy Storchaka]

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?


___
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/

Re: [python-committers] A different way to focus discussions

[Antoine Pitrou]

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
>  whenever the peps repo structure changes).
___
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/

Re: [python-committers] A different way to focus discussions

[Nathaniel Smith]

On Fri, May 18, 2018 at 4:51 PM, Ivan Levkivskyi  wrote:
> On 18 May 2018 at 19:46, Gregory P. Smith  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
___
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/

Re: [python-committers] A different way to focus discussions

[Nathaniel Smith]

On Fri, May 18, 2018 at 3:25 PM, 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. :-)

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
___
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/

Re: [python-committers] A different way to focus discussions

[Guido van Rossum]

Yes, you can do that.

On Fri, May 18, 2018, 16:51 Ivan Levkivskyi  wrote:

> On 18 May 2018 at 19:46, Gregory P. Smith  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
>
>
>
___
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/

Re: [python-committers] A different way to focus discussions

[Ivan Levkivskyi]

On 18 May 2018 at 19:46, Gregory P. Smith  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
___
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/

Re: [python-committers] A different way to focus discussions

[Gregory P. Smith]

On Fri, May 18, 2018 at 3:28 PM 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.
>
> 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
___
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/

Re: [python-committers] A different way to focus discussions

[Guido van Rossum]

On Fri, May 18, 2018 at 3:58 PM, Ivan Levkivskyi 
wrote:

> I would like to clarify, what would be a typical time-line for a PEP? Will
> it look like this:
>
> 0. Preliminary discussions to determine whether an idea is PEP-worthy (can
> happen anywhere, python-ideas, SIGs, even offline)
> 1. 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.


> 2. PEP is drafted and discussed by a narrow circle of interested
> participants (happens in a separate repo)
> 3. 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.


> 4. 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.


> 5. 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  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)
___
python-committers mailing list

Re: [python-committers] A different way to focus discussions

[Carol Willing]

> On May 18, 2018, at 3:25 PM, 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.
> 

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 
, 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 )
> ___
> 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/

Re: [python-committers] A different way to focus discussions

[Ivan Levkivskyi]

I would like to clarify, what would be a typical time-line for a PEP? Will
it look like this:

0. Preliminary discussions to determine whether an idea is PEP-worthy (can
happen anywhere, python-ideas, SIGs, even offline)
1. A PEP number is requested by a champion and assigned by a PEP editor (in
python/peps repo)
2. PEP is drafted and discussed by a narrow circle of interested
participants (happens in a separate repo)
3. 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
4. If reasonable objections appear at this step, go to step 2
5. 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  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/
>
>
___
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/