[python-committers] [RELEASED] Python 3.4.9rc1 and Python 3.5.6rc1 are now available

[Larry Hastings]

On behalf of the Python development community, I'm pleased to announce 
the availability of Python 3.4.9rc1 and Python 3.5.6rc1.


Both Python 3.4 and 3.5 are in "security fixes only" mode.  Both 
versions only accept security fixes, not conventional bug fixes, and 
both releases are source-only.



You can find Python 3.4.9rc1 here:

   https://www.python.org/downloads/release/python-349rc1/


And you can find Python 3.5.6rc1 here:

   https://www.python.org/downloads/release/python-356rc1/



Python's entrenched bureaucracy soldiers on,


//arry/
___
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] And Now for Something Completely Different

[Ethan Furman]

On 07/19/2018 04:47 PM, Victor Stinner wrote:


or: Replace Dictatorship with Democracy.

Hi,

== Introduction: unjustified fears? ==

I see that many people are eager to replace the old governance based
on a single BDFL with a new governance with a new BD(FL) and/or a
council. My problem is that I don't see any clear definition of the
roles of these BD(FL) and/or council: what they are expected to do,
what they cannot do, etc.


I imagine that will be made clear in that proposed PEP.


It seems that the main question for a new governance is how to take a
decision on PEPs (accept or reject them with some variants like
Deferred). I read that core developers are unable to make a decision
themselves (fail to reach a consensus) and that letting core
developers decide would make Python "inconsistent" (as if only a
single BDFL is able to keep Python consistent). I also read that the
BDFL is required to make unpopular decisions to enhance Python.


This is, unfortunately, true -- with 100+ core-devs (give or take a few) that's basically 100+ different visions of 
Python, and on any particular issue the majority will be made up of different core-devs, therefore different visions 
will be approving/rejecting the PEPs, and internal consistency becomes impossible.



Can someone please explain me the rationale behind these fears? Do you
have examples? Maybe examples outside Python?


Examples inside Python are good enough:

- PEP 435 (Enum)  [accepted]
  lots of minor decisions from BDFL about this or that choice, and still there
  were about 1,000 emails over several threads

- PEP 461 (%-formatting for bytes and byte arrays) [accepted]
  IIRC there was lots of push-back on adding this to bytes and byte arrays

- PEP 463 (exception-catching expressions) [rejected]
  lots of discussion here, not sure if it would have been accepted by majority 
vote

- PEP 572 (assignment expressions) [accepted]
  'nough said


In my experience, a consensus has been reached in less than one month
on most PEPs without the help of the BDFL. There were a few
controversal PEPs. The most controversial PEP is obviously the latest
accepted PEP, the PEP 572 (assignment expressions). OK. But do you
have other examples?


See above.


I propose to trust core developers judgment and let them all decide if
a PEP should be accepted (or rejected). Common PEPs would require
"50%+1" majority (1/2), sensitive PEPs (ex: modify the Python
language) would require 66%+1 majority (2/3).

Known experts will help to lead the discussion and to refine the PEP.
Core developers will decide when they consider that a PEP is mature
enough for a vote.


My first issue with this model is, as discussed above, a lack of a consistent vision.  A BDFL is not just there to say, 
"this PEP is accepted," but also to say, "change this one piece here, remove that piece there, add this" -- definitely 
not something easily done by 100+ voters.


My second issue is qualifications:  there are plenty of PEPs that I either have no interest in or whose field I have no 
experience with, and my voting on those PEPs would be nonsensical; when that happens to a BDFL s/he appoints a BDFOP.


My third issue is, quite simply, time.  Working on patches takes time; reviewing PRs takes time; and being a good voting 
citizen takes lots and lots of time -- and we're all volunteers.  Time is at a premium.


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

[python-committers] And Now for Something Completely Different

[Victor Stinner]

or: Replace Dictatorship with Democracy.

Hi,

== Introduction: unjustified fears? ==

I see that many people are eager to replace the old governance based
on a single BDFL with a new governance with a new BD(FL) and/or a
council. My problem is that I don't see any clear definition of the
roles of these BD(FL) and/or council: what they are expected to do,
what they cannot do, etc.

It seems that the main question for a new governance is how to take a
decision on PEPs (accept or reject them with some variants like
Deferred). I read that core developers are unable to make a decision
themselves (fail to reach a consensus) and that letting core
developers decide would make Python "inconsistent" (as if only a
single BDFL is able to keep Python consistent). I also read that the
BDFL is required to make unpopular decisions to enhance Python.

Can someone please explain me the rationale behind these fears? Do you
have examples? Maybe examples outside Python?

In my experience, a consensus has been reached in less than one month
on most PEPs without the help of the BDFL. There were a few
controversal PEPs. The most controversial PEP is obviously the latest
accepted PEP, the PEP 572 (assignment expressions). OK. But do you
have other examples?

In a different thread,I gave the example of my PEP 446 "Make newly
created file descriptors non-inheritable": Guido approved it, even
though Charles-François Natali was against it (since it broke the
backward compatibility). If I recall correctly, the issue with that
PEP is that almost nobody cared about it: it was mostly
Charles-François and Guido :-) Hopefully, such cases are rare.


== What is the image send to the community and contributors? ==

Last year, I mentored multiple contributors. What I learnt is that
contributing to Python is much harder than what I expected.

Most core developers are core for 5 years or longer (maybe 10 years
for some of them?), and we (core developers) forgot how hard it is to
contribute. When your name is known in a community: it's very easy to
share your ideas, other people listen to you and respect your
experience. It's much faster to get a pull request merged... sometimes
simply because you merged your own PR :-)

Becoming a core developer takes between 6 months and 2 years, it
requires a lot of commitment, to have free time, etc. In short, it's
*very hard* to recruit new core developers. It seems like many people
forgot that.

What is the image sent to contributors if we create a subgroup inside
core developpers called "council"? What if we elect a new BDFL *for
life*? Does it mean that even core developers judgment are no longer
trusted, only the council decision matters? What about people outside
in the insider group of cores... regular contributors? Will anyone
still listen to them?

I'm not saying that a new governance will lead to such issues. I'm
only opening the question of the image sent to the community.


== Democracy: vote on PEPs open to all core developers ==

I would like to come back to my idea of using a vote restricted to
core developers: a PEP would require "50% +1" (at least 50% of votes +
1 voter) to be approved. Maybe some more sensitive PEPs would require
a bigger majority, like 66%+1, for example PEPs changing the Python
language. The vote would only be opened once we (core devs) consider
that the PEP is ready for a vote.


Drawbacks.

The main risk is that PEPs would fail to be approved if no consensus
can be found. In practice, it means that Python remains unchanged.
Honestly, I don't think that this consequence is a disaster:
sometimes, doing nothing *is* a wise choice :-) The PEP author is free
to retry in 6 or 12 months with a new PEP, maybe written differently,
maybe with better examples. For example, if everybody agreed to reject
the first version of the PEP 572, I expect a more positive result on
the latest flavor of the PEP. The issue is sometimes the PEP itself,
not the proposed change. Guido forced me to rewrite my very long PEP
540 "UTF-8 Mode" from scratch to make it shorter (and simpler), and it
was a major enhancement for my PEP :-)

OK, but sometimes everyone like the proposed change, but just not the
PEP itself. What can be done? Well, the PEP can be modified. Another
different PEP can be proposed. In the worst case, it's a dead end.
Again, IMHO it's fine to done nothing. Moreover, I would like to
insist that in last years, I don't think that such case occurred
frequently. To be honest, I fail to find any example...


Advantages.

We saw drawbacks. What are advantages of a democracy where every core
developer vote counts?

First, the BDFL is no longer a bottleneck. Last years, Guido became
less available, some PEPs took a lot of time to be approved, I'm
thinking about PEP 525 and PEP 530.

Moreover, core developers can take holiday. You are allowed to take
care of friends, family, and just have a break. It's fine. There are
other people who will take care of Python for you.

The decision becomes 

Re: [python-committers] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Victor Stinner]

Please extend the deadline: next week, I will be at EuroPython (I
don't think that I will have time to sit down and come up with
something), and I'm (more or less) in holiday the whole month of
August.

Victor

2018-07-19 21:43 GMT+02:00 Antoine Pitrou :
>
> Le 19/07/2018 à 21:35, Carol Willing a écrit :
>>>
> My biggest concern is that dragging this on into the new year will
> result in more bikeshedding, more uncertainty, and less confidence in
> the developer community decision making ability.

 That's a fair point.  But there's also an opposite concern that
 discussions may be deterred or cut short by a too tight deadline.  Even
 simple and uncontentious PEPs take time to write, discuss and finalize.
>>>
>>> Maybe it would be better to focus on a first date for submitting
>>> proposals and then wait to set the rest of the deadlines until after
>>> we have a bit more of the discussion behind us. That will give us
>>> a sense for how much consensus there is and how much more discussion
>>> might be needed.
>>
>> This suggestion seems to balance well the different perspectives.
>>
>> Proposals due by Sept 9, 2018 AOE.
>
> I still think it's too short.  Imagine someone leaving in August.
> Besides catching up with work, the beginning of a new school year (if
> they have kids) and other things, they have only 9 days to contribute
> usefully.
>
> This is not something we can mobilize for to try and compress the time
> span as much possible.
>
> 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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Paul Moore]

On 19 July 2018 at 20:44, Brett Cannon  wrote:
> But the amount of discussion can be unbounded (considering people write PhD
> theses on governance models and voting systems we could talk about this
> stuff forever ;), so putting a schedule in place to help focus the
> discussions can be beneficial.
>
> I'm +1 on Mariatta's schedule. That gives people more than 2 months to come
> up with governance proposals and all of us to settle on how we will vote.
> And if we say the month of November will be when voting is open then that
> would give people more then 3 months notice of when the first vote will
> occur.

As long as we understand that the deadline is intended to help focus
discussion, and not to pressure a premature or rushed decision, I
think Maraiatta's schedule is fine. If, coming up to that date, people
feel the need for more discussion/review, it should be easy to extend
the timescale. I'd like to think no-one is going to demand an
extension simply to delay the process, and conversely I assume that if
someone *does* ask for an extension, that request would be treated
with respect and consideration.

So while I think a concrete timescale will help focus the discussion,
I don't think it should be viewed as set in stone (otherwise we'll
just have yet another debate on what precise dates we should choose!)

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] Language moratorium

[Stefan Krah]

On Thu, Jul 19, 2018 at 10:24:17AM +0200, Victor Stinner wrote:
> On of the reason which motivated Facebook and Instagram to migrate
> from Python 2.7 directly to 3.5 was to get the new async and await
> keywords. So new syntaxes can be the new "killer feature" of a
> specific Python release, at least for some use cases.

This is definitely true. But Python is very strong now, much stronger
than during the last moratorium.

So in general I think making a decision for a 12 months moratorium should
not be viewed by the community as a weak "policy of not having a policy",
but as a signal of strength.

Suppose people take long vacations, take a distance to the whole PEP 572
situation, perhaps reevaluate; there is always the possibility of overlooking
a very simple solution that becomes apparent after a while.


Stefan Krah



___
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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Doug Hellmann]

Excerpts from Brett Cannon's message of 2018-07-19 12:44:23 -0700:
> On Thu, 19 Jul 2018 at 11:52 Doug Hellmann  wrote:
> 
> > Excerpts from Antoine Pitrou's message of 2018-07-19 20:07:41 +0200:
> > >
> > > Le 19/07/2018 à 20:00, Carol Willing a écrit :
> > > > I appreciate and respect the importance of these decisions. The dates
> > > > that I suggested, and I am not anchored to any of them, were not
> > > > selected to rush or be hasty. Instead, it was respect for our time
> > > > together (at least some of us) at the September sprint and to have all
> > > > proposals on the table by that time.
> > >
> > > I hadn't thought about the September sprint.  I'd say it's up to people
> > > to discuss those things there if they want or not (I would prefer if we
> > > could avoid discussions in select groups like that, but I don't think
> > > there's any reasonable way to prevent it).
> >
> > The best way to mitigate it is to agree that select groups who happen to
> > be able to meet in person won't make any final decisions, and that any
> > discussions they have that start to trend toward agreement will be
> > summarized to the mailing list so that the folks not able to be present
> > can benefit from and participate in the discussion.
> >
> 
> We already do that for the language summit and I don't think any consensus
> reached at the dev sprints would be any different. My gut says that if we
> haven't reached a consensus on how to handle voting by the dev sprints then
> we will try to reach one there to bring back to the list to see if
> team-wide consensus also exists for the voting proposal.

That plan makes sense to me.

> > > > My biggest concern is that dragging this on into the new year will
> > > > result in more bikeshedding, more uncertainty, and less confidence in
> > > > the developer community decision making ability.
> > >
> > > That's a fair point.  But there's also an opposite concern that
> > > discussions may be deterred or cut short by a too tight deadline.  Even
> > > simple and uncontentious PEPs take time to write, discuss and finalize.
> >
> > Maybe it would be better to focus on a first date for submitting
> > proposals and then wait to set the rest of the deadlines until after
> > we have a bit more of the discussion behind us. That will give us
> > a sense for how much consensus there is and how much more discussion
> > might be needed.
> >
> 
> But the amount of discussion can be unbounded (considering people write PhD
> theses on governance models and voting systems we could talk about this
> stuff forever ;), so putting a schedule in place to help focus the
> discussions can be beneficial.

Sure. I'm just suggesting not rushing to decide what that schedule
should be. Maybe by the time all of the proposals are formally written
up there will be a high enough level of consensus that it will be
possible to move to a decision sooner than we expect right now.

Either way, I do think having a schedule will give folks enough space
and time to consider the options carefully.

> I'm +1 on Mariatta's schedule. That gives people more than 2 months to come
> up with governance proposals and all of us to settle on how we will vote.
> And if we say the month of November will be when voting is open then that
> would give people more then 3 months notice of when the first vote will
> occur.
___
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] Language moratorium

[Brett Cannon]

On Thu, 19 Jul 2018 at 11:04 Barry Warsaw  wrote:

> On Jul 19, 2018, at 08:41, Brett Cannon  wrote:
> >
> > Then we would have to solve our governance problem sooner rather than
> later. But i don't think every Python release has to make a huge splash.
>
> The other option of course is to push the release date of Python 3.8 back
> to accommodate the new governance structure.
>
> > On Jul 18, 2018, at 19:23, Tim Peters  wrote:
>
> > Unsure!  Governance is needed to resolve conflict.  When there's broad
> agreement, "leaders" aren't really needed.  For example, there's been a bit
> of talk on python-ideas about adding a new `intmath` module capturing some
> frequently reinvented functions for which decent implementations are known
> but non-obvious (e.g., for generating the primes).  Nobody could sanely
> fight to death against something like that.  Even whining about it would
> appear petty ;-)
>
>
> I don’t necessarily include new modules, other stdlib changes, build or
> performance improvements, and other such “normal development” work (i.e.
> bug fixing) to be affected by a language moratorium.  PEP 572-level
> decisions would very definitely fall under that rubric.
>
> We have plenty of experts still in place that can make more minor
> decisions.  In fact, perhaps we should largely operate as if our BDFL were
> just on a long vacation and not pronouncing on PEPs.  That’s never frozen
> Python development before, and shouldn’t now.
>
> If PEP 572 were the only new syntax for 3.8, then so be it.
>

That last time we had a language moratorium we allowed new stdlib modules (
https://www.python.org/dev/peps/pep-3003/).
___
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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Brett Cannon]

On Thu, 19 Jul 2018 at 11:52 Doug Hellmann  wrote:

> Excerpts from Antoine Pitrou's message of 2018-07-19 20:07:41 +0200:
> >
> > Le 19/07/2018 à 20:00, Carol Willing a écrit :
> > > I appreciate and respect the importance of these decisions. The dates
> > > that I suggested, and I am not anchored to any of them, were not
> > > selected to rush or be hasty. Instead, it was respect for our time
> > > together (at least some of us) at the September sprint and to have all
> > > proposals on the table by that time.
> >
> > I hadn't thought about the September sprint.  I'd say it's up to people
> > to discuss those things there if they want or not (I would prefer if we
> > could avoid discussions in select groups like that, but I don't think
> > there's any reasonable way to prevent it).
>
> The best way to mitigate it is to agree that select groups who happen to
> be able to meet in person won't make any final decisions, and that any
> discussions they have that start to trend toward agreement will be
> summarized to the mailing list so that the folks not able to be present
> can benefit from and participate in the discussion.
>

We already do that for the language summit and I don't think any consensus
reached at the dev sprints would be any different. My gut says that if we
haven't reached a consensus on how to handle voting by the dev sprints then
we will try to reach one there to bring back to the list to see if
team-wide consensus also exists for the voting proposal.


>
> > > My biggest concern is that dragging this on into the new year will
> > > result in more bikeshedding, more uncertainty, and less confidence in
> > > the developer community decision making ability.
> >
> > That's a fair point.  But there's also an opposite concern that
> > discussions may be deterred or cut short by a too tight deadline.  Even
> > simple and uncontentious PEPs take time to write, discuss and finalize.
>
> Maybe it would be better to focus on a first date for submitting
> proposals and then wait to set the rest of the deadlines until after
> we have a bit more of the discussion behind us. That will give us
> a sense for how much consensus there is and how much more discussion
> might be needed.
>

But the amount of discussion can be unbounded (considering people write PhD
theses on governance models and voting systems we could talk about this
stuff forever ;), so putting a schedule in place to help focus the
discussions can be beneficial.

I'm +1 on Mariatta's schedule. That gives people more than 2 months to come
up with governance proposals and all of us to settle on how we will vote.
And if we say the month of November will be when voting is open then that
would give people more then 3 months notice of when the first vote will
occur.
___
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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Antoine Pitrou]

Le 19/07/2018 à 21:35, Carol Willing a écrit :
>>
 My biggest concern is that dragging this on into the new year will
 result in more bikeshedding, more uncertainty, and less confidence in
 the developer community decision making ability.
>>>
>>> That's a fair point.  But there's also an opposite concern that
>>> discussions may be deterred or cut short by a too tight deadline.  Even
>>> simple and uncontentious PEPs take time to write, discuss and finalize.
>>
>> Maybe it would be better to focus on a first date for submitting
>> proposals and then wait to set the rest of the deadlines until after
>> we have a bit more of the discussion behind us. That will give us
>> a sense for how much consensus there is and how much more discussion
>> might be needed.
> 
> This suggestion seems to balance well the different perspectives.
> 
> Proposals due by Sept 9, 2018 AOE.

I still think it's too short.  Imagine someone leaving in August.
Besides catching up with work, the beginning of a new school year (if
they have kids) and other things, they have only 9 days to contribute
usefully.

This is not something we can mobilize for to try and compress the time
span as much possible.

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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Carol Willing]

> On Jul 19, 2018, at 11:52 AM, Doug Hellmann  wrote:
> 
> Excerpts from Antoine Pitrou's message of 2018-07-19 20:07:41 +0200:
>> 
>> Le 19/07/2018 à 20:00, Carol Willing a écrit :
>>> I appreciate and respect the importance of these decisions. The dates
>>> that I suggested, and I am not anchored to any of them, were not
>>> selected to rush or be hasty. Instead, it was respect for our time
>>> together (at least some of us) at the September sprint and to have all
>>> proposals on the table by that time.
>> 
>> I hadn't thought about the September sprint.  I'd say it's up to people
>> to discuss those things there if they want or not (I would prefer if we
>> could avoid discussions in select groups like that, but I don't think
>> there's any reasonable way to prevent it).
> 
> The best way to mitigate it is to agree that select groups who happen to
> be able to meet in person won't make any final decisions, and that any
> discussions they have that start to trend toward agreement will be
> summarized to the mailing list so that the folks not able to be present
> can benefit from and participate in the discussion.

Excellent suggestion. Reporting to the mailing list, python-committers and 
python-dev, would be the courteous and productive thing to do.


> 
>>> My biggest concern is that dragging this on into the new year will
>>> result in more bikeshedding, more uncertainty, and less confidence in
>>> the developer community decision making ability.
>> 
>> That's a fair point.  But there's also an opposite concern that
>> discussions may be deterred or cut short by a too tight deadline.  Even
>> simple and uncontentious PEPs take time to write, discuss and finalize.
> 
> Maybe it would be better to focus on a first date for submitting
> proposals and then wait to set the rest of the deadlines until after
> we have a bit more of the discussion behind us. That will give us
> a sense for how much consensus there is and how much more discussion
> might be needed.

This suggestion seems to balance well the different perspectives.

Proposals due by Sept 9, 2018 AOE.

No formal decisions prior to October 1, 2018.


> 
> Doug
> ___
> 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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Doug Hellmann]

Excerpts from Antoine Pitrou's message of 2018-07-19 20:07:41 +0200:
> 
> Le 19/07/2018 à 20:00, Carol Willing a écrit :
> > I appreciate and respect the importance of these decisions. The dates
> > that I suggested, and I am not anchored to any of them, were not
> > selected to rush or be hasty. Instead, it was respect for our time
> > together (at least some of us) at the September sprint and to have all
> > proposals on the table by that time.
> 
> I hadn't thought about the September sprint.  I'd say it's up to people
> to discuss those things there if they want or not (I would prefer if we
> could avoid discussions in select groups like that, but I don't think
> there's any reasonable way to prevent it).

The best way to mitigate it is to agree that select groups who happen to
be able to meet in person won't make any final decisions, and that any
discussions they have that start to trend toward agreement will be
summarized to the mailing list so that the folks not able to be present
can benefit from and participate in the discussion.

> > My biggest concern is that dragging this on into the new year will
> > result in more bikeshedding, more uncertainty, and less confidence in
> > the developer community decision making ability.
> 
> That's a fair point.  But there's also an opposite concern that
> discussions may be deterred or cut short by a too tight deadline.  Even
> simple and uncontentious PEPs take time to write, discuss and finalize.

Maybe it would be better to focus on a first date for submitting
proposals and then wait to set the rest of the deadlines until after
we have a bit more of the discussion behind us. That will give us
a sense for how much consensus there is and how much more discussion
might be needed.

Doug
___
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] An alternative governance model

[Barry Warsaw]

On Jul 18, 2018, at 17:31, Alex Martelli via python-committers 
 wrote:
> Humans do so love to argue!
> 
> No we don't! (cfr http://www.montypython.net/scripts/argument.php)...

I guess that means we do love getting hit on the head…

-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] Language moratorium

[Antoine Pitrou]

Le 19/07/2018 à 20:03, Barry Warsaw a écrit :
> 
> If PEP 572 were the only new syntax for 3.8, then so be it.

+1.  Which means that:

> The other option of course is to push the release date of Python 3.8
> back to accommodate the new governance structure.

is basically unnecessary ;-)

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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Antoine Pitrou]

Le 19/07/2018 à 20:00, Carol Willing a écrit :
> I appreciate and respect the importance of these decisions. The dates
> that I suggested, and I am not anchored to any of them, were not
> selected to rush or be hasty. Instead, it was respect for our time
> together (at least some of us) at the September sprint and to have all
> proposals on the table by that time.

I hadn't thought about the September sprint.  I'd say it's up to people
to discuss those things there if they want or not (I would prefer if we
could avoid discussions in select groups like that, but I don't think
there's any reasonable way to prevent it).

> My biggest concern is that dragging this on into the new year will
> result in more bikeshedding, more uncertainty, and less confidence in
> the developer community decision making ability.

That's a fair point.  But there's also an opposite concern that
discussions may be deterred or cut short by a too tight deadline.  Even
simple and uncontentious PEPs take time to write, discuss and finalize.

Regards

Antoine.


> 
> Hoping we can compromise on a happy medium on a timeline.
> 
> 
> 
> 
> On Thu, Jul 19, 2018, 10:36 AM Antoine Pitrou  > wrote:
> 
> 
> Le 19/07/2018 à 19:26, Carol Willing a écrit :
> > Would it be possible to have all proposals:
> >
> > - How to determine the governance structure (PEP 10 or other approval
> > process)
> > - The suggested governance structure
> >
> > submitted by AOE August 31, 2018?
> >
> > That would give everyone 40ish days to get their proposals in for
> either
> > topic.
> 
> Much too short IMHO.  We are all volunteers, plus July-August is often
> an extended leave (holiday) period in European countries (not for me,
> but I imagine for other people perhaps).
> 
> This is a serious decision to take, I don't think we gain anything in
> hasting things.  Plus we are talking about a situation that seems to
> have taken everyone by surprise, given what I can read of the various
> e-mails.
> 
> Let's let people think and elaborate at a calm pace.
> 
> 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] Language moratorium

[Barry Warsaw]

On Jul 19, 2018, at 08:41, Brett Cannon  wrote:
> 
> Then we would have to solve our governance problem sooner rather than later. 
> But i don't think every Python release has to make a huge splash.

The other option of course is to push the release date of Python 3.8 back to 
accommodate the new governance structure.

> On Jul 18, 2018, at 19:23, Tim Peters  wrote:

> Unsure!  Governance is needed to resolve conflict.  When there's broad 
> agreement, "leaders" aren't really needed.  For example, there's been a bit 
> of talk on python-ideas about adding a new `intmath` module capturing some 
> frequently reinvented functions for which decent implementations are known 
> but non-obvious (e.g., for generating the primes).  Nobody could sanely fight 
> to death against something like that.  Even whining about it would appear 
> petty ;-)


I don’t necessarily include new modules, other stdlib changes, build or 
performance improvements, and other such “normal development” work (i.e. bug 
fixing) to be affected by a language moratorium.  PEP 572-level decisions would 
very definitely fall under that rubric.

We have plenty of experts still in place that can make more minor decisions.  
In fact, perhaps we should largely operate as if our BDFL were just on a long 
vacation and not pronouncing on PEPs.  That’s never frozen Python development 
before, and shouldn’t now.

If PEP 572 were the only new syntax for 3.8, then so be it.

Cheers,
-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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Carol Willing]

I appreciate and respect the importance of these decisions. The dates that
I suggested, and I am not anchored to any of them, were not selected to
rush or be hasty. Instead, it was respect for our time together (at least
some of us) at the September sprint and to have all proposals on the table
by that time.

You make a good point about European holidays. I am not opposed to delaying
a couple of weeks (due date for proposals by the September sprint start).

My biggest concern is that dragging this on into the new year will result
in more bikeshedding, more uncertainty, and less confidence in the
developer community decision making ability.

Hoping we can compromise on a happy medium on a timeline.




On Thu, Jul 19, 2018, 10:36 AM Antoine Pitrou  wrote:

>
> Le 19/07/2018 à 19:26, Carol Willing a écrit :
> > Would it be possible to have all proposals:
> >
> > - How to determine the governance structure (PEP 10 or other approval
> > process)
> > - The suggested governance structure
> >
> > submitted by AOE August 31, 2018?
> >
> > That would give everyone 40ish days to get their proposals in for either
> > topic.
>
> Much too short IMHO.  We are all volunteers, plus July-August is often
> an extended leave (holiday) period in European countries (not for me,
> but I imagine for other people perhaps).
>
> This is a serious decision to take, I don't think we gain anything in
> hasting things.  Plus we are talking about a situation that seems to
> have taken everyone by surprise, given what I can read of the various
> e-mails.
>
> Let's let people think and elaborate at a calm pace.
>
> 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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Barry Warsaw]

On Jul 19, 2018, at 10:19, Terry Reedy  wrote:
> 
> On 7/19/2018 1:10 PM, Mariatta Wijaya wrote:
>> On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon > > wrote:
>> So what about the following timelines:
>> Oct 1: Deadline for people to come up with proposals of governance model, 
>> candidates, and how to vote
>> Dec 1: Deadline to choose a governance model, (and if possible, we choose 
>> the new leader(s) too)
> 
> Why not Nov 1, leaving a month to decide on proposals?
> 
>> Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec 1.

I like the Nov 1 schedule.  I’m +1 with giving plenty of time to process, but I 
share the concern about letting things drag on too long.

IMHO, ideally we’d have the new governance structure and its office holders in 
place by EOY18.  That has to account for various holidays, including 
Thanksgiving in the US and Christmas to New Years.

Cheers,
-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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Antoine Pitrou]

Le 19/07/2018 à 19:26, Carol Willing a écrit :
> Would it be possible to have all proposals:
> 
> - How to determine the governance structure (PEP 10 or other approval
> process)
> - The suggested governance structure
> 
> submitted by AOE August 31, 2018?
> 
> That would give everyone 40ish days to get their proposals in for either
> topic.

Much too short IMHO.  We are all volunteers, plus July-August is often
an extended leave (holiday) period in European countries (not for me,
but I imagine for other people perhaps).

This is a serious decision to take, I don't think we gain anything in
hasting things.  Plus we are talking about a situation that seems to
have taken everyone by surprise, given what I can read of the various
e-mails.

Let's let people think and elaborate at a calm pace.

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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Terry Reedy]

On 7/19/2018 1:10 PM, Mariatta Wijaya wrote:



On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon > wrote:



I had Carol's same worry that while it's great to have a "no sooner
than" date, we also can't let this drag on and we have no "settle
by" date, else we risk losing the faith of the community in our
ability to come together and make decisions (e.g. if I heard it took
a year for a project to resolve this then I would think there was
some major divisiveness on the team).

So could we go with Nathaniel's idea of no decision before October,
but any proposals to be ready by then as well as Ethan suggested?

I would also propose we have a goal of at least choosing the
governance model by the end of the year (and a stretch goal to even
have people placed into created positions by then as well). I have
no problem with sooner, but I think it might be good to try to put
_some_ upper bound on this.

-Brett


Sounds good.
So what about the following timelines:
Oct 1: Deadline for people to come up with proposals of governance 
model, candidates, and how to vote
Dec 1: Deadline to choose a governance model, (and if possible, we 
choose the new leader(s) too)


Why not Nov 1, leaving a month to decide on proposals?


Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec 1.


___
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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Mariatta Wijaya]

On Thu, Jul 19, 2018 at 8:59 AM Brett Cannon  wrote:

>
> I had Carol's same worry that while it's great to have a "no sooner than"
> date, we also can't let this drag on and we have no "settle by" date, else
> we risk losing the faith of the community in our ability to come together
> and make decisions (e.g. if I heard it took a year for a project to resolve
> this then I would think there was some major divisiveness on the team).
>
> So could we go with Nathaniel's idea of no decision before October, but
> any proposals to be ready by then as well as Ethan suggested?
>
> I would also propose we have a goal of at least choosing the governance
> model by the end of the year (and a stretch goal to even have people placed
> into created positions by then as well). I have no problem with sooner, but
> I think it might be good to try to put _some_ upper bound on this.
>
> -Brett
>
>
Sounds good.
So what about the following timelines:
Oct 1: Deadline for people to come up with proposals of governance model,
candidates, and how to vote
Dec 1: Deadline to choose a governance model, (and if possible, we choose
the new leader(s) too)
Jan 1: Deadline to choose the new leader(s), if not already chosen by Dec 1.

?
___
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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Brett Cannon]

On Wed, Jul 18, 2018, 22:32 Carol Willing,  wrote:

> Thanks Ethan for clarifying. Totally cool if that is the case.
>
> On Wed, Jul 18, 2018, 10:19 PM Ethan Furman  wrote:
>
>> On 07/18/2018 09:40 PM, Carol Willing wrote:
>> > I am in favor of a time limit. Yet, October 1 seems a bit too long for
>> the initial governance decision (i.e. how to
>> > decide how to decide). My perspective, based on transitions in
>> non-profits and the corporate world, is that the longer
>> > an organization let's it draw out then fear, uncertainty, and doubt
>> creep in.
>> >
>> > We have PEP 10 in place for a strawperson vote. It seems as good as
>> anything to use to determine how to make a decision.
>> > Perhaps set a 30 day deadline to submit decision process
>> recommendations. Then take a strawperson poll on each and at
>> > the core sprint create a time window for specific proposals on
>> structure be submitted before October 1.
>> >
>> > My concern if we leave how to decide until at least Oct 1 that the
>> likelihood of completing this year is fairly low.
>>
>> My understanding is that, between now and Oct 1, we'll all get our
>> proposals together for both how to decide, and what
>> to decide.  Then we have the first vote to decide how to decide, then
>> maybe a week or two later we use that mechanism to
>> decide on a governance model.
>>
>
I had Carol's same worry that while it's great to have a "no sooner than"
date, we also can't let this drag on and we have no "settle by" date, else
we risk losing the faith of the community in our ability to come together
and make decisions (e.g. if I heard it took a year for a project to resolve
this then I would think there was some major divisiveness on the team).

So could we go with Nathaniel's idea of no decision before October, but any
proposals to be ready by then as well as Ethan suggested?

I would also propose we have a goal of at least choosing the governance
model by the end of the year (and a stretch goal to even have people placed
into created positions by then as well). I have no problem with sooner, but
I think it might be good to try to put _some_ upper bound on this.

-Brett



>> --
>> ~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/
>>
> ___
> 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] Language moratorium

[Brett Cannon]

On Thu, Jul 19, 2018, 01:24 Victor Stinner,  wrote:

> Hi,
>
> 2018-07-18 18:11 GMT+02:00 Stefan Krah :
> > Perhaps we could have one again, say for 12 months so we can figure
> things
> > out. Other Python implementations may welcome the moratorium so they can
> > catch up.
>
> Python 3.8 has a new syntax for assignment expressions (PEP 572). A
> moratorium of 12 months in practice means no other syntax changes for
> Python 3.8. I strongly prefer to introduce syntax changes early in the
> development cycle, rather than late, to give time to third party
> modules to be updated (ex: linters like flake8 or pylint).
>
> I am unable to decide if a moratorium is a good idea. For example, I
> was (strongly) against f-string at the beginning, and wrote that it
> was possible to write the same thing without f-string. You can say the
> same for PEP 572 which is "more or less" pure syntax sugar. But Python
> 3.6 also got a simple change to allow underscore in numbers for
> readability (PEP 515) and I now really love that feature.
>
> On the side, I would like to slow down syntax changes. On the other
> side, I started to really love latest syntax changes...
>
> What about other syntax changes like async and await which became real
> keywords? IMHO it's also a major enhancement for asyncio, even if they
> were more or less already keywords :-)
>
> When I look back at syntax changes since Python 3.4, it's really hard
> for me to say that I prefer to stay at Python 3.4 (syntax) forever and
> never use Python 3.5, 3.6 and 3.7 new syntaxes... When I can use them,
> I started to strongly prefer f-string over str % args (which now kind
> of look as "legacy" compared to f-string) or its verbose brother
> str.format(args).
>
> On of the reason which motivated Facebook and Instagram to migrate
> from Python 2.7 directly to 3.5 was to get the new async and await
> keywords. So new syntaxes can be the new "killer feature" of a
> specific Python release, at least for some use cases.
>

Then we would have to solve our governance problem sooner rather than
later. But i don't think every Python release has to make a huge splash.

-Brett


> 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/
>
___
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] 3.4.9rc1 and 3.5.6rc1 slipping by one day to Thursday July 19 2018

[Larry Hastings]

I was working with Serhiy on fixing the documentation for some bytecodes 
in 3.5 (GH-8338) and time got away from me.  They'll both be out later 
today, Thursday July 19 2018.


*yawn,*


//arry/
___
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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Mark Shannon]

On 19/07/18 03:36, Nathaniel Smith wrote:

[tl;dr: We need some ground rules, because uncertainty makes it hard
to think straight. But if we get sucked into a complicated meta-debate
about the ground rules then that defeats the purpose. My proposal for
a Minimum Viable Ground Rule: let's all agree not to finalize any
governance decisions before October 1.]


+1

Cheers,
Mark.
___
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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Paul Moore]

On 19 July 2018 at 08:33, Antoine Pitrou  wrote:
>
> Le 19/07/2018 à 04:36, Nathaniel Smith a écrit :
>> [tl;dr: We need some ground rules, because uncertainty makes it hard
>> to think straight. But if we get sucked into a complicated meta-debate
>> about the ground rules then that defeats the purpose. My proposal for
>> a Minimum Viable Ground Rule: let's all agree not to finalize any
>> governance decisions before October 1.]
>
> +1 from me.  Thank you.

+1 from me too. You make very good points (particularly regarding the
"fear of something happening while I'm not watching" factor).
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] Language moratorium

[Victor Stinner]

Hi,

2018-07-18 18:11 GMT+02:00 Stefan Krah :
> Perhaps we could have one again, say for 12 months so we can figure things
> out. Other Python implementations may welcome the moratorium so they can
> catch up.

Python 3.8 has a new syntax for assignment expressions (PEP 572). A
moratorium of 12 months in practice means no other syntax changes for
Python 3.8. I strongly prefer to introduce syntax changes early in the
development cycle, rather than late, to give time to third party
modules to be updated (ex: linters like flake8 or pylint).

I am unable to decide if a moratorium is a good idea. For example, I
was (strongly) against f-string at the beginning, and wrote that it
was possible to write the same thing without f-string. You can say the
same for PEP 572 which is "more or less" pure syntax sugar. But Python
3.6 also got a simple change to allow underscore in numbers for
readability (PEP 515) and I now really love that feature.

On the side, I would like to slow down syntax changes. On the other
side, I started to really love latest syntax changes...

What about other syntax changes like async and await which became real
keywords? IMHO it's also a major enhancement for asyncio, even if they
were more or less already keywords :-)

When I look back at syntax changes since Python 3.4, it's really hard
for me to say that I prefer to stay at Python 3.4 (syntax) forever and
never use Python 3.5, 3.6 and 3.7 new syntaxes... When I can use them,
I started to strongly prefer f-string over str % args (which now kind
of look as "legacy" compared to f-string) or its verbose brother
str.format(args).

On of the reason which motivated Facebook and Instagram to migrate
from Python 2.7 directly to 3.5 was to get the new async and await
keywords. So new syntaxes can be the new "killer feature" of a
specific Python release, at least for some use cases.

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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Yury Selivanov]

On Thu, Jul 19, 2018 at 5:36 AM Nathaniel Smith  wrote:

> What would be a good date? The core sprint is coming up Sept. 10-14,
> and this seems to be a likely topic of conversation there. And then
> after the sprint, those who aren't present will need time to catch up
> with any discussions that happened at the sprint. So to make things
> concrete, I propose: no governance decisions finalized before October
> 1, 2018.
>

+1.

Yury
___
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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Antoine Pitrou]

Le 19/07/2018 à 04:36, Nathaniel Smith a écrit :
> [tl;dr: We need some ground rules, because uncertainty makes it hard
> to think straight. But if we get sucked into a complicated meta-debate
> about the ground rules then that defeats the purpose. My proposal for
> a Minimum Viable Ground Rule: let's all agree not to finalize any
> governance decisions before October 1.]

+1 from me.  Thank you.

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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Steve Dower]

I’ll be a little disappointed to not have anything in place by the sprints, as 
most of my planned work was to get my PEPs accepted, but it seems we have a 
fairly sizable split within the group between the ~3 proposals so far (NBDFL, 
Council, delay), so under the circumstances I think it’s most fair to let those 
in the third group have time to think through. (I haven’t been counting or 
keeping track of names, but it seems like different people are +1-ing this 
thread than were doing it on the others.)

Consider this a +0.

Cheers,
Steve

Top-posted from my Windows 10 phone

From: Nathaniel Smith
Sent: Wednesday, 18 July 2018 19:37
To: python-committers
Subject: [python-committers] Proposal: an explicit,time-limited moratorium on 
finalizing any governance decisions

[tl;dr: We need some ground rules, because uncertainty makes it hard
to think straight. But if we get sucked into a complicated meta-debate
about the ground rules then that defeats the purpose. My proposal for
a Minimum Viable Ground Rule: let's all agree not to finalize any
governance decisions before October 1.]

We're in a constitutional crisis, and that's scary. There's no map and
none of us know what to expect. It feels like anything could happen.
You look at the mailing list and see people making big proposals -- is
one of them going to suddenly be adopted? If I look away for a few
days, will I come back and find out that something's been decided?
What are we even talking about? Do I need to jump into that thread
RIGHT NOW? It's scary.

People don't do their best work when scared. When we're scared it's
harder to listen and build up common ground with others -- but that's
exactly what we'll need to do to get through this. And also, like...
being scared sucks. I would prefer to be less scared.

So: can we do anything to make this less scary?

One thing that would help is if we had some ground-rules for how the
decision itself will be made. Knowing what to expect makes things less
scary. There's another thread going on right now trying to do that
(subject "Proposal on how to vote"). But... if you look at that
thread, it turns out deciding on how to vote is itself an important
decision with lots of subtle issues, where we probably want to give
people time to think, brainstorm, critique. Heck, in the end we might
decide a vote isn't even the best approach. So I'm not saying we
shouldn't be having that discussion, we definitely should, but... it's
also giving me a new source of anxiety: that we'll all be so eager to
get *some* certainty here that we'll end up trying to force a decision
prematurely. Kind of a catch-22: the decision about how to make
complex decisions is itself a complex decision, which is what we don't
know how to do yet.

Is there some way to avoid this loop? Can we come up with some ground
rules simple enough that we can agree on them without a big debate?
Well, there's one thing I am pretty sure of: this is a big decision,
there's a lot to think about and talk about, and that we won't regret
taking some time some time to do that. And besides, trying to force it
to happen faster will make people more scared and dig in their heels.

So here's my proposal for an initial, Minimum Viable Ground Rule: we
should set a date and promise that no actual decisions will be
finalized before that. Until then we are just talking and
brainstorming and gradually converging on points of consensus. (And to
be clear, the point of this is to give us breathing room, not set a
deadline -- we shouldn't dawdle, but if we get there and it turns out
we need more time, then that's OK.)

What would be a good date? The core sprint is coming up Sept. 10-14,
and this seems to be a likely topic of conversation there. And then
after the sprint, those who aren't present will need time to catch up
with any discussions that happened at the sprint. So to make things
concrete, I propose: no governance decisions finalized before October
1, 2018.

Probably this is what will end up happening anyway, but if we make it
explicit in advance and tell everyone, then at least we'll all know
that it's OK to stop refreshing our email constantly and redirect that
energy in more useful directions.

What do you all think?

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

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