Re: [python-committers] discuss.python.org participation

[Doug Hellmann]

Brett Cannon  writes:

> One data point in all of this is Victor's PEP 8015. Here on the mailing
> list I seem to be the first and only person to reply since the PEP was
> posted on Monday. But over on Discourse there have been 3 people who have
> replied and there's already been some back-and-forth.
>
> So with a sample size of one, it looks like Discourse isn't discouraging
> anyone, otherwise I would have assumed people who don't want to start with
> Discourse would have simply started a discussion here on the mailing list
> about Victor's PEP.

I don't think it is safe to interpret the current level of engagement
there as a definitive endorsement of the tool.

I believed this discussion was *supposed* to be happening over there and
*not* on the mailing list (the initial messages about it were worded
very strongly). If others who want to have a say in the future
governance of the project had the same impression, then I would expect
them to sign up and use Discourse regardless of their opinion of the
tool.

I don't dislike Discourse, but I would have rather used the mailing list
for the governance discussion and used some other, less critical, topic
as a trigger for experimenting with a new tool. If the trouble with the
mailing lists is moderation, then some other list that requires more
moderation work would have been a good candidate.

>
> On Tue, 9 Oct 2018 at 20:24, Jack Diederich  wrote:
>
>> I'm worried about the new format combined with governance discussions. As
>> best I can tell 51 CPython committers have signed up for an account [I
>> think that is a big number, btw] but only 17 have posted anything; That 17
>> is about 5 more people than put their name on a governance PEP. And maybe 5
>> people have half the total posts. This does not feel like a discussion at
>> all.
>>
>> I don't think it was deliberate, but it looks like the new format is
>> actively discouraging everyone but those most deeply invested with the most
>> free time from participating.
>>
>> -Jack
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Doug Hellmann]

> On Oct 1, 2018, at 8:18 AM, Doug Hellmann  wrote:
> 
> Signed PGP part
> 
> 
>> On Sep 28, 2018, at 5:45 PM, Łukasz Langa > <mailto:luk...@langa.pl>> wrote:
>> 
>> Signed PGP part
>> Hello committers,
>> since this got pretty long, here's the tl;dr:
>> 
>> - we're at the point where it is hard to make mailing lists work for us;
>> - we're switching to Discourse; it's better in many ways;
>> - go to https://discuss.python.org/ <https://discuss.python.org/> and create 
>> your account there;
>> - please do not post to python-committers for the remainder of the year to 
>> give Discourse a real shot.
> 
> The site shows up blank for me in Safari.
> 
> Which browsers are supported?

Nevermind, it appears related to the javascript popup-blocking setting.

Doug



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-committers is dead, long live discuss.python.org

[Doug Hellmann]

> On Sep 28, 2018, at 5:45 PM, Łukasz Langa  wrote:
> 
> Signed PGP part
> Hello committers,
> since this got pretty long, here's the tl;dr:
> 
> - we're at the point where it is hard to make mailing lists work for us;
> - we're switching to Discourse; it's better in many ways;
> - go to https://discuss.python.org/  and create 
> your account there;
> - please do not post to python-committers for the remainder of the year to 
> give Discourse a real shot.

The site shows up blank for me in Safari.

Which browsers are supported?

Doug



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

[Doug Hellmann]

Excerpts from Steven D'Aprano's message of 2018-07-21 02:32:02 +1000:
> On Fri, Jul 20, 2018 at 10:37:03AM -0400, Doug Hellmann wrote:
> > Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100:
> 
> [...]
> > > In contrast, I would imagine that people would continue to discuss
> > > PEPs in exactly the same way that they currently do, so the result
> > > would be that the votes are based more on partially-informed opinion
> > > and "gut feeling". Certainly some people will work harder to provide
> > > an informed vote, but I doubt that will be true in the majority of
> > > cases. Worst case, people will feel a responsibility to vote, but
> > > won't have any more time than they do right now so they'll vote with
> > > limited information simply because "it's expected of them" to vote.
> 
> [...]
> > In other communities that use this form of consensus approval for
> > design changes I have seen folks who do not have time or interest
> > to dig deeply into a proposed change learn to trust others who have
> > the time, interest, and expertise. The team comes out stronger as
> > a result of that built-up trust.
> 
> A few questions...
> 
> You say folks "learn to trust others", but what does that mean in 
> practice? The only interpretation I can think of is:
> 
> People vote for a feature, because Fred says he's in favour 
> of it and they trust him, or like him personally, or because
> he's more charismatic and persuasive than those against it.
> 
> What happens when two trusted experts disagree and the voters don't have 
> the expertise to tell which one is correct?

The same sort of thing that happens with PEPs. Either the proposal
itself is changed to support more compromise, or it is abandoned and the
status quo prevails.

> How large are these communities you are referring to?

OpenStack had 2000 contributors during 2017. Of those, I would
estimate that on the order of a few hundred are considered core
reviewers in some way and would have a formal vote in our specification
process, although the group reviewing any given specification would
be somewhat closer to the size of the python core developer team
size.

> The sort of participatory democracy Victor and you seem to be talking 
> about doesn't scale beyond small communities where everyone knows 
> everyone else. That's why such participatory democracy worked in ancient 
> Greece, and continues to be used in (eg) Swiss canons, but beyond that 
> communities have moved to a representative democratic model.

It is certainly harder to implement as the size of the group grows. I
don't think this group has hit the point where it is impossible to
sustain, though.

> Certainly the Python community as a whole is *significantly* bigger 
> than a village. What about the core developers? Now? In the future?

I'm not sure the entire Python community is really the relevant
size to consider. Another important aspect of open source governance
to keep in mind is that decisions need to be made by the folks doing
the work.  That's one reason the existing PEP delegate process works
so well today -- the person making that final decision is invested
in not just the decision but the overall area where the work is
happening. We already trust them to both know what they are doing
technically and guide the decision making process to consensus.

I find it interesting that the arguments in favor of a single BDFL
tend to assume that the person selected will be responsible and
informed enough to make good decisions, and the argument against a
more democratic approach seems to be that the community would not
be. Where in that latter assumption is the leadership of the person
we would be giving the BDFL title to? Why are they unable to
communicate, inform, and lead a democratically organized community
to achieve goals for the common good? And if they can't, why are
they qualified to be a dictator?

> One factor that I don't think Victor has covered is that of what 
> percentage of core devs would have to vote for the result to be 
> accepted -- a quorum, or equivalent.

Yes, this is a good point. I'm not sure a 1-size-fits-all approach
necessarily works, but some way of deciding how to know when consensus
is reached would be an important aspect of choosing a democratic
approach.

> Personally, I'm not sure I'd even want to vote on every PEP that comes 
> up. When I was first nominated to the PSF, I took the voting rights as 
> both a privilege and a duty and took them very seriously indeed. But as 
> time went on, I got somewhat disillusioned and burned out (for reasons 
> we need not go into). And that is only voting once or twi

Re: [python-committers] And Now for Something Completely Different

[Doug Hellmann]

Excerpts from Paul Moore's message of 2018-07-20 13:14:49 +0100:
> On 20 July 2018 at 12:57, Victor Stinner  wrote:
> > Hum. Let me try to explain my point differently. Currently, some
> > people don't read PEPs just because at the end, only the single BDFL
> > vote counts. What's the point of spending hours (if not days) on
> > reading a long PEP and the long discussion on mailing lists, if your
> > count doesn't count?
> 
> My suspicion is that *most* people who don't read PEPs don't do so
> because they don't have the time, not because they don't believe that
> their opinion will matter. In actual fact, the evidence from many
> threads is that people are more than happy to express their opinion
> even though they haven't read the PEP. So I doubt that giving people
> more power to affect the result will make little practical difference.
> 
> > Now imagine that all votes count. I expect that
> > people will spend more time on reading carefully each PEP and follow
> > more closely discussions since they will be de facto more involved in
> > the decision process.
> 
> In contrast, I would imagine that people would continue to discuss
> PEPs in exactly the same way that they currently do, so the result
> would be that the votes are based more on partially-informed opinion
> and "gut feeling". Certainly some people will work harder to provide
> an informed vote, but I doubt that will be true in the majority of
> cases. Worst case, people will feel a responsibility to vote, but
> won't have any more time than they do right now so they'll vote with
> limited information simply because "it's expected of them" to vote.
> 
> I suspect that the reality will be somewhere between these two extremes.
> 
> Paul

In other communities that use this form of consensus approval for
design changes I have seen folks who do not have time or interest
to dig deeply into a proposed change learn to trust others who have
the time, interest, and expertise. The team comes out stronger as
a result of that built-up trust.

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

Re: [python-committers] And Now for Something Completely Different

[Doug Hellmann]

Excerpts from Antoine Pitrou's message of 2018-07-20 09:49:01 +0200:
> 
> Le 20/07/2018 à 02:51, Ethan Furman a écrit :
> > My first issue with this model is, as discussed above, a lack of a 
> > consistent vision.  A BDFL is not just there to say, 
> > "this PEP is accepted," but also to say, "change this one piece here, 
> > remove that piece there, add this" -- definitely 
> > not something easily done by 100+ voters.
> > 
> > My second issue is qualifications:  there are plenty of PEPs that I either 
> > have no interest in or whose field I have no 
> > experience with, and my voting on those PEPs would be nonsensical; when 
> > that happens to a BDFL s/he appoints a BDFOP.
> > 
> > My third issue is, quite simply, time.  Working on patches takes time; 
> > reviewing PRs takes time; and being a good voting 
> > citizen takes lots and lots of time -- and we're all volunteers.  Time is 
> > at a premium.
> 
> This is true.  But it's a problem for the BDFL even more.  Our ex-BDFL
> resigned because of pressure and exhaustion.  Why would another BDFL
> fare better?
> 
> Victor pointed out something I didn't know: that several prominent core
> devs (him, Brett Cannon) recently suffered from
> breakdown/burnout/depression.
> 
> I find the PEP-delegate to be a powerful concept.  Why wouldn't *every*
> PEP have a PEP-delegate?  This way we don't need a BDFL anymore.  We can
> discuss how to nominate PEP-delegates (Nick had an interesting proposal).

+1

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

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

[Doug Hellmann]

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

That plan makes sense to me.

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

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

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

> I'm +1 on Mariatta's schedule. That gives people more than 2 months to come
> up with governance proposals and all of us to settle on how we will vote.
> And if we say the month of November will be when voting is open then that
> would give people more then 3 months notice of when the first vote will
> occur.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

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

[Doug Hellmann]

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

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

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

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

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

Re: [python-committers] Proposal on how to vote (was: An alternative governance model)

[Doug Hellmann]

Excerpts from Łukasz Langa's message of 2018-07-18 17:31:40 -0500:
> The PSF uses a good voting system where votes are secret. I see no reason not 
> to reuse this infra.
> 
> -- 
> Best regards,
> Łukasz Langa

This feels like a case where a consensus-based voting system may
be better than one that depends on amassing raw votes.

https://civs.cs.cornell.edu is a hosted version of Condorcet that
is reliable, easy to use, and allows for public review of the ballots
(without associating them with the person casting them).

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

Re: [python-committers] Transfer of power

[Doug Hellmann]

Excerpts from Jack Jansen's message of 2018-07-17 11:33:22 +0200:
> 
> > On 17 Jul 2018, at 02:02, Tim Peters  wrote:
> > 
> > [Tim]
> >> Guido's most visible (well, to us committers) BDFL role has been in 
> >> "yes/no", "go/nogo" language/library design questions, which don't even 
> >> overlap with the PSF's proper concerns.
> >> 
> >> But I'm not sure it's fully appreciated just how active Guido has been in 
> >> those at times.  The "accepted/rejected" at the end of major PEPs is just 
> >> a small part of that.  Along the way, e.g., it's been pretty common to see 
> >> a "Save your breath.  That's not going to happen." from Guido to end a 
> >> distracting alternative (sub)proposal persistently promoted by one (or a 
> >> few) very active and/or loquacious posters.
> > [Jack Jansen]
> >  
> >> This is a very good point. And it is a role that is not “formally encoded” 
> >> anywhere, and one that I think cannot be formally encoded.
> >> 
> >> And actually I wonder whether this role could be fulfilled by any 
> >> person/committee/procedure other than Guido himself. Which means that in 
> >> future we should prepare for doing without this role. Which will lead to 
> >> more contentious issues being put in front of the 
> >> whatever-body-replaces-the-bdfl, because the early weeding out isn’t going 
> >> to happen.
> >> 
> > I'm not quite as hopeless ;-)  Most notions on python-ideas are dropped 
> > voluntarily, after it's clear that they generate little interest - or 
> > massive hostility ;-) 
> > 
> > For one that proceeds to a preliminary PEP, I think it would be wise for 
> > the Elders (whatever it's called) to appoint a BDFL-workalike for that 
> > specific PEP.  Which may or may not be an Elder.  That person would need to 
> > commit to staying current with the PEP's progress, and would have final 
> > "yes/no", "this/that", ...  authority on all the design decisions on the 
> > way to polishing the PEP.  But not the final accept/reject decision (if the 
> > PEP survives that long).
> 
> I’m not hopeless either:-)
> 
> But the point I was trying to make is that Guido has a standing _within the 
> wider community_ that will cause people to sit and ponder his replies, in 
> stead of quickly replying and going into the defensive. The Elders will 
> probably miss that standing in the community at large, at least for the time 
> being. So I think we should prepare for more and longer heated discussions, 
> and make sure that the procedures for the eventual decision are such that 
> people can generally live with the outcome and don’t turn their back on the 
> community.

I agree that having a consensus-based process that everyone agrees
to use and abide by is important.

Perhaps we can also take change the process to start eliminating
the culture that leads to so much heat in the first place. Healthy
debate is all well and good, but it seems like we've had a couple
of examples of things getting out of hand recently.

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

Re: [python-committers] Organizing an informational PEP on project governance options (was Re: Transfer of power)

[Doug Hellmann]

Excerpts from Nathaniel Smith's message of 2018-07-13 04:31:00 -0700:
> 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.

I would be happy to contribute based on the experiences we've had
with different leadership models in OpenStack.

Doug

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

[Doug Hellmann]

Oh, yeah, I guess I wasn’t clear there. I am not suggesting that release 
managers add this new responsibility. I’m suggesting that a release cycle 
length is an amount of time the community is used to dealing with, and 
therefore might make a good cadence for elections or whatever other rotation 
mechanism is selected for the new group.

Sorry for the confusion.

Doug

> On Jul 13, 2018, at 5:30 AM, Anthony Baxter  wrote:
> 
> As someone who's not been involved for some time now, but was release manager 
> for a three or four years (2.3.1 through to 2.5.1), trying to have the 
> release manager also be a decider of potentially controversial things doesn't 
> seem scalable. 
> 
> Getting a release out is a heck of a lot of work, both the actually cutting 
> the alphas, betas, &c, and also triaging issues that comes up and chasing 
> people up for fixes.
> 
> I'm not sure what the proper governance structures should be, but they 
> absolutely shouldn't be dumping extra load onto the release manager.
> 
> On Fri, Jul 13, 2018, 3:49 AM Doug Hellmann  <mailto:d...@doughellmann.com>> wrote:
> Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400:
> > On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou  > <mailto:anto...@python.org>> wrote:
> > >
> > >
> > > I'd like to point out that the N-virate idea doesn't handle a key issue:
> > > once you have a N-virate, how do you evolve its composition according to
> > > the implication and motivation of its members - but also to remarks or
> > > frustation by non-virate contributors (especially new contributors who
> > > will feel there's a perpetual category they're locked out of)?  Do you
> > > just wait for people to gently step down when required?
> > 
> > One way would be to re-elect them every 5 or so years.  Essentially,
> > an N-virate is a dictator-like entity for a few years.
> > 
> > Yury
> 
> We've had good luck in the OpenStack community tying leadership to
> release cycles. It causes elections more often (our cycles are 6
> months long), but people tend to step up for several cycles in a
> row so that hasn't been a cause of excessive turnover. Having
> frequent opportunities for folks to step down gracefully when they
> need or want to also means no one feels like they are signing up
> for an indefinite time commitment.
> 
> For a multi-person group, staggered elections where only a portion
> of the group is up for election at one time, also provides some
> consistency when there is turnover.
> 
> Doug
> ___
> python-committers mailing list
> python-committers@python.org <mailto:python-committers@python.org>
> https://mail.python.org/mailman/listinfo/python-committers 
> <https://mail.python.org/mailman/listinfo/python-committers>
> Code of Conduct: https://www.python.org/psf/codeofconduct/ 
> <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] Transfer of power

[Doug Hellmann]

Excerpts from Christian Heimes's message of 2018-07-12 20:54:05 +0200:
> On 2018-07-12 20:50, Brett Cannon wrote:
> > IMHO the N-virate should primarily be responsible for delegation.
> > 
> > Side note: I think we'll be talking less and less about language design,
> > and instead about library and infrastructure design.
> > 
> > 
> > Same here. I suspect this will make us much more conservative in
> > accepting language changes compared to e.g. what our deprecation policy
> > should be.
> 
> +1
> 
> - Primary to delegate responsibilities to domain experts
> - Secondary to provide consistency and trust
> - Lastly to have final word in case of controversial bike shedding
> 
> Christian

If the primary approach to decision making is to delegate unless
an arbiter is absolutely necessary, then long-term consistency and
stability comes less from finding individuals to commit to serving
for very long terms on the N-virate as it does from everyone having
a good understanding of the history of discussions and from a
willingness to keep the status quo in situations where consensus
isn't reached (note "consensus" rather than "unanimous agreement").

Building the system to support and encourage turnover, like we do
with release managers, lowers the level of effort someone is signing
up for when they agree to serve. Given the *many* discussions of
burnout in the Python community and open source in general, that
seems like an important feature.

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

Re: [python-committers] Transfer of power

[Doug Hellmann]

Excerpts from Brett Cannon's message of 2018-07-12 11:11:49 -0700:
> On Thu, 12 Jul 2018 at 11:02 Yury Selivanov  wrote:
> 
> >
> > IOW I don't see anyone (or some group of 3) who is as well-versed in
> > everything on Guido's level.  That can be solved if Guido agrees to
> > join the permanent N-virate though :)
> >
> 
> No one has suggested we haven't been extremely lucky for the past 28 years.
> :) I also don't think we will reach perfection in any solution anyway and
> this is somewhat of a "least bad" situation.

Are we looking for people who are skilled at language design, or who are
skilled at building consensus through open decision-making processes?
Because those are very different sorts of skills, and if this new body
is intended to only be a final arbiter on decisions the former set of
skills may be less important than the latter.

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

Re: [python-committers] Transfer of power

[Doug Hellmann]

Excerpts from Yury Selivanov's message of 2018-07-12 13:29:21 -0400:
> On Thu, Jul 12, 2018 at 12:58 PM Antoine Pitrou  wrote:
> >
> >
> > I'd like to point out that the N-virate idea doesn't handle a key issue:
> > once you have a N-virate, how do you evolve its composition according to
> > the implication and motivation of its members - but also to remarks or
> > frustation by non-virate contributors (especially new contributors who
> > will feel there's a perpetual category they're locked out of)?  Do you
> > just wait for people to gently step down when required?
> 
> One way would be to re-elect them every 5 or so years.  Essentially,
> an N-virate is a dictator-like entity for a few years.
> 
> Yury

We've had good luck in the OpenStack community tying leadership to
release cycles. It causes elections more often (our cycles are 6
months long), but people tend to step up for several cycles in a
row so that hasn't been a cause of excessive turnover. Having
frequent opportunities for folks to step down gracefully when they
need or want to also means no one feels like they are signing up
for an indefinite time commitment.

For a multi-person group, staggered elections where only a portion
of the group is up for election at one time, also provides some
consistency when there is turnover.

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

Re: [python-committers] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

[Doug Hellmann]

Excerpts from Brett Cannon's message of 2017-01-21 19:51:48 +:
> What I'm picking up from this is (as a gross oversimplification):
> 
> * Victor _wants_ code reviews
> * Raymond thinks we _need_ code reviews
> 
> So the common theme here regardless of whether you agree with Raymond or
> Victor's approach to development is that we are not getting enough code
> reviews to go around. To me that's what the systemic issue is that this
> email is bringing up.
> 
> Now I think most of us don't think the solution to the lack of reviews is
> to lower our standard of what it takes to become a core developer (this
> doesn't mean we shouldn't do a better job of identifying potential
> candidates, just that we shouldn't give people commit privileges after a
> single patch like some projects do). To me that means we need to address
> why out of 79 core developers only 39 have a single commit over the past
> year, 30/79 have more than 12 commits over that same time scale, 15/79
> people have more than 52 commits, and 2/79 people have over 365 commits (
> https://github.com/python/cpython/graphs/contributors?from=2016-01-22&to=2017-01-21&type=c
> for
> the stats).
> 
> Some of you have said you're waiting for the GitHub migration before you
> start contributing again, which I can understand (I'm going to be sending
> an email with an update on that after this email to python-dev &
> core-workflow). But for those that have not told me that I don't know what
> it will take to get you involved again. For instance, not to pick on Andrew
> but he hasn't committed anything but he obviously still cares about the
> project. So what would it take to get Andrew to help review patches again
> so that the next time something involving random comes through he feels
> like taking a quick look?
> 
> As I have said before, the reason I took on the GitHub migration is for us
> core developers. I want our workflow to be as easy as possible so that we
> can be as productive as possible. But the unspoken goal I have long-term is
> to get to the point that even dormant core devs want to contribute again,
> and to the point that everyone reviews a patch/month and more people
> reviewing a patch/week (although I'll take a patch/year to start). I want
> to get to the point that every person with commit privileges takes 30
> minutes a month to help with reviews and that the majority of folks take 30
> minutes a week to review (and please don't think this as a hard rule and if
> you don't the privileges go away, view this as an aspirational goal). Even
> if people who don't have time to review the kind of patches Victor is
> producing which triggered this thread, reviewing documentation patches can
> be done without deep knowledge of things and without taking much time. That
> way people who have time to review the bigger, more difficult patches can
> actually spend their time on those reviews and not worrying about patches
> fixing a spelling mistake or adding a new test to raise test coverage.
> 
> All of this is so that I hope one day we get to the point where all patches
> require a review no matter who proposed the code change. Now I think we're
> quite a ways of from being there, but that's my moonshot goal for our
> workflow: that we have enough quality reviews coming in that we feel that
> even patches from fellow core developers is worth requiring the extra code
> check and disbursement of knowledge without feeling like a terrible drag on
> productivity.
> 
> Once the GitHub migration has occurred I'm planning to tackle our Misc/NEWS
> problem and then automate Misc/ACKS. After that, though, I hope we can take

I would be happy to help with both of those tasks. I have experience
with both within the OpenStack project.

And put me on the list of "waiting for github" contributors. I
should have more time freeing up in a couple of months as I change
some of my responsibilities at work. I would like to help with the
migration and eventually regular reviews.

Doug

> the time to have a hard look at what in our workflow prevents people from
> making even occasional code reviews so that everyone wants to help out
> again (and if any of this interests you then please subscribe to
> core-workflow).
> 
> On Fri, 20 Jan 2017 at 02:46 Victor Stinner 
> wrote:
> 
> > Hi,
> >
> > Raymond Hettinger used a regression that I introduced in the builtin
> > sorted() function (in Python 3.6.0) to give me his feedback on my
> > FASTCALL work, but also on Argument Clinic.
> >
> > Context: http://bugs.python.org/issue29327#msg285848
> >
> > Since the reported issues is wider than just FASTCALL, including how I
> > contribute to CPython, I decided to discuss the topic with a wider
> > audience. I continue the discussion on python-committers to get the
> > opinion of the other core developers.
> >
> > Sorry for my very long answer! I tried to answer to each issues
> > reported by Raymond.
> >
> > Inaccurate summary: I'm a strong supporter of "it's better to as