[python-committers] Re: Making it easier to track who is currently considered "active" for voting

[Nathaniel Smith]

How are you measuring "activity"? Just commits?

On Tue, Oct 20, 2020 at 12:16 PM Brett Cannon  wrote:

> With the next SC election fast approaching, I did the final tweaks I
> wanted to make to the voters repo to address visibility issues we had in
> the last election.
>
> First, there is now a monthly cron job that will run at
> https://github.com/python/voters/actions?query=workflow%3A%22Projected+Voter+Roll%22
> which will project a Dec 01 vote and then calculate who would fall off the
> voter roll based solely on activity, who would be added, and then the full
> list of voters. What that means is the two year of activity is calculated
> back from the next Dec 01, so you can check to see if you haven't committed
> or authored code in that timeframe to automatically be put on the voter
> roll.
>
> Second, I created
> https://github.com/python/voters/actions?query=workflow%3A%22Generate+Voter+Roll%22
> for manually creating the voter roll. This means people can manually
> trigger the same code used to create the initial voter roll and see who
> would (not) be automatically placed on it. I expect this to mostly be used
> by the folks running the election. And I do advise specifying the full date
> as the input instead of using the MM-DD shortcut if you choose today as it
> will most likely wrap around to projecting a vote next year.
>
> Finally, I updated the data to include when someone left the core team
> (and if someone was ejected, which is a term from PEP 13). For those that
> never entered a GitHub username, I implicitly put them as having left the
> team the day the first PR was merged on GitHub since they stopped being
> able to participate actively from that day forward with an appropriate note
> as to why (2017-02-10). This is now shown in the developer log at
> https://devguide.python.org/developers/.
>
> Hopefully this is enough to easily check if one should try to get a quick
> PR committed and/or authored before an election. We can all also try to
> remember to include it in the vote announcement email going forward if
> anyone forgets.
> ___
> python-committers mailing list -- python-committers@python.org
> To unsubscribe send an email to python-committers-le...@python.org
> https://mail.python.org/mailman3/lists/python-committers.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-committers@python.org/message/DLJE25TWAQ2KBGVJUSUO4W7KSZYHFFVC/
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>


-- 
Nathaniel J. Smith -- https://vorpus.org 
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/VEOL3LDT6YNUTGPAYXYT776X7QZ5DNFY/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: MSDN Subscription renewals

[Nathaniel Smith]

On Thu, Aug 13, 2020 at 11:04 AM Zachary Ware  wrote:
>
> On Thu, Aug 13, 2020 at 12:29 PM Steve Dower  wrote:
> > While most of the tooling necessary for working on CPython is freely
> > available (as Visual Studio Community), this will also include OS images
> > and Azure credits.
>
> For reference, the Azure credit has been enough to me to run a Windows
> 8.1 buildbot for the past several years at no cost to me.

Yeah, it's pretty substantial ($150/mo). The subscription also comes
with multiple free licenses for every version of Windows, which is
incredibly useful if you have a Mac or Linux system but need to spin
up a Windows dev VM.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/L5WNAXNYPYPF3JCKKXFHCFYULOC6DB6V/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Nathaniel Smith]

On Thu, Jul 23, 2020, 05:46 Donald Stufft  wrote:

>
>
> On Jul 23, 2020, at 3:52 AM, Matthias Klose  wrote:
>
> Apparently there was agreement to hide this kind of information, and that's
> worse than the original behavior that was acted on. Who will be next? For
> what
> reason?  I am not questioning the decision, at least we voted for our
> delegates,
> so I have to respect that decision even if I would disagree.  If you don't
> want
> to communicate in public, then email committers separately, or create a
> private
> ML for committers.
>
>
>
> I don’t think it’s unreasonable to allow the core developer the chance to
> come back in 3 months without all of their “colleagues” (for lack of a
> better word), knowing they’ve had disciplinary action taken against them.
>

The problem with this reasoning is, the disciplinary action was for things
the core developer did *to* those colleagues, in public.

Imagine two hypothetical scenarios: in both of them, you're at work, and
you see one of your co-workers punch another in the face. Then, in scenario
1, management makes an announcement that people shouldn't punch each other,
and that the offender has been disciplined. In scenario 2, as far as you
know, management doesn't do anything.

In which scenario are you going to find it easier to work with that
colleague in the future? The one where you know that they've learned
something about appropriate behavior and that if they repeat what they did
before there will be consequences, or the one where they "have the chance"
to pretend that everything was fine and that punching co-workers is totally
cool and consequence-free?

I'm all for CoC violators having the chance to make amends and come back,
but the most effective way to do that is to acknowledge the problem and,
well, make amends, not sweep things under the rug.

-n
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/XRXY2AVZJLRQZ4JVRORFCAX656SMGJDE/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Nathaniel Smith]

On Thu, Jul 23, 2020, 05:25 Jack Diederich  wrote:

> I'm sorry we had to ban Guido for three months but maybe he'll learn his
> lesson and not merge commit messages that include screeds about "relics of
> white supremacy".
>

I'm guessing there's some layers of irony or sarcasm in this message, but
I'm definitely not able to unpack them, and I think it's spectacularly
inappropriate regardless. Maybe you're only joking when you say Guido is at
fault here, and maybe you're only joking when you act like the problem with
white supremacy is people mentioning the existence of white supremacy. I
don't know. I hope so, because both statements are completely false. But
there are certainly plenty of people who think both those things, so it
doesn't work as a joke.

I would forward this post to the conduct-wg, but Jack's already cc'ed them
himself.

I think this interchange illustrates why we need some clearer statements
from the conduct-wg when you all have a chance. Obviously Jack and I still
have very different ideas about what's appropriate here. Does the
conduct-wg in fact consider mentions of white supremacy to be a violation
of the CoC? I hope not, but I just don't know.

-n

>
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/XGTSOCUIHTVCGANA2GSOAHWW2O4MGW75/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: Notification of a three-month ban from Python core development

[Nathaniel Smith]

Given that this is a response to behavior in public mailing list
posts, the lack of specificity feels off to me. Whatever this person
did is already public. What's being hidden isn't their behavior; it's
the conduct-wg/steering-council's reasoning for banning them. The
point of having a CoC is that everyone is on the same page and can be
confident about what behavior is unacceptable and acceptable, but it's
hard for them or others to learn from this, if you don't tell them or
us why they were banned...
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/22464N65TVY4UVECNZ3LL3YUD72S5C3C/
Code of Conduct: https://www.python.org/psf/codeofconduct/

[python-committers] Re: The Night’s Watch is Fixing the CIs in the Darkness for You

[Nathaniel Smith]

On Fri, Apr 3, 2020 at 11:32 AM Victor Stinner  wrote:
> I had to update the OpenSSL version in the CI configuration which
> lives in the same Git repository than Python code base. Since our CI
> currently runs on unmodified PRs, maybe the 1090 pending pull requests
> must now be rebased manually on the master branch to get these CI
> configuration updates. Otherwise, the CI would fail which prevents to
> merge a PR. I'm not sure at this point.

In general CI systems run on merge(PR-head, target-branch-head),
rather than directly on PR-head. So this may not be an issue at all.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list -- python-committers@python.org
To unsubscribe send an email to python-committers-le...@python.org
https://mail.python.org/mailman3/lists/python-committers.python.org/
Message archived at 
https://mail.python.org/archives/list/python-committers@python.org/message/WEZGVOFIBKPO357UGNFLC2I3Y3NFKWPI/
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] [Python-Dev] PEP 581 (Using GitHub issues for CPython) is accepted

[Nathaniel Smith]

On Mon, May 20, 2019 at 9:05 PM Xiang Zhang  wrote:
>
> Also, Github has just changed its export control. As an international team, 
> does it affect us and PEP581? Maybe better consult the lawyer first?
>
> http://help.github.com/en/articles/github-and-export-controls

From a quick non-expert read, that document seems to say that
github.com is subject to the same export control laws as every other
US company, but they don't do much to enforce them. ("Users are
responsible", "Github.com has not been audited", etc.) Can you give
any more details? You said something changed – what was it? Is there a
reason to think that github is different in this respect from any
other platform we might use, including self-hosting? (For better or
worse, the PSF is also a US corporation subject to US law...)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Can we choose between mailing list and discuss.python.org?

[Nathaniel Smith]

On Thu, Feb 14, 2019, 09:39 Brett Cannon 
>
> On Wed, Feb 13, 2019 at 12:17 PM Paul Moore  wrote:
>
>> On Wed, 13 Feb 2019 at 19:56, Steve Dower  wrote:
>> >
>> > On 13Feb2019 1112, Brett Cannon wrote:
>> > >
>> > >
>> > > On Wed, Feb 13, 2019 at 2:55 AM Paul Moore > > > > wrote:
>> > >
>> > > On Tue, 12 Feb 2019 at 22:00, Antoine Pitrou > > > > wrote:
>> > >  > Here is a 161-message Discourse thread (at the time of this
>> writing):
>> > >  > https://discuss.python.org/t/pep-517-backend-bootstrapping/789
>> > >
>> > > As someone directly involved in that discussion, with a strong
>> need to
>> > > understand all of the points being made, that's a great example of
>> > > both the benefits and the flaws of the discourse model.
>> > >
>> > >
>> > > Can I ask if that entire thread is on topic, or is there a reasonable
>> > > point in that discussion where side conversations could have been
>> broken
>> > > off into a separate topic(s)? When email threads tend to reach that
>> > > length there have been side discussions that could have become their
>> own
>> > > topic if someone thought to change the subject and Discourse allows
>> for
>> > > having an admin break posts off at any point and I'm curious if it
>> would
>> > > have been helpful and people simply didn't think about it (I know I
>> > > don't always think of it immediately yet).
>> >
>> > My feeling (as I followed the entire discussion from the start) is that
>> > the side discussions all tied back, rather than diverging permanently.
>> > So at best it would be "you 2-3 go and discuss this part separately and
>> > come back when you agree", which as we know is often followed up by "you
>> > other 2-3 re-discuss everything they already discussed since you weren't
>> > part of the side discussion".
>>
>> Precisely this. I don't know *how* I would have split off a separate
>> sub-thread in Discourse if needed (it's easy enough in email by
>> changing the subject, I presume it's not much harder in Discourse?)
>>
>
> Nope, it's not hard. The process is:
>
>1. An admin notices/is asked to split a topic that has diverged
>2. The admin clicks the wrench icon and chooses to Select Posts
>3. You select posts either manually, post + all following, or post +
>all replies
>4. You then have the option to create a new topic for the selected
>posts, specifying category, title, labels, etc.
>
> The pro to this compared to subject changing in an ML is it's retroactive.
> The con is an admin needs to to it, but you can always @ mention 'admins'
> -- maybe 'staff' group has the same abilities? -- to bring a thread to
> their attention that needs splitting.
>

Apparently you don't actually need an admin to do this – any user with
"trust level 4" can do it:
https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/

That includes admins and moderators, but we can also promote as many people
as we want to that level, and they don't have to sign up for moderator work
or count against our staff account cap.

-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] Draft ballot text

[Nathaniel Smith]

Oh yeah, one odd thing I noticed: according to PEP 8001, the vote runs
from Dec. 1 to Dec. 16, i.e., two weeks + two days. Is this...
intentional? Of course 16 is a good round number, but it still seemed
strange. Maybe it's supposed to give us a little wiggle room in case
the vote doesn't get sent out right at midnight on the 1st, while
still keeping the two week period?

-n
On Thu, Nov 29, 2018 at 8:03 PM Nathaniel Smith  wrote:
>
> Hi all,
>
> Since the vote's supposed to be starting in a few days, I figured it
> would be good to finish up the fiddly details and avoid any
> last-minute editing. So here's a draft proposal for the ballot
> instructions and options: https://github.com/python/peps/pull/844
>
> I also set up a test vote on CIVS, so you can see how it will actually
> look: 
> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_f3dd3ec110515d32&akey=add219018ca56843
>
> Please post any feedback on the PR or here.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org



-- 
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] Draft ballot text

[Nathaniel Smith]

Hi all,

Since the vote's supposed to be starting in a few days, I figured it
would be good to finish up the fiddly details and avoid any
last-minute editing. So here's a draft proposal for the ballot
instructions and options: https://github.com/python/peps/pull/844

I also set up a test vote on CIVS, so you can see how it will actually
look: 
https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_f3dd3ec110515d32&akey=add219018ca56843

Please post any feedback on the PR or here.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] A plea to stop last-minute changes to governance PEPs

[Nathaniel Smith]

On Mon, Nov 19, 2018 at 5:30 AM Paul Moore  wrote:
> My feeling, however, is that the PEPs that are having the most trouble
> with this are the ones that are trying to pin down too much detail.
> Sure (to pick a random example), it's ultimately going to be important
> that a council have a clear idea of how they reach agreement on
> banning a core developer, should that situation come up. But is it
> really going to be so critical to establish that detail *right now*
> that someone would change their vote **to a completely different
> governance model** if the number of votes was set at 3 or 4? And is
> the proposal explicitly denying us the chance to change that number
> based on experience going forward?[1]

PEP 8016 does try to specify all the details needed to get us out of
our current state of ambiguity, so that if we adopt it then we're
ready to go immediately and never have to go back to our current
ill-defined process. That forces it to specify various details, but
beyond that it tries to specify as little as possible (so lots of
details are delegated to the future governance system, rather than
being resolved right now), and for the things that it does specify, it
also specifies how we can change them:
https://www.python.org/dev/peps/pep-8016/#changing-this-document . So
we can totally change things going forward.

If the PEP left blank spaces to be filled in later, then when would we
fill them in, and how? Are you imagining we'd have a second round of
voting to fill in the details, or what are you thinking?

> I realise this is precisely the point you made about subjectivea way to 
> change those details – see
> judgements, but I think it needs to be taken in context. I have a
> maximum of 7 proposals to choose from (6 if Steve withdraws his). I'm
> interested in the overall "shape" of the proposal (leader or group who
> decides vs community voting for example) and the "tone" (is it
> concerned with pinning down lots of details, does it assume we'll
> trust each other to work in good faith, is it bureaucratic, is it
> well-established or novel, etc). The sorts of changes you're talking
> about in the examples you give mostly leave me with a feeling of "this
> proposal is prone to getting bogged down in details, it's
> overspecified", and that's what will affect my vote rather than the
> actual detail being debated[2].

Well, that's up to you I guess :-). None of the bureaucratic details
in PEP 8016 have anything to do with day-to-day development, and for
uncontroversial decisions, governance doesn't matter at all. The only
time a governance PEP matters is when we hit an ambiguous situation
where people are disagreeing. IMO that means the governance probably
shouldn't leave the details ambiguous and assume people will agree on
how to handle them :-).

But that's kind of neither here nor there... even if you disagree with
me about that, I hope we can still agree on one thing:

> > - In the course of a discussion that Paul Moore started about
> > processes for promoting core devs, I realized [5] that there's (what
> > feels to me like) a substantial ambiguity in PEPs 8010 and 8011 about
> > how much power the Technical Leader or Trio would actually have –
> > specifically I'd been assuming one thing, but realized that the texts
> > actually don't say either way. I hope Barry and Mariatta will clarify
> > what they intended before the vote starts. No matter which way they
> > clarify things, it may feel like a substantive change to some people,
> > depending on how they read it originally.
>
> And yet, I hope they don't, as a key point for me about their
> proposals is that they *don't* try to specify everything up front, but
> rather they allow for the leader/council to make judgements as time
> goes on. If you feel that as a result their proposals are
> underspecified, by all means vote for something else.

If you're right that Barry's intent for PEP 8010 is to make it a kind
of "template" for a future governance PEP, with details intentionally
left underspecified to be filled in later by some yet-to-be-determined
process, then it would still be helpful for him to specify *that*.
That would give us both the information we need to vote :-).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] A plea to stop last-minute changes to governance PEPs

[Nathaniel Smith]

On Sun, Nov 18, 2018 at 3:17 AM Antoine Pitrou  wrote:
> A couple days ago Nathaniel pushed significant changes to his governance
> PEP (PEP 8016).  This means some governance PEPs are apparently still
> *not* finalized.  This raises a problem: when can we consider that we
> are reading the final version of a proposal (barring wording fixes or
> improvements), not some work in progress draft?

There were several PEPs that received significant changes in the week
before Nov 16 when the "review period" started (at least 8001, 8014,
8015, 8016), but AFAICT none of the PEPs have had any changes since
then.

> Not everyone keeps an eye daily on PEP changes and discussions.  It
> would be nice to be able to make one's mind at an idle pace.  But that
> requires that PEP authors don't make last-minute changes in an attempt
> to gather more support.

Thanks for raising this. It's an important issue and one where I've
been struggling too.

I'll put my conclusion first. My suggestion:

- We do allow changes to the PEPs until the actual voting starts, but
not afterwards
- We leave it up to the PEP authors' judgement what changes they want to make
- The PEP authors will work together to maintain a single shared
changelog summarizing every change that's made to the PEPs after Nov.
16, no matter how trivial, and including links to the relevant commits
so you can easily see the actual text
- We'll include a link to this changelog prominently in the voting
instructions etc.

This is easy to implement, avoids messy subjective judgements about
which changes are "too big", allows the PEPs to be tweaked and
clarified through the review period, and would mean that so long as
you read the PEPs at least once during the review period and then
check the changelog before voting, you're guaranteed that you won't
miss anything.

Here's my reasoning:

You're absolutely right, it's crucial that everyone know what they're
voting on; that's basic to having a valid vote. (And I almost got
bitten by this too – PEP 8014 changed a lot on Nov. 9, and it was only
by random chance that I noticed it a week later!) But... right now
people are still reading the proposals for the first time and
requesting changes. And if someone's suggestion would be an actual
improvement, and we turn it down because it's too late – that's
disenfranchising in a different way, and also, like, deliberately
choosing to make our governance worse than necessary, which is
sub-optimal. Obviously once the vote starts we *can't* change the
PEPs, because that would retroactively change the meaning of votes
that were already cast. But until then, freezing and not freezing both
make me really uncomfortable. It would be good if we could find a
third way.

To make this concrete, here are some examples of things people have
brought up re: PEP 8016 since Nov. 16, where I'm not sure what we
should do:

- Xiang Zhang noticed [1] that PEP 8016 uses a piece of nonstandard
terminology: "strict majority" where it means "simple majority". Oops.
I feel like fixing this is probably a good idea, and as
uncontroversial as any change could be? But OTOH if we don't have a
changelog then even trivial changes like this might make you and
others uncomfortable (they make me uncomfortable!), because without
seeing the change we have no way to judge for ourselves how trivial it
actually is.

- Xiang Zhang and Victor Stinner are arguing [1, 2] for changing PEP
8016 to effectively require a slightly higher threshold for the
steering council to block a new core developer for misconduct
(4-out-of-5 instead of 3-out-of-5, see [3] for the details). This is a
small tweak in a corner of the proposal we hope will never come up in
practice, and it definitely wouldn't change the proposal's overall
character, but it is a change. It would produce some procedural
simplifications, and apparently make at least two core devs more
comfortable. Is that something we should do?

- Steve Dower has suggested [4] tweaking when in the release cycle the
steering council election is held. This discussion isn't resolved yet,
maybe we'll conclude it's a bad idea anyway, but OTOH maybe it would
be an improvement? And again it's a super-tiny change.

It's possible PEP 8016 is particularly prone to this because a design
goal was to be small and explicit enough to encourage
nitpickingdetailed review, but I'm not just suggesting this
because "my" PEP has special needs. Other potential changes I'm aware
of:

- Steve Dower is considering withdrawing PEP 8014 entirely [4], which
if it happens would be a major substantive change to PEP 8014 that
voters would want to know about!

- In the course of a discussion that Paul Moore started about
processes for promoting core devs, I realized [5] that there's (what
feels to me like) a substantial ambiguity in PEPs 8010 and 8011 about
how much power the Technical Leader or Trio would actually have –
specifically I'd been assuming one thing, but realized that the texts
actually don't say either wa

[python-committers] Straw poll: Which governance proposals do you like best?

[Nathaniel Smith]

There's been a lot of clarification and critique for individual
governance proposals, but not a lot of discussion of how they compare
to each other or what different core devs think is important. And I
know that for complicated issues like this, I often don't understand
the trade-offs until I talk them over with other people, so I'm pretty
nervous about voting without having that discussion!

I started a poll on the discourse to get a sense of what people are
thinking, and talk it through. Please join us!

https://discuss.python.org/t/straw-poll-which-governance-proposals-do-you-like-best/436

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Timeline to vote for a governance PEP

[Nathaniel Smith]

On Sun, Nov 4, 2018 at 10:53 AM, Paul Moore  wrote:
> As one example of my confusion here,
> https://www.python.org/dev/peps/pep-8016/ is currently a 404.

Sorry about that – there's a thread here with background:

https://discuss.python.org/t/working-discussion-for-pep-8016-the-boringest-possible-steering-council-model/333

And the PR to add it is here:
https://github.com/python/peps/pull/827

So it should be available on python.org soon.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Timeline to vote for a governance PEP

[Nathaniel Smith]

On Fri, Nov 2, 2018 at 8:40 PM, Victor Stinner  wrote:
> The PEP 8001 is not trivial, it expects a specific format:
>
> **DO NOT LEAVE ANY BRACKETS BLANK!**
> **DO NOT REPEAT A RANKING/NUMBER!**
>
> Maybe it would help to have a script to validate my own vote? (Also
> ensure that all choices are present?)

I'm not sure what the motivation for those restrictions is. I guess
with IRV there isn't an obvious way to handle a repeated number, but
with Condorcet it's no problem. And both methods are fine with leaving
some options blank (it's equivalent to ranking the blank options as
tied for dead last).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] python-committers is dead, long live discuss.python.org

[Nathaniel Smith]

On Sat, Sep 29, 2018 at 1:53 AM, Nick Coghlan  wrote:
> This is exactly the kind of arbitrary decision making by an insufficiently
> representative group that led to us banning making any binding decisions at
> language summits: their in-person nature means that they're inherently
> exclusive environments that lead to requirements being overlooked and
> decisions being made without involving most of the people affected.

Did you see Brett's email here, especially the last few paragraphs?

https://mail.python.org/pipermail/python-committers/2018-September/006100.html

I don't know how the Discourse experiment will turn out, and I know it
won't make everyone happy, but I hope it works. Because we *know* that
what we're doing now is making people miserable and driving them away.
The push to try Discourse may or may not be misguided, but it's not
coming out of a few people having a whim over lunch together.

-n

P.S.: I found that link using my usual method for finding mailing list
archive links, which is: first I did a search in my local MUA, found
the email I wanted, noted the date, then manually went to the mailing
list archives and clicked through the messages around that date until
I found it. This *sucks*.

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] python-committers is dead, long live discuss.python.org

[Nathaniel Smith]

On Sat, Sep 29, 2018 at 1:51 AM, Serhiy Storchaka  wrote:
> 29.09.18 03:45, Łukasz Langa пише:
>>>
>>> On 28 Sep 2018, at 23:04, Serhiy Storchaka  wrote:
>>
>> Do you use NNTP? Like with IRC, you won't find the next generation of core
>> developers on it. And no, there is no support for it in Discourse.
>
>
> Yes, I do. I read all Python-related mailing list via the Gmane gate. It is
> convenient in case of large discussions, when I can read selected branches
> and ignore others. The great advantage of NNTP is that it provides access to
> past discussions. I can read Python-Dev discussions back from 1999.

The reason the general public has settled on web forums rather than
mailing lists is basically that web forums give you many of the
advantages of NNTP -- including first-class access to archives,
replying to threads that predate your arrival, muting topics, the
ability to skim the topic list before downloading everything, etc. --
without the need to install specialized software. Of course it's not
going to be the same as your favorite NNTP client that you've spent a
decade tweaking, but it might be worth giving it a try?

That said, there is this:

  https://github.com/sman591/discourse-nntp-bridge

No idea how usable it is in practice, but apparently it works for at
least one person...

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] 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] Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)

[Nathaniel Smith]

On Thu, Sep 20, 2018 at 3:35 PM, Ethan Furman  wrote:
> And I have to argue against his use of the n-word* as being part of the
> reason -- he wasn't calling anybody that, he was using the word as an
> example of a taboo in one culture that is not in others.  Using that as part
> of the reason to ban him helps me understand the sentiment voiced at the
> sprints of the feeling that the CoC is a weapon waiting to shoot us down.

But using that word, even with quote marks around it, *is* a serious
taboo in American culture. And partly this is because "white person
who finds convoluted excuse to use the n-word" is such a cliche that
the affected folks have given up with arguing about it and just don't
want to hear it anywhere, in or out of quotes, with or without an
excuse attached. There's no reservoir of good-faith left to fall back
on.

Now sure, that taboo is an American thing, and I wouldn't support
automatically banning someone who used it in genuine ignorance, was
repentant when they realized what they'd done, etc. Context absolutely
matters. But in context here it's clear that Jacco knew perfectly well
that he was violating a taboo, and I can't read his usage as anything
but an intentional provocation. Especially when combined with all the
other things in his email.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel

[Nathaniel Smith]

Congratulations!

On Fri, Sep 14, 2018, 12:29 Raymond Hettinger 
wrote:

> At the developer sprints this week, we collectively decided to grant core
> committer status to Emily and Lisa.
>
> Please join me in welcoming them to the team.
>
>
> Raymond
>
>
> ---
>
> Emily is the Director of Engineering at Cuttlesoft. She has previously
> attended two Language Summits and three core development sprints at PyCon.
> Since July, Emily has worked with Guido's guidance to implement PEP 572,
> Assignment Expressions.  She has also worked with Eric Snow to dive into
> CPython's runtime as well as subinterpreters.  This year at PyCon she gave
> a talk on Python's AST.  Here is her speaker bio
> https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk
> video: https://www.youtube.com/watch?v=XhWvz4dK4ng
>
> Lisa has a background in network engineering and supported the Cisco sale
> engineer team to develop high quality Python product demonstrations.  Later
> she moved to the Facebook security team.  This is her third core developer
> sprint.  She and Guido are co-authors of PEP 526, Syntax for Variable
> Annotations. Last year, she worked with Eric Smith on PEP 557, Data
> Classes. Here is her speaker bio
> https://us.pycon.org/2018/speaker/profile/824/  and a link to her Pycon
> talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and
> https://www.youtube.com/watch?v=ww1UsGZV8fQ
> ___
> 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] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Nathaniel Smith]

I'm sorry, I seem to have accidentally licked a cookie [1] here. I'm still
keen to see this happen and to be a part of it, and have been trying to be
find the spoons to take the lead on organizing, but it's been a few weeks
now and that hasn't happened yet [2].

Does anyone else want to take the lead here? A number of people have
expressed interest in helping or in making introductions to other
communities, and I think the next step would be to organize some kind of
kick off meeting to rough out an outline and start divvying up work.

-n

[1] http://communitymgt.wikia.com/wiki/Cookie_Licking
[2] not to go into too many details, but basically I'm currently sick,
unemployed, and broke, which isn't a crisis but sorting it out is sucking
up a lot of energy.

On Jul 13, 2018 04:31, "Nathaniel Smith"  wrote:

On Thu, Jul 12, 2018 at 6:35 PM, Łukasz Langa  wrote:
> I'm +1 to an Informational PEP around the state of the art in project
governance.

I think this is a great idea. There's a lot of experience out there on
different governance models, but of course any given project only uses
one of them, so knowledge about what works and what doesn't is pretty
fragmented across the F/OSS community. And this is a really important
decision for us and our users, so we should do due diligence. For
example, we should think this through at least as carefully as we
thought through Github vs. Gitlab :-). A PEP is a good format to start
doing that.

I volunteer to co-author such a PEP. But I'm not up to doing it on my
own. So... who else wants to be a co-author? (I'm not going to
pressure anyone, but Brett, Mariatta, and Carol, please know that your
names were the first ones that jumped to my mind when thinking about
this :-).)

What I'm thinking:

- While this might eventually produce some recommendations, the
immediate goal would just be to collect together different options and
ideas and point out their trade-offs. I'm guessing most core devs
aren't interested in becoming experts on open-source governance, so
the goal here would be to help the broader community get up to speed
and have a more informed discussion [1].

- As per the general PEP philosophy, I think this is best done by
having some amount of general discussion on
python-dev/python-committers, plus a small group of coauthors (say 2-4
people) who take responsibility for filtering ideas and organizing
them in a coherent document.

- Places where we'll want to look for ideas:
  - The thread already happening on python-committers
  - Whatever books / articles / blog posts / etc. we can find (e.g. I
know Karl Fogel's Producing OSS book has some good discussion)
  - Other major projects in a similar position to CPython (e.g.,
node.js, Rust) -- what do they do, and what parts are they
happy/not-happy about?
  - Large Python projects (e.g. Django) -- likewise

If you have suggestions for particularly interesting projects or
excellent writing on the topic, then this thread would be a good place
to mention them.

-n

[1] The NumPy project has put a lot of energy into working through
governance issues over the last few years, and one thing that
definitely helped was coming up with some "assigned reading" ahead of
the main sprint where we talked about this. NumPy's problems are/were
pretty different from CPython's, but I'm imagining this PEP as filling
a similar role.


-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Reminder of BDFL succession timeline + CFP

[Nathaniel Smith]

On Wed, Aug 1, 2018 at 12:41 PM, Mariatta Wijaya
 wrote:
> Since this is like a CFP I figured we should clarify what's expected the
> proposal, and I also wanted to be more detailed in the timeline.
>
> Oct 1 00:00:00 UTC: Deadline of coming up with proposals of governance
> model.
>
> To be included in the proposal:
> - explanation and reasoning of the governance model
> - expected roles and responsibilities
> - candidate for the role need not be included at this time, since we're only
> choosing the governance model. Depending on the governance model chosen, we
> might have different people to be nominated. There will be a separate
> process for nominating the candidate.
> - the term of governance: is it for life? 5 years? 10 years?
>
> Who can submit the proposal?
> Python core developers. Individual core devs can submit a proposal, or
> co-author the proposal with another core dev.
>
> How to submit the proposal?
> Proposal should be in a form of a PEP, and merged into peps repo before Oct
> 1 00:00:00 UTC. Proposals not merged after Oct 1 00:00:00 UTC will not be
> considered.
>
> Oct 1 - Nov 15: Review period.
> All core developers will review the PEPs, and ask any questions to the PEP
> author. This timeline allows for enough time for all core devs to carefully
> review each PEPs, and for authors to respond.
>
> There will be two parts of this:
>
> Review phase 1: Oct 1- Nov 1: Allow changes and tweaks to the proposed PEPs.
> I figured people will have questions and will need to clarify the PEPs
> during this period. But if we want the PEP to be final by Oct 1, that's fine
> by me. maybe allow typo fixes still.
>
> Review phase 2: Nov 1 00:00:00 UTC: No more changes to the above PEPs.
> No more tweaks to these PEPs. PRs to these PEPs should be rejected.
> This is the final chance to carefully review all governance PEPs, and
> formulate your decisions.

I'm worried that this whole plan is a bad idea.

This kind of process with deadlines, proposals, votes, etc., is an
excellent way to take legitimacy and make it visible. That's a
valuable thing, and addresses an important problem. But it's not the
problem I'm most worried about here.

As engineers, we know that every design has trade-offs, and that goes
for governance as well. Having a universally acclaimed BDFL like Guido
has many tremendous advantages. But it also has one tremendous
disadvantage: because we always knew Guido would make the final
decision, and that we could always appeal to him when things didn't go
the way we like, python-dev has never had to learn to work out
disagreements and get along.

Now we have to figure that out: the legitimacy of any new governance
system is ultimately going to have to rest on the consensus of the
core devs. The only way I know to get that is by taking the time to
work through the difficult conversations. If these deadlines just
encourage people to keep moving and engaging, then that's great. But I
worry that if we impose a cut-off like this up front, then we'll take
that as an excuse to skip doing that work, because there's no time,
and if someone disagrees it's easier to vote than to actually engage
and work it out.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Nathaniel Smith]

On Fri, Jul 20, 2018 at 3:50 PM, Brett Cannon  wrote:
>
>
> On Fri, 20 Jul 2018 at 15:36 Nathaniel Smith  wrote:
>>
>> On Fri, Jul 20, 2018, 08:58 Brett Cannon  wrote:
>> > While I'm purposefully staying out of this thread as my name is
>> > currently so strongly associated with it and I don't want people thinking
>> > I'm a megalomaniac, I will say that I see no reason why I wouldn't get 50%
>> > time at Microsoft if I asked for it (I already get a day/week plus email
>> > reading every day).
>>
>> Is that only if you were named BDFL, or do you think they might also
>> support that if you were named "Chief PEP Herder", or "Member of the
>> steering council",or similar?
>
> It isn't really title and more about workload/responsibility. So if the
> title changed to "Chief PEP herder" but it was still on my shoulders to have
> final say then I don't expect an issue as they would understand what that
> means to me and my time. If I'm one of three on a council then I might still
> get more time but I'm not as sure; it's definitely possible, but not as much
> of a sure thing. If the group was 10 then probably not because that means I
> am just one of about a quarter of all authors over the past year.

Right, my point was more that "workload" and "authority" are related
but not exactly the same :-). For example, if we ended up with a
governance model in which final PEP acceptance is based on consensus
or voting or something, then we wouldn't have a BDFL, but it still
might be *very* helpful to have people with dedicated time to help
shepherd PEPs through the process of building consensus, working out
exactly what the points of disagreement were that needed to be voted
on, mediating arguments that get out of hand, and so forth [1] --
that's what I was trying to handwave at with the "Chief PEP herder"
title.

> I think that's a constant discussion to have which never really ends. People 
> with more time to effectively contribute is always welcome. :)

Sure, but there is something special about this moment too :-). If we
think that funding positions like these would make a significant
difference to the viability of our community post-Guido, then now is a
time when we could go to companies and say "look, Python is going
through this critical transition, it needs this kind of funding to
survive and thrive, can you help?", and see how they respond.

I don't want to put you on the spot and I know you can't make promises
on behalf of MS, so maybe I shouldn't have asked. But generally – we
have some evidence that companies might be willing to fund someone to
be the BDFL. It'd be useful to know whether companies would also be
willing to fund crucial community work even if it didn't mean they got
to boast about having the BDFL on their payroll.

-n

[1] personally I suspect that python's survival is going to depend
much more on whether we have people doing this kind of work, than on
which specific formal governance structure we end up with

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] An alternative governance model

[Nathaniel Smith]

On Fri, Jul 20, 2018, 08:58 Brett Cannon  wrote:
>
>
>
> On Fri, Jul 20, 2018, 07:51 Nick Coghlan,  wrote:
>>
>> Guido was willing to do it for so long because Python was his
>> creation, and he grew into the increasing demands of the BDFL role as
>> time went by, but even he eventually reached the point of saying "I
>> don't want to do this any more - the personal costs are outweighing
>> the personal benefits". There's no way that a new individual in a
>> comparable role to Guido's is going to have an easier time of it than
>> Guido did, and a lot of good reasons to believe that they will find it
>> significantly harder (not least of which is that Guido has been able
>> to request 50% funded "BDFL-time" from his employers since he joined
>> Google in 2005, and it's unlikely that a newcomer to the role would
>> enjoy that benefit any time soon).
>
> While I'm purposefully staying out of this thread as my name is currently so 
> strongly associated with it and I don't want people thinking I'm a 
> megalomaniac, I will say that I see no reason why I wouldn't get 50% time at 
> Microsoft if I asked for it (I already get a day/week plus email reading 
> every day).

Is that only if you were named BDFL, or do you think they might also
support that if you were named "Chief PEP Herder", or "Member of the
steering council",or similar?

AFAICT Guido spent a lot of time behind the scenes moving PEPs along
and generally keeping things organized. I think we might get a lot of
value out of having more people with time to focus on these things,
and it's not really limited to the BDFL. The Django project seems to
benefit a lot from their fellows program [1], and in the recent grant
the PSF got for PyPI, everyone was *very* happy that we spent money on
a project manager [2]. (And at the risk of falling into megalovania
myself, I've also written about this recently [3].)

So I don't have a specific proposal or anything, but maybe as part of
this discussion we should exploring ways to get more dedicated time on
CPython, through company's donating time, or sponsoring people through
the PSF, or whatever makes sense.

-n

[1] 
https://www.djangoproject.com/weblog/2016/dec/28/fellowship-2016-retrospective/
[2] https://twitter.com/EWDurbin/status/968180960066928640
[3] 
https://vorpus.org/blog/the-unreasonable-effectiveness-of-investment-in-open-source-infrastructure/
___
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] Proposal: an explicit, time-limited moratorium on finalizing any governance decisions

[Nathaniel Smith]

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

Re: [python-committers] Transfer of power

[Nathaniel Smith]

On Fri, Jul 13, 2018 at 8:22 PM, Tim Peters  wrote:
> [Nathaniel Smith ]
>>
>> That's not really true -- life expectancy *at birth* was ~35 years,
>> but mostly because so many people died as infants/children. If you
>> survived long enough to get nominated for a judgeship, then by that
>> point your life expectancy wasn't too different from what we're used
>> to today:
>> https://passionforthepast.blogspot.com/2011/08/average-life-expectancy-myth.html
>
> But that's just anecdotal, [...]

Yeah, it's an off-topic digression anyway so I was simplifying and
didn't spend much time looking for the perfect link. Looking a bit it
seems like in ~1790 a 20-year old white male in the US could expect to
live another ~45 years, and today that's up to ~55 years, and then the
numbers get closer together as the ages increase. Which is about what
I had in mind for "not too different".

>> But I think there are a lot of differences between a 21st-century
>> F/OSS project and an 18th-century federal government, so probably not
>> the most relevant model in any case. And of course it's always
>> tempting to start inventing neat rules and procedures, but IME those
>> details are actually the least important part of project governance
>> (compared to things like, having a healthy discussion culture, tools
>> for building consensus, etc. -- by the time you're voting on something
>> you've already failed). So debating the pros and cons of term limits
>> seems a bit premature to me right now :-).
>
>
> The subject "Transfer of power" is a pretty good clue that building tools
> (etc) isn't the primary topic of this thread ;-)  We're looking to fill the
> void left by an Absolute Dictator for Life stepping down.  It's important to
> get that part right too, because "by the time you're voting on something
> you're already failed" is a thing that will happen, and repeatedly.  Guido
> has been the last, best resort in such cases.

Well, sure, we can try to come up with something to slot into the
space Guido is leaving, while keeping everything else the same, that's
one option. But I doubt it's the best one. Guido is, quite literally,
irreplaceable.

> The US Supreme Court is the closest thing to a dictatorial institution the
> US has (lifetime appointments, answerable to nobody, and against which there
> is no appeal), so it's a natural model to consider when replacing a
> dictator.

Yeah, I get why it comes to mind for USians here, but there are also,
like... lots of actual open-source projects that have transitioned
from a BDFL model to something else, and they're probably even more
natural models ;-).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Transfer of power

[Nathaniel Smith]

On Fri, Jul 13, 2018 at 6:54 PM, Tim Peters  wrote:
> [Larry Hastings]
> ...
>>
>> However, once appointed, Elders are appointed is "for life".  The only way
>> to remove one would be for them to voluntarily step down--there would be no
>> mechanism to remove one from office.  (Perhaps this is too strong--perhaps
>> one could be removed by a unanimous vote from all other Elders?)  I want the
>> Council to be immune to popular opinion, to be empowered to do what they
>> think is right without fear of anything beyond negative public opinion.
>
> At the time the US"s founders drafted the Constitution, mean US life
> expectancy was about 35 years   A Federal judge only had to maintain "good
> behavior" to keep their job, but I imagine they expected most judges would
> die within a decade or two regardless.

That's not really true -- life expectancy *at birth* was ~35 years,
but mostly because so many people died as infants/children. If you
survived long enough to get nominated for a judgeship, then by that
point your life expectancy wasn't too different from what we're used
to today: 
https://passionforthepast.blogspot.com/2011/08/average-life-expectancy-myth.html

But I think there are a lot of differences between a 21st-century
F/OSS project and an 18th-century federal government, so probably not
the most relevant model in any case. And of course it's always
tempting to start inventing neat rules and procedures, but IME those
details are actually the least important part of project governance
(compared to things like, having a healthy discussion culture, tools
for building consensus, etc. -- by the time you're voting on something
you've already failed). So debating the pros and cons of term limits
seems a bit premature to me right now :-).

-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] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Nathaniel Smith]

On Thu, Jul 12, 2018 at 6:35 PM, Łukasz Langa  wrote:
> I'm +1 to an Informational PEP around the state of the art in project 
> governance.

I think this is a great idea. There's a lot of experience out there on
different governance models, but of course any given project only uses
one of them, so knowledge about what works and what doesn't is pretty
fragmented across the F/OSS community. And this is a really important
decision for us and our users, so we should do due diligence. For
example, we should think this through at least as carefully as we
thought through Github vs. Gitlab :-). A PEP is a good format to start
doing that.

I volunteer to co-author such a PEP. But I'm not up to doing it on my
own. So... who else wants to be a co-author? (I'm not going to
pressure anyone, but Brett, Mariatta, and Carol, please know that your
names were the first ones that jumped to my mind when thinking about
this :-).)

What I'm thinking:

- While this might eventually produce some recommendations, the
immediate goal would just be to collect together different options and
ideas and point out their trade-offs. I'm guessing most core devs
aren't interested in becoming experts on open-source governance, so
the goal here would be to help the broader community get up to speed
and have a more informed discussion [1].

- As per the general PEP philosophy, I think this is best done by
having some amount of general discussion on
python-dev/python-committers, plus a small group of coauthors (say 2-4
people) who take responsibility for filtering ideas and organizing
them in a coherent document.

- Places where we'll want to look for ideas:
  - The thread already happening on python-committers
  - Whatever books / articles / blog posts / etc. we can find (e.g. I
know Karl Fogel's Producing OSS book has some good discussion)
  - Other major projects in a similar position to CPython (e.g.,
node.js, Rust) -- what do they do, and what parts are they
happy/not-happy about?
  - Large Python projects (e.g. Django) -- likewise

If you have suggestions for particularly interesting projects or
excellent writing on the topic, then this thread would be a good place
to mention them.

-n

[1] The NumPy project has put a lot of energy into working through
governance issues over the last few years, and one thing that
definitely helped was coming up with some "assigned reading" ahead of
the main sprint where we talked about this. NumPy's problems are/were
pretty different from CPython's, but I'm imagining this PEP as filling
a similar role.

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Vote to promote Pablo Salingo Salgado as core developer

[Nathaniel Smith]

On Thu, Jun 14, 2018 at 4:40 AM, Berker Peksağ  wrote:
> This isn't about my or someone else's high standards. We keep saying
> we need more triagers and reviewers, and we keep promoting people who
> didn't do any issue triaging and code review. It's not fair to
> contributors who have spent so much time working on these areas.

Surely the solution is to promote more people who do those things, not
to turn away people making other contributions? We need more
contributors of all kinds.

+1 from me.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Comments on moving issues to GitHub

[Nathaniel Smith]

On Sun, May 20, 2018, 03:18 Antoine Pitrou  wrote:

>
> Le 19/05/2018 à 02:10, Victor Stinner a écrit :
> > Hi,
> >
> > I failed to get the microphone after Mariatta's secret talk about
> > moving Python issues from bugs.python.org (Roundup) to GitHub.
>
> A "secret talk"? What is that?
>

She gave a talk at the language summit to discuss what people thought of
the idea, and she had some fun making the topic a surprise so she could see
people's reactions. I don't think there's any secret beyond that.

IIRC, the general reaction was that it was definitely worth exploring, but
that it would be a lot of work and require solutions to a lot of problems
to make sure people's workflows weren't too impacted, so we'd need a much
more detailed proposal before any decision could be made.

-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] Travis & AppVeyor hidden on Github, scroll the invisible region to see them.

[Nathaniel Smith]

On Fri, May 18, 2018 at 4:29 PM, Gregory P. Smith  wrote:
> What do people think about teaching miss-islington how to re-launch specific
> CI runs a few times to deflake failures? ("1 out of n passes counts as a
> pass") - That requires compute resources, but when it is what the human is
> going to need to do anyways... why not reduce the need and just automate it
> the first couple of times? I don't know how feasible this is for any given
> CI system we use today on CPython given the various ways in which they
> operate.

This can also be done with a loop inside individual tests, which would
avoid complications with CI APIs and make sure that if any new flaky
tests show up then we'll notice it.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Nathaniel Smith]

On Fri, May 18, 2018 at 4:51 PM, Ivan Levkivskyi  wrote:
> On 18 May 2018 at 19:46, Gregory P. Smith  wrote:
>>
>>
>> I'm all for picking a victom^Wvolunteer PEP to try dogfood it on.
>>
>
> Can few related PEPs share the same repository? For example, I want to start
> writing three PEPs about extensions to PEP 484 type system: literal types,
> final/const qualifier, and integer generics (simple dependent types).
> They all are tightly connected (but I don't want a single mega-PEP), can I
> put these three in the same repo?

Another common pattern we see with trickier PEPs is the creation of
multiple competing proposals. This strikes me as healthy and something
we want to encourage. Maybe these should also go in the same repo by
default?

This is also a case where assigning PEP numbers earlier rather than
later seems useful. Unambiguously referring to PEP 521, PEP 550, PEP
567, and PEP 568 would be difficult without the numbers :-).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Nathaniel Smith]

On Fri, May 18, 2018 at 3:25 PM, Guido van Rossum  wrote:
> Discussing PEPs on python-dev and python-ideas is clearly not scalable any
> more. (Even python-committers probably doesn't scale too well. :-)

PEP 572 seems like something of a perfect storm... it's simultaneously
a bikeshed and a nuclear power plant [1], and also the rare proposal
that you like but that significant numbers of core devs find deeply
objectionable; any one of these would tend to produce a lot of email,
and then the combination is something else again. Is this proposal
mostly responding to that, or something that you've been thinking for
a while?

[1] For those unfamiliar with this example:
https://en.wikipedia.org/wiki/Law_of_triviality#Examples

> I wonder if it would make sense to require that for each PEP a new GitHub
> *repo* be created whose contents would just be a draft PEP and whose issue
> tracker and PR manager would be used to debate the PEP and propose specific
> changes.

To some extent this has been happening informally for a while. Just
off the top of my head:

PEP 465: https://github.com/numpy/numpy/pull/4351
PEP 543: https://github.com/python-hyper/pep543/issues/2#issuecomment-309199376
PEP 513: https://github.com/pypa/manylinux#the-pep-itself
A repo full of packaging PEPs: https://github.com/pypa/interoperability-peps

For a lot of us these days, putting a document in a repo is just the
default way to work on it (and get feedback, etc.).

Managing the relationship between these repos and the main peps repo
is currently pretty awkward. They tend to get out of sync in both
directions – people make edits directly to the PEP repo – plus in
general some pieces of information are in one place and some in
another, there's no link between them, the original repo can get
misplaced over time...

> This way the discussion is still public: when the PEP-specific repo is
> created the author(s) can notify python-ideas, and when they are closer to
> submitting they can notify python-dev, but the discussion doesn't attract
> uninformed outsiders as much as python-{dev,ideas} discussions do, and it's
> much easier for outsiders who want to learn more about the proposal to find
> all relevant discussion.
>
> PEP authors may also choose to use a different repo hosting site, e.g.
> Bitbucket or GitLab. We can provide a script that allows checking the
> formatting of the PEP easily (basically pep2html.py from the peps repo).

I'd be somewhat tempted to require people to use Github and to move
the repo into the python/ organization when it gets a number, so that
there's one canonical place to look for the history and we have some
control over its lifecycle.

More radical idea: what if the PEPs index just linked to the Github
rendering of each file? That's always going to be up to date, it comes
with a link to the issue tracker at the top, it has a nice "Edit"
button if someone wants to submit small fixes as a PR...

> Using a separate repo per PEP has the advantage that people interested in a
> topic can subscribe to all traffic in that repo -- if we were to use the
> tracker of the peps repo you would have to subscribe to all peps traffic.
>
> Thoughts? (We can dogfood this proposal too, if there's interest. :-)

Rust's RFC process is a bit different, but may be of interest:
https://github.com/rust-lang/rfcs

One thing people might worry about is missing out on discussion
they're interested in – there wouldn't be one central place to
subscribe to see discussions. Rust's concept of a "final comment
period" is a nice way to manage this.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Visual Studio Team Services checks on pullrequests

[Nathaniel Smith]

On Thu, May 17, 2018 at 5:27 PM, Terry Reedy  wrote:
> Can VSTS run GUI tests on any of the systems?  Right now, only Appveyor and
> one or two of the Windows buildbots do so.

It's certainly possible to use Xvfb to run headless GUI tests on Linux
(or other Unixes that use X11). Any CI service should be able to
handle this, e.g.:
https://docs.travis-ci.com/user/gui-and-headless-browsers/#Using-xvfb-to-Run-Tests-That-Require-a-GUI

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Poll: Do you like the PEP 572 Assignment Expressions?

[Nathaniel Smith]

-1, I think, though I'm frustrated that in the parts of the list
discussion I had energy to read, its proponents seemed to be saying
that the most compelling examples aren't actually in the PEP (and I
don't know what they are).

On Wed, May 2, 2018 at 2:49 AM, Victor Stinner  wrote:
> Hi,
>
> I would like to start a poll on Chris Angelico's PEP 572 "Assignment
> Expressions", restricted to Python core developers, to prepare the
> talk at the Language Summit:
>
>https://www.python.org/dev/peps/pep-0572/
>
> The poll is on the *current* PEP. I propose 4 choices:
>
> * +1: you like the PEP
> * -1: you dislike the PEP
> * 0: you are not sure if you like it or not, or you have no opinon
> * don't reply to this poll :-)
>
> Just reply to this email with "+1", "0", "-1". Please don't elaborate
> here, it's just a quick poll, use python-dev if you want to talk :-)
>
> The poll will end next Tuesday, May 8, the day before the Language Summit.
>
> I propose a poll because I'm unable to track the opinion of each core
> dev, too many emails have been sent to python-dev, and maybe some
> people changed their mind during the long discussion (which started in
> February) :-)
>
> Note: Obviously, it's just a poll, not a vote. Guido van Rossum is the
> one who will pronounce himself on the PEP, to accept to reject it, so
> the only one allowed to vote ;-)
>
> 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/



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