Re: [python-committers] Python 4.0 or Python 3.10?

[Barry Warsaw]

On Sep 25, 2018, at 18:57, Victor Stinner  wrote:
> 
> IMHO It's time to discuss again modifying the "python" program to always 
> point to the latest Python version.

This just came up again on linux-sig, but...

> What is the status of Brett's UNIX Python launcher "py" by the way?

...I forgot to mention this.

FWIW, I still think we shouldn’t recommend a change here until 2.7 is done and 
done.  However, the launcher might be a good way out.

-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] Python 4.0 or Python 3.10?

[Victor Stinner]

Serhiy:
> And changing the major version number itself is significant breaking
change. From the name of the executable (python3 vs python4) hardcoded in
Python

IMHO It's time to discuss again modifying the "python" program to always
point to the latest Python version.

What is the status of Brett's UNIX Python launcher "py" by the way?

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] Python 4.0 or Python 3.10?

[Donald Stufft]

> On Sep 25, 2018, at 6:39 PM, Yury Selivanov  wrote:
> 
> I think we all have seen code like that; it's a common pattern.  So by
> just bumping the version to 4.0 you would break the compatibility for
> some libraries and frameworks.  And maybe breaking it is fine if
> there's a very strong technical reason, but doing that just to make a
> statement isn't worth it, IMHO.


Breaking a bunch of software to make the statement that you’re not going to 
break backwards compatibility anymore sounds like something out of a Monty 
Python skit though ;)___
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] Python 4.0 or Python 3.10?

[Yury Selivanov]

On Tue, Sep 25, 2018 at 6:33 PM Victor Stinner  wrote:
>
> Hi,
>
> I would prefer to never ever break the backward compatibility in Python. To 
> make it clear I suggest to use 4.0 for the release following Python 3.7.

I think Serhiy made a strong argument that the code like below would
break if we release Python 4.0:

 PY3 = sys.version_info[0] == 3
 if not PY3:
 ... # implies Python 2

I think we all have seen code like that; it's a common pattern.  So by
just bumping the version to 4.0 you would break the compatibility for
some libraries and frameworks.  And maybe breaking it is fine if
there's a very strong technical reason, but doing that just to make a
statement isn't worth it, IMHO.

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] Python 4.0 or Python 3.10?

[Victor Stinner]

Hi,

I would prefer to never ever break the backward compatibility in Python. To
make it clear I suggest to use 4.0 for the release following Python 3.7.

More and more data confirm me frequently that we already reached the
critical mass to declare that the migration to Python 3 is done.

There was no Python 2.8, I suggest to skip 3.8. Ten years is enough between
two major versions...

To be clear, I only propose to change the version number. Not break
anything. Not remove anything. Any pending removal scheduled for 4.0 must
be postponed, maybe to 4.1, maybe 4.2, maybe never.

Linux switched from 3.x to 4.x and didn't break anything. We can do the
same.

--

Ok, some people like me want to break the backward compatibility. You have
to fight against that and make sure that incompatible changes are limited
and very small per release.

Please don't use the C API as any promise of anything. This project is
highly experimental and don't iffer anaything except pain at this point ;-)

Victor

Le mardi 25 septembre 2018, Yury Selivanov  a
écrit :
> What's the current plan for what version of Python we release after 3.9?
>
> The reason I'm asking this is because I frequently need to refer to
> *that version* of Python in the documentation, especially when I'm
> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> implying that 4.0 will be released right after 3.9.
>
> I've heard multiple opinions on this subject. One of them is that we
> should release 4.0 when we have a major new change, like removal of
> the GIL or introduction of a JIT compiler.  On the other hand, we have
> no estimate when we have such a change. We also don't want Python 4.0
> to be backwards incompatible with Python 3.0 (at least not at the
> scale of 2 vs 3).  So to me, it seems logical that we simply release
> Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
> drastically different from 3.0 and from 2.7.  It sounds better. :)
>
> Finally, I'm not sure we need a new governance in place to make this
> decision or maybe we can make it now. That's why I'm posting this to
> python-committers to see if core devs already have a consensus on
> this.
>
> 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/
>
___
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] Python 4.0 or Python 3.10?

[Facundo Batista]

2018-09-25 16:30 GMT-03:00 Yury Selivanov :

> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> implying that 4.0 will be released right after 3.9.
>
> I've heard multiple opinions on this subject. One of them is that we
> should release 4.0 when we have a major new change, like removal of
> the GIL or introduction of a JIT compiler.  On the other hand, we have
> no estimate when we have such a change. We also don't want Python 4.0
> to be backwards incompatible with Python 3.0 (at least not at the
> scale of 2 vs 3).  So to me, it seems logical that we simply release
> Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
> drastically different from 3.0 and from 2.7.  It sounds better. :)

On the other hand... the best chance we have to let the world know
that "we will never ever again break everything as we did with the 2
to 3 transition" is to just release 4.0 after 3.9 as a simple follow
up release with just the minor and usual glitches we have from minor
to minor release.

IOW, we're breaking the major/minor revision evolution, but we're
firmly signaling that a transition that could take a decade will not
happen anymore in the future, that we learned the lesson and all
evolution steps will be smooth.

See it as more a political/social decision, than a technical one.

Note 1: I remember Guido saying something like this, but to be fair I
couldn't find any mail with a statement like that in a 10' exploration
I just did.

Note 2: I know we planned 2.7.10 after 2.7.9, but that just reinforces
my point: the idea is to communicate that we'll never have again a
dead end like 2.7.

Regards,

-- 
.Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org.ar/
Twitter: @facundobatista
___
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] Python 4.0 or Python 3.10?

[Yury Selivanov]

On Tue, Sep 25, 2018 at 5:18 PM Nathaniel Smith  wrote:
>
> On Tue, Sep 25, 2018, 12:30 Yury Selivanov  wrote:
>>
>> The reason I'm asking this is because I frequently need to refer to
>> *that version* of Python in the documentation, especially when I'm
>> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
>> implying that 4.0 will be released right after 3.9.
>
>
> I don't know what we'll end up calling it, but I don't think it matters for 
> this. For warnings about future deprecations and removals, I would use "3.10" 
> regardless.
>
> No one can predict the future; maybe our future selves will change their 
> minds when we get there. But for people reading the documentation now, "3.10" 
> clearly means "the version after 3.9", so they'll understand what you mean. 
> And if it ends up being called 4.0 then that's higher than 3.10 anyway, so no 
> one can claim you didn't warn them.
>
> OTOH if you write "4.0", at least some people will misunderstand, and be 
> grumpy if the feature disappears in 3.10.

Yeah, this makes sense.

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] Python 4.0 or Python 3.10?

[Nathaniel Smith]

On Tue, Sep 25, 2018, 12:30 Yury Selivanov  wrote:

> The reason I'm asking this is because I frequently need to refer to
> *that version* of Python in the documentation, especially when I'm
> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> implying that 4.0 will be released right after 3.9.
>

I don't know what we'll end up calling it, but I don't think it matters for
this. For warnings about future deprecations and removals, I would use
"3.10" regardless.

No one can predict the future; maybe our future selves will change their
minds when we get there. But for people reading the documentation now,
"3.10" clearly means "the version after 3.9", so they'll understand what
you mean. And if it ends up being called 4.0 then that's higher than 3.10
anyway, so no one can claim you didn't warn them.

OTOH if you write "4.0", at least some people will misunderstand, and be
grumpy if the feature disappears in 3.10.

-n
___
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] Python 4.0 or Python 3.10?

[Brian Curtin]

On Tue, Sep 25, 2018 at 2:38 PM Serhiy Storchaka 
wrote:

> 25.09.18 22:40, Barry Warsaw пише:
> > On Sep 25, 2018, at 15:31, Antoine Pitrou  wrote:
> >> So my preference would be on 3.10.
> > 3.9 + 0.1 :)
> >
> > Renaming it to Python 4 is fraught with knock-on effects, so I think we
> do reserve that for major changes.  I doubt we’ll ever need for a
> disruptive backward incompatible change *at the Python level* in a Python
> 4, but I absolutely can see the possibility of incompatible changes at the
> public C API layer.  I’m not saying it *will* happen, but that’s what we
> should reserve “Python 4” for if or when it happens.
>
> I concur.
>
> And changing the major version number itself is significant breaking
> change. From the name of the executable (python3 vs python4) hardcoded
> in Python and shell scripts to a number of third-party scripts that
> contain in the best case:
>
>  PY3 = sys.version_info[0] == 3
>  if not PY3:
>  ... # implies Python 2
>
> and in the worst case:
>
>  PY3 = sys.version[0] == '3'
>
> Changing the minor version number from a single-digit to a two-digits
> will break some software too, but I think that this breakage is smaller.
>

FWIW, we had a similar bump in 2015 (?) when 2.7.10 was about to come out.
Moving up to two digits might break some assumptions, though users misusing
things isn't really our problem. Someone out there is parsing
`sys.version[:5]` or `platform.python_version()` instead of the
alternatives that are better suited to getting specific parts of the
version.
___
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] Python 4.0 or Python 3.10?

[Yury Selivanov]

On Tue, Sep 25, 2018 at 4:38 PM Serhiy Storchaka  wrote:
[..]
> And changing the major version number itself is significant breaking
> change. From the name of the executable (python3 vs python4) hardcoded
> in Python and shell scripts to a number of third-party scripts that
> contain in the best case:
>
>  PY3 = sys.version_info[0] == 3
>  if not PY3:
>  ... # implies Python 2
>
> and in the worst case:
>
>  PY3 = sys.version[0] == '3'
>
> Changing the minor version number from a single-digit to a two-digits
> will break some software too, but I think that this breakage is smaller.

I think this is the last nail in the coffin of the "Python 4.0 after 3.9" idea.

Seems that we've reached the consensus: we release Python 3.10 after
Python 3.9.  We maybe release Python 4.0 at some point if there's a
significant backwards incompatible change.

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] Python 4.0 or Python 3.10?

[Serhiy Storchaka]

25.09.18 22:40, Barry Warsaw пише:

On Sep 25, 2018, at 15:31, Antoine Pitrou  wrote:

So my preference would be on 3.10.

3.9 + 0.1 :)

Renaming it to Python 4 is fraught with knock-on effects, so I think we do 
reserve that for major changes.  I doubt we’ll ever need for a disruptive 
backward incompatible change *at the Python level* in a Python 4, but I 
absolutely can see the possibility of incompatible changes at the public C API 
layer.  I’m not saying it *will* happen, but that’s what we should reserve 
“Python 4” for if or when it happens.


I concur.

And changing the major version number itself is significant breaking 
change. From the name of the executable (python3 vs python4) hardcoded 
in Python and shell scripts to a number of third-party scripts that 
contain in the best case:


    PY3 = sys.version_info[0] == 3
    if not PY3:
    ... # implies Python 2

and in the worst case:

    PY3 = sys.version[0] == '3'

Changing the minor version number from a single-digit to a two-digits 
will break some software too, but I think that this breakage is smaller.

___
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] Python 4.0 or Python 3.10?

[Eric Snow]

On Tue, Sep 25, 2018 at 1:30 PM Yury Selivanov  wrote:
> What's the current plan for what version of Python we release after 3.9?

One idea I've heard is to switch to calendar versioning after 3.9.  So
we'd start with something like "2021" (year) or "2021.06" (year +
month).  sys.version_info would stay monotonic and so would the
version macro in the C-API.  The executable would still be "python3"
so it may still make sense to incorporate "3" into the version.  When
we do get to a major/breaking change we'd change the executable to
"python4" and incorporate "4" into the version.

Switching to calver doesn't necessarily mean we'd tie ourselves to a
fixed release schedule, but doing so would probably fit better with
calver. :)

Anyway, this is just something I've heard discussed which I kind of liked.

-eric
___
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] Python 4.0 or Python 3.10?

[Paul Moore]

On Tue, 25 Sep 2018 at 20:32, Antoine Pitrou  wrote:
>
>
> Le 25/09/2018 à 21:30, Yury Selivanov a écrit :
> > What's the current plan for what version of Python we release after 3.9?
> >
> > The reason I'm asking this is because I frequently need to refer to
> > *that version* of Python in the documentation, especially when I'm
> > deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> > implying that 4.0 will be released right after 3.9.
> >
> > I've heard multiple opinions on this subject. One of them is that we
> > should release 4.0 when we have a major new change, like removal of
> > the GIL or introduction of a JIT compiler.  On the other hand, we have
> > no estimate when we have such a change. We also don't want Python 4.0
> > to be backwards incompatible with Python 3.0 (at least not at the
> > scale of 2 vs 3).  So to me, it seems logical that we simply release
> > Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
> > drastically different from 3.0 and from 2.7.  It sounds better. :)
>
> Many people have bad memories of the Py2->3 transition, so I think we
> should avoid triggering their sensitivities by announcing a Py4 if
> there's nothing, in terms of changes, to justify the jump.
>
> So my preference would be on 3.10.

I agree. 3.10 seems like the best choice. Even though we don't expect
4.0 to be a major breaking change like 3.0, people do assume something
like semantic versioning, and therefore expect 3.9 -> 4.0 to be a
"bigger" change than 3.9 -> 3.10.

One thing that *will* need work is places that assume single-digit
version components (for example the wheel spec uses pyXY to mark
compatibility with Python X.Y - that will need tweaking to allow for
3.10). IMO, we should make it clear sooner rather than later that
version numbering will be going 3.8, 3.9, 3.10, 3.11, ... to give
people a chance to prepare. Otherwise we might inadvertently have
another major compatibility issue right after 3.9 :-( The uncertainty
simply lets people assume whatever's least disruptive for them, and
not be ready.

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] Python 4.0 or Python 3.10?

[Barry Warsaw]

On Sep 25, 2018, at 15:31, Antoine Pitrou  wrote:
> 
> So my preference would be on 3.10.

3.9 + 0.1 :)

Renaming it to Python 4 is fraught with knock-on effects, so I think we do 
reserve that for major changes.  I doubt we’ll ever need for a disruptive 
backward incompatible change *at the Python level* in a Python 4, but I 
absolutely can see the possibility of incompatible changes at the public C API 
layer.  I’m not saying it *will* happen, but that’s what we should reserve 
“Python 4” for if or when it happens.

-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] Python 4.0 or Python 3.10?

[Matthias Klose]

On 25.09.2018 21:30, Yury Selivanov wrote:
> What's the current plan for what version of Python we release after 3.9?
> 
> The reason I'm asking this is because I frequently need to refer to
> *that version* of Python in the documentation, especially when I'm
> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> implying that 4.0 will be released right after 3.9.
> 
> I've heard multiple opinions on this subject. One of them is that we
> should release 4.0 when we have a major new change, like removal of
> the GIL or introduction of a JIT compiler.  On the other hand, we have
> no estimate when we have such a change. We also don't want Python 4.0
> to be backwards incompatible with Python 3.0 (at least not at the
> scale of 2 vs 3).  So to me, it seems logical that we simply release
> Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
> drastically different from 3.0 and from 2.7.  It sounds better. :)

why call it 4.0 when there are no significant changes?  Just calling it
4.something sends the wrong signal, that probably people try to skip 3.x and
keep going with 2.7 ...

> Finally, I'm not sure we need a new governance in place to make this
> decision or maybe we can make it now. That's why I'm posting this to
> python-committers to see if core devs already have a consensus on
> this.

sorry, for me that sounds like a non-decision.
___
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] Python 4.0 or Python 3.10?

[Antoine Pitrou]

Le 25/09/2018 à 21:30, Yury Selivanov a écrit :
> What's the current plan for what version of Python we release after 3.9?
> 
> The reason I'm asking this is because I frequently need to refer to
> *that version* of Python in the documentation, especially when I'm
> deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
> implying that 4.0 will be released right after 3.9.
> 
> I've heard multiple opinions on this subject. One of them is that we
> should release 4.0 when we have a major new change, like removal of
> the GIL or introduction of a JIT compiler.  On the other hand, we have
> no estimate when we have such a change. We also don't want Python 4.0
> to be backwards incompatible with Python 3.0 (at least not at the
> scale of 2 vs 3).  So to me, it seems logical that we simply release
> Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
> drastically different from 3.0 and from 2.7.  It sounds better. :)

Many people have bad memories of the Py2->3 transition, so I think we
should avoid triggering their sensitivities by announcing a Py4 if
there's nothing, in terms of changes, to justify the jump.

So my preference would be on 3.10.

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] Python 4.0 or Python 3.10?

[Yury Selivanov]

What's the current plan for what version of Python we release after 3.9?

The reason I'm asking this is because I frequently need to refer to
*that version* of Python in the documentation, especially when I'm
deprecating APIs or behavior.  Right now I'm saying "Python 4.0"
implying that 4.0 will be released right after 3.9.

I've heard multiple opinions on this subject. One of them is that we
should release 4.0 when we have a major new change, like removal of
the GIL or introduction of a JIT compiler.  On the other hand, we have
no estimate when we have such a change. We also don't want Python 4.0
to be backwards incompatible with Python 3.0 (at least not at the
scale of 2 vs 3).  So to me, it seems logical that we simply release
Python 4.0 after Python 3.9.  After all, after 3.9 Python will be
drastically different from 3.0 and from 2.7.  It sounds better. :)

Finally, I'm not sure we need a new governance in place to make this
decision or maybe we can make it now. That's why I'm posting this to
python-committers to see if core devs already have a consensus on
this.

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] Council / board (Was: 1 week to Oct 1)

[Barry Warsaw]

On Sep 25, 2018, at 14:40, Brett Cannon  wrote:

> For me personally, I am not going to participate in any discussion about any 
> PEP until there is a published text to refer to, otherwise the discussion is 
> ripe for misunderstandings. If a PEP comes out which people disagree with and 
> want an alternative for I'm sure we can give them an opportunity to create a 
> tweaked PEP (but I also assume we will have a civil discussion first in hopes 
> of finding consensus first).

Agreed.  Also, something we discussed at the sprints was the idea of each of 
the general governing PEPs will have certain knobs that can be tweaked.  E.g. 
the exact number of folks on a committee, or their term limits, etc.  It’s 
probably counterproductive to have competing PEPs that differ only in some of 
these details.  Ultimately, it’s up to the PEP authors, but I think we’ll come 
to consensus much more quickly when we can use the PEPs to describe the general 
shape of governance, and work the details out in the subsequent conversations.  
At least, that’s how I see it working for the PEP I’ve promised to author.

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] Council / board (Was: 1 week to Oct 1)

[Brett Cannon]

On Tue, 25 Sep 2018 at 09:18, M.-A. Lemburg  wrote:

> On 25.09.2018 16:28, Mariatta Wijaya wrote:
> > My proposal is taking into consideration The PSF's mission and diversity
> > statement. I will not remove the diversity clause from PEP 8011.
>
> I cannot comment on what you actually have in PEP 8011 as
> diversity clause, since the page is just a placeholder at the
> moment, but please take into consideration that we're *not* debating a
> council which is to represent the Python community or other group of
> people.
>
> The council is intended to be a technical body for steering language
> design and needs experts as members who we all trust and respect
> to make good decisions - regardless of any other criteria and,
> of course, open to all core developers, regardless of background
> (which is what the PSF diversity statement is all about).
>
> > To save us all trouble of discussing this particular issue, for those of
> > you who disagree completely, and have other ideas about how you'd like
> > Python to be governed and who should be in it, you can do one or more of
> > the following:
> >
> > - not vote on my PEP
> > - vote on the other PEPs
> > - write their own PEP
>
> I think we're grown up enough to work on these PEPs together and
> in the usual spirit of coming up with good solutions. We owe
> this to the Python community at large who will be affected by
> whatever we decide.


Correct, but since the PEP isn't ready to be published for discussion this
thread is all speculation based on imperfect information since Mariatta
tried to summarize something ahead of time.

For me personally, I am not going to participate in any discussion about
any PEP until there is a published text to refer to, otherwise the
discussion is ripe for misunderstandings. If a PEP comes out which people
disagree with and want an alternative for I'm sure we can give them an
opportunity to create a tweaked PEP (but I also assume we will have a civil
discussion first in hopes of finding consensus first).
___
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] Council / board (Was: 1 week to Oct 1)

[Donald Stufft]

> On Sep 25, 2018, at 12:24 PM, Antoine Pitrou  wrote:
> 
> 
> Le 25/09/2018 à 18:10, Guido van Rossum a écrit :
>>To save us all trouble of discussing this particular issue, for
>>those of you who disagree completely, and have other ideas about how
>>you'd like Python to be governed and who should be in it, you can do
>>one or more of the following:
>> 
>>- not vote on my PEP
>>- vote on the other PEPs
>>- write their own PEP
>> 
>> 
>> I would remind people that it's well documented that diverse group make
>> better decisions.
> 
> Can you point us to such documentation?  It would be nice to know under
> which conditions the assertion holds, according to which metrics, etc.


https://hbr.org/2016/11/why-diverse-teams-are-smarter 
 includes links to 
several studies. There are a lot more results as well to the search “diverse 
teams make better decisions” or “diverse groups decision making” on Google as 
well if those studies are lacking to you.


___
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] Council / board (Was: 1 week to Oct 1)

[Antoine Pitrou]

Le 25/09/2018 à 18:10, Guido van Rossum a écrit :
> To save us all trouble of discussing this particular issue, for
> those of you who disagree completely, and have other ideas about how
> you'd like Python to be governed and who should be in it, you can do
> one or more of the following:
> 
> - not vote on my PEP
> - vote on the other PEPs
> - write their own PEP
> 
> 
> I would remind people that it's well documented that diverse group make
> better decisions.

Can you point us to such documentation?  It would be nice to know under
which conditions the assertion holds, according to which metrics, etc.

Also, may I make the matter more concrete?  You have been the BDFL
during 20+ years.  A one-person deciding group of a single white male is
not exactly diverse.  Retrospectively, do you think this led you to take
worse decisions?

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] Council / board (Was: 1 week to Oct 1)

[M.-A. Lemburg]

On 25.09.2018 16:28, Mariatta Wijaya wrote:
> My proposal is taking into consideration The PSF's mission and diversity
> statement. I will not remove the diversity clause from PEP 8011.

I cannot comment on what you actually have in PEP 8011 as
diversity clause, since the page is just a placeholder at the
moment, but please take into consideration that we're *not* debating a
council which is to represent the Python community or other group of
people.

The council is intended to be a technical body for steering language
design and needs experts as members who we all trust and respect
to make good decisions - regardless of any other criteria and,
of course, open to all core developers, regardless of background
(which is what the PSF diversity statement is all about).

> To save us all trouble of discussing this particular issue, for those of
> you who disagree completely, and have other ideas about how you'd like
> Python to be governed and who should be in it, you can do one or more of
> the following:
> 
> - not vote on my PEP
> - vote on the other PEPs
> - write their own PEP

I think we're grown up enough to work on these PEPs together and
in the usual spirit of coming up with good solutions. We owe
this to the Python community at large who will be affected by
whatever we decide. Personal agendas should put be aside for
the time being.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Sep 25 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
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] Council / board (Was: 1 week to Oct 1)

[Guido van Rossum]

On Tue, Sep 25, 2018 at 7:28 AM Mariatta Wijaya  wrote:

> My proposal is taking into consideration The PSF's mission and diversity
> statement. I will not remove the diversity clause from PEP 8011.
>

+1


> To save us all trouble of discussing this particular issue, for those of
> you who disagree completely, and have other ideas about how you'd like
> Python to be governed and who should be in it, you can do one or more of
> the following:
>
> - not vote on my PEP
> - vote on the other PEPs
> - write their own PEP
>

I would remind people that it's well documented that diverse group make
better decisions. And given that there is a historical bias, often
unconscious, towards white men I think it's good to try to counter this
bias explicitly.

I should also think that "merit-based" criteria tend to reinforce the
existing unconscious bias.

-- 
--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] Council / board (Was: 1 week to Oct 1)

[Antoine Pitrou]

Le 25/09/2018 à 17:49, Victor Stinner a écrit :
> Le mar. 25 sept. 2018 à 13:57, Antoine Pitrou  a écrit :
>> Not sure what you mean here.  What you are asking for is routinely
>> called, AFAIK, "positive discrimination".  Please correct me if I'm wrong.
>>
>> You ask me to assume positive intent, but you are the one assuming
>> negative intent on my part...
> 
> Note: in french, we say "discrimation positive", but in english, we
> prefer "positive action".

Well, apparently it may be about British English vs. American English:
https://en.oxforddictionaries.com/definition/positive_discrimination

... which brings us back to the linguistic issues I pointed out in a
previous message.

> If anyone is interested to talk about diversity, code of conduct and
> things like that: please contact me in private.
> 
> These topics are difficult to discuss in a public space. At least, I'm
> not comfortable today to talk about them in public. There are good
> reasons why people don't talk about things like that in public.

Perhaps, but there are also good reasons why debates that lead to
governance decisions should be help publicly.

While it's ok for personal anecdotes to only be shared privately,
mandating that general debate takes place privately will only shut down
debate.

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] 1 week to Oct 1

[Antoine Pitrou]

Le 25/09/2018 à 17:54, Guido van Rossum a écrit :
> On Tue, Sep 25, 2018 at 7:11 AM Antoine Pitrou  > wrote:
> 
> I would suggest November 1st, so that nobody feels pressured.
> 
> 
> You realize that then exactly the same will happen around that date, right?

Not really.

> Have you ever been on the organizing side of a conference? Both
> paper/talk submissions and attendee registrations tend to happen
> immediately before the deadline.

I'll take your word for it.

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] 1 week to Oct 1

[Guido van Rossum]

On Tue, Sep 25, 2018 at 7:11 AM Antoine Pitrou  wrote:

> I would suggest November 1st, so that nobody feels pressured.
>

You realize that then exactly the same will happen around that date, right?

Have you ever been on the organizing side of a conference? Both paper/talk
submissions and attendee registrations tend to happen immediately before
the deadline.

I propose not to move the deadline *unless* the PEP authors ask for an
extension on the eve of Oct 1st.

-- 
--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] Council / board (Was: 1 week to Oct 1)

[Victor Stinner]

Le mar. 25 sept. 2018 à 13:57, Antoine Pitrou  a écrit :
> Not sure what you mean here.  What you are asking for is routinely
> called, AFAIK, "positive discrimination".  Please correct me if I'm wrong.
>
> You ask me to assume positive intent, but you are the one assuming
> negative intent on my part...

Note: in french, we say "discrimation positive", but in english, we
prefer "positive action".

Le mar. 25 sept. 2018 à 14:42, Giampaolo Rodola'  a écrit :
> "white men", "women", "slave"... Personally I find this tendency quite
> worrying and discriminating and frankly I don't understand what it has
> to do with a programming language nor why it's emerging only recently.
> (...)

If anyone is interested to talk about diversity, code of conduct and
things like that: please contact me in private.

These topics are difficult to discuss in a public space. At least, I'm
not comfortable today to talk about them in public. There are good
reasons why people don't talk about things like that in public.

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] [PEP 8013] The External Council Governance Model

[Steve Dower]

Here is the text of PEP 8013 for discussion and improvement (in 
isolation from the other proposals, of course -- we're not ready for the 
shoot-out yet.)


I'm keen to see the model be considered, but I don't feel the need to 
tightly control the specific content in the PEP, so feel free to send 
your own PRs if you have definitive improvements.


For the next few days I'm also going to have varying amounts of ability 
to read and respond to email. I'll try and catch up by the weekend or 
early next week.


Rendered version at: https://www.python.org/dev/peps/pep-8013/

---

PEP: 8013
Title: The External Council Governance Model
Author: Steve Dower 
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 2018-09-14

Abstract


This PEP proposes a new model of Python governance based on a Group
of Unbiased Independent Directors of Order (GUIDO) tasked with making
final decisions for the language.  It differs from PEP 8010 by
specifically not proposing a central singular leader, and from PEP
8011 by disallowing core committers from being council members. It
describes the size and role of the council, how the initial group of
council members will be chosen, any term limits of the council
members, and how successors will be elected.

It also spends significant time discussing the intended behaviour of
this model. By design, many processes are not specified here but are
left to the people involved. In order to select people who will make
the best decisions, it is important for those involved to understand
the expectations of GUIDO but it is equally important to allow GUIDO
the freedom to adjust process requirements for varying circumstances.
This only works when process is unspecified, but all participants have
similar expectations.

This PEP does *not* name the members of GUIDO. Should this model be
adopted, it will be codified in PEP 13 along with the names of all
officeholders described in this PEP.

Open Discussion Points
==

Some suggestions in this document are currently weak suggestions, and
are open to change during the discussion period. These include:

* We can change the name of the group. "Council of Auditors" is the
  suggested alternative, though "Python Inquisition" is very tempting
  if we believe we can be clear about the source of the name [1]_

* We can change voting procedures, timelines, and tie-breakage rules


The Importance of the Grey Area
===

In any actual decision-making process, there is going to be grey area.
This includes unexpected scenarios, and cases where there is no
"correct" answer.

Many process plans attempt to minimise grey area by defining processes
clearly enough that no flexibility is required.

This proposal deliberately goes the other way. The aim is to provide a
robust framework for choosing the best people to handle unexpected
situations, without defining how those people should handle those
situations.

Examples are provided of "good" responses to some situations as an
illustration. The hope is that the "best" people are the best because
they would live up to those examples. The process that is proposed has
been designed to minimise the damage that may be caused when those
people turn out not to be the best.

Grey area is guaranteed to exist. This proposal deliberately embraces
and works within that, rather than attempting to prevent it.

Model Overview
==

Key people and their functions
--

The Group of Unbiased Independent Directors of Order (GUIDO) is a
council of varying size, typically two to four people, who are elected
for the duration of a Python release. One member of GUIDO is
considered the President, who has some minor points of authority over
the other members.

GUIDO has responsibility for reviewing controversial decisions in the
form of PEPs written by members of the core development team. GUIDO
may choose to accept a PEP exactly as presented, or may request
clarification or changes. These changes may be of any form and for any
reason. This flexibility is intentional, and allows the process to
change over time as different members are elected to GUIDO. See the
later sections of this document for examples of the kinds of requests
that are expected.

GUIDO only pronounces on PEPs submitted to python-committers. There is
no expectation that GUIDO follows or participates on any other mailing
lists. (Note that this implies that only core developers may submit
PEPs. Non-core developers may write and discuss proposals on other
mailing lists, but without a core developer willing to support the
proposal by requesting pronouncement, it cannot proceed to acceptance.
This is essentially the same as the current system, but is made
explicit here to ensure that members of GUIDO are not expected to deal
with proposals that are not supported by at least one core developer.)

GUIDO may not delegate authority to individuals who have not been
elected by the core 

Re: [python-committers] Council / board (Was: 1 week to Oct 1)

[Paul Moore]

On Tue, 25 Sep 2018 at 15:28, Mariatta Wijaya  wrote:
>
> My proposal is taking into consideration The PSF's mission and diversity 
> statement. I will not remove the diversity clause from PEP 8011.
>
> To save us all trouble of discussing this particular issue, for those of you 
> who disagree completely, and have other ideas about how you'd like Python to 
> be governed and who should be in it, you can do one or more of the following:
>
> - not vote on my PEP
> - vote on the other PEPs
> - write their own PEP

Or presumably

- discuss the concerns during the debate phase of the process

?

At the moment the discussion seems to be about a possible
misinterpretation of a possible misquote of something the PEP might
end up saying. It seems like it's probably worth waiting until the
facts are clear before saying anything more. But once there's an
actual PEP (not a placeholder) in place, I assume that discussions
about the content *will* be acceptable (as long as they are reasonable
and respectful, obviously). I don't recall the expected details of the
actual process (if they've been published yet) but I don't expect them
to be simply "here's the PEPs, let's vote!".

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] Council / board (Was: 1 week to Oct 1)

[Mariatta Wijaya]

My proposal is taking into consideration The PSF's mission and diversity
statement. I will not remove the diversity clause from PEP 8011.

To save us all trouble of discussing this particular issue, for those of
you who disagree completely, and have other ideas about how you'd like
Python to be governed and who should be in it, you can do one or more of
the following:

- not vote on my PEP
- vote on the other PEPs
- write their own PEP
___
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] 1 week to Oct 1

[Antoine Pitrou]

Le 25/09/2018 à 16:07, Barry Warsaw a écrit :
> On Sep 24, 2018, at 14:32, Mariatta Wijaya  wrote:
>>
>> 1. Is everyone still ok with the Oct 1 as deadline for coming up with 
>> governance PEPs?
> 
> I’m afraid that I may not be, actually.  I expected to have time to work on 
> my PEP while I was on leave for my son’s wedding, but y’know, family! :)  
> Mariatta and I are collaborating a bit on 8011, but I haven’t really had time 
> to work on 8010.  I don’t want to push it back too far, but a couple of weeks 
> would really help.

I would suggest November 1st, so that nobody feels pressured.

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] 1 week to Oct 1

[Barry Warsaw]

On Sep 24, 2018, at 14:32, Mariatta Wijaya  wrote:
> 
> 1. Is everyone still ok with the Oct 1 as deadline for coming up with 
> governance PEPs?

I’m afraid that I may not be, actually.  I expected to have time to work on my 
PEP while I was on leave for my son’s wedding, but y’know, family! :)  Mariatta 
and I are collaborating a bit on 8011, but I haven’t really had time to work on 
8010.  I don’t want to push it back too far, but a couple of weeks would really 
help.

-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] Council / board (Was: 1 week to Oct 1)

[Giampaolo Rodola']

On Tue, Sep 25, 2018 at 1:52 PM Mariatta Wijaya  wrote:
>
> > * Mariatta proposed to require to have a least one woman in that
> > council.
>
> > Why stop at women?
>
>
> My actual wording was: "not all white men", which actually means quite 
> different from "must include one woman".
>
> I don't appreciate you jumping straight to accusing me for discrimination. 
> Assume positive intent, and ask for clarity before scrutinizing and making 
> accusations.

"white men", "women", "slave"... Personally I find this tendency quite
worrying and discriminating and frankly I don't understand what it has
to do with a programming language nor why it's emerging only recently.
Whoever ends up in the council, approves a PEP, writes a patch, merges
a PR... I think that person should be elected based *entirely* on
their merits, not because of their gender or skin color. Electing
someone just to represent a minority doesn't have anything to do with
IT and cannot lead to a good outcome in the long run IMHO.
--
Giampaolo - http://grodola.blogspot.com
___
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] Council / board (Was: 1 week to Oct 1)

[Antoine Pitrou]

Le 25/09/2018 à 13:52, Mariatta Wijaya a écrit :
> I don't appreciate you jumping straight to accusing me for
> discrimination. Assume positive intent, and ask for clarity before
> scrutinizing and making accusations.

Not sure what you mean here.  What you are asking for is routinely
called, AFAIK, "positive discrimination".  Please correct me if I'm wrong.

You ask me to assume positive intent, but you are the one assuming
negative intent on my part...

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] Council / board (Was: 1 week to Oct 1)

[Mariatta Wijaya]

> * Mariatta proposed to require to have a least one woman in that
> council.

> Why stop at women?


My actual wording was: "not all white men", which actually means quite
different from "must include one woman".

I don't appreciate you jumping straight to accusing me for discrimination.
Assume positive intent, and ask for clarity before scrutinizing and making
accusations.

My PEP will provide guideline on how members of the group should be
nominated, and it is a long list. It will not name names. Only once the PEP
has been accepted that people can nominate folks to fill the role, and
there will be another round of voting.

Some of the questions asked by Victor will be answered in the PEP that I'm
writing, so I will not answer now.
___
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] Council / board (Was: 1 week to Oct 1)

[Antoine Pitrou]

Hi,

Le 25/09/2018 à 12:14, Victor Stinner a écrit :
> 
> Since there are no concrete PEPs, I don't know where I should post my
> comments. I decided to send them here :-)
> 
> For the new council/board idea (group of 3 or 5 peoples):
> 
> * Can we require that each people comes from a different company? At
> least, require that no all of them work for the same company. I would
> mean that a member of this council would have to nominate someone else
> if they decide to move to a different company which already has ("too
> many") council members.

The details must be ironed out, but that sounds like a good idea.  There
were routinely concerns about  influencing the Python
development process.  Once it was Google, nowadays it seems to be Microsoft.

(admittedly, Google probably didn't influence us very much in the end,
but I'm not sure it's because we are immune to such a danger, rather
than Python simply not being an attractive target enough, as opposed to
e.g. Go or Javascript)

> * Mariatta proposed to require to have a least one woman in that
> council. What do you think of this idea? Honestly, I have no opinion
> yet, since I don't think this idea has been discussed enough yet. I
> would expect that only core developers could join the council and
> right now, there are 4 women core developers: Mariatta, Carol, Emily,
> Lisa.

Why stop at women?  There are many underrepresented groups.  You could
discriminate based on gender, skin colour, nationality, socio-economic
origins, etc.

The main problem, though, is we are talking about a very little group
chosen amongst a likely very small number of candidates (I don't expect
more than a dozen candidates, two dozens at most).  If you start doing
positive discrimination amongst such a small number of people, you
disrupt the democratic process (by which I mean voting) a *lot*.

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] 1 week to Oct 1

[Victor Stinner]

Hi,

Since there are no concrete PEPs, I don't know where I should post my
comments. I decided to send them here :-)

For the new council/board idea (group of 3 or 5 peoples):

* Can we require that each people comes from a different company? At
least, require that no all of them work for the same company. I would
mean that a member of this council would have to nominate someone else
if they decide to move to a different company which already has ("too
many") council members.

* Mariatta proposed to require to have a least one woman in that
council. What do you think of this idea? Honestly, I have no opinion
yet, since I don't think this idea has been discussed enough yet. I
would expect that only core developers could join the council and
right now, there are 4 women core developers: Mariatta, Carol, Emily,
Lisa.

By the way, what's the process if someone wants to leave this council?
Does they have to nominate someone? Or should we organize a new vote
open to new candidates? I'm not sure that we decided how long members
should stay in the council. I like the idea of a fixed duration. Or
maybe align it to a release. For example, usually a development cycle
takes 18 months. Maybe it's a good fit? A full release cycle allows to
implement some ideas. Obviously, some ideas require multiple cycles,
so maybe some candidates would like to reapply for the next cycle to
continue their projects?

Victor
Le mar. 25 sept. 2018 à 09:40, Victor Stinner  a écrit :
>
> I wanted to read these 4 PEPs:
>
> Le lun. 24 sept. 2018 à 20:32, Mariatta Wijaya
>  a écrit :
> > - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process
> > - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model
> > - https://www.python.org/dev/peps/pep-8011 The Council Governance Model 
> > (I'm claiming this PEP)
> > - https://www.python.org/dev/peps/pep-8012 The Community Governance Model
>
> All of them are empty.
>
> > 1. Is everyone still ok with the Oct 1 as deadline for coming up with 
> > governance PEPs?
>
> It doesn't make sense to me:
>
> * Nothing explains how we take a decision: PEP 8001 is empty
> * Governance PEPs are empty: how are we supposed to take a decision on
> an empty PEP?
>
> > 2. How do we discuss these PEPs?
>
> I suggest to use emails as we did previously, but only on
> python-committers. If someone wants to change that, I suggest to wait
> after the new governance is decided.
>
> 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] CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[M.-A. Lemburg]

On 21.09.2018 14:59, Paul Moore wrote:
> Balance, forgiveness, and a mature level of empathy are what's
> *really* needed ("among the things that are needed...":-)). Not
> policies. Policies should be weapons of last resort.

Agreed.

I guess we'll also have to learn that flamebait as we had it in the
old days is now often launched as cocbait.

It'll take some time to get used to this, but we'll have to try
not to fall for it.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Sep 25 2018)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
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] 1 week to Oct 1

[Victor Stinner]

I wanted to read these 4 PEPs:

Le lun. 24 sept. 2018 à 20:32, Mariatta Wijaya
 a écrit :
> - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process
> - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model
> - https://www.python.org/dev/peps/pep-8011 The Council Governance Model (I'm 
> claiming this PEP)
> - https://www.python.org/dev/peps/pep-8012 The Community Governance Model

All of them are empty.

> 1. Is everyone still ok with the Oct 1 as deadline for coming up with 
> governance PEPs?

It doesn't make sense to me:

* Nothing explains how we take a decision: PEP 8001 is empty
* Governance PEPs are empty: how are we supposed to take a decision on
an empty PEP?

> 2. How do we discuss these PEPs?

I suggest to use emails as we did previously, but only on
python-committers. If someone wants to change that, I suggest to wait
after the new governance is decided.

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/