On 26.03.2019 05:20, Raymond Hettinger wrote:
> 
>> On Mar 22, 2019, at 8:34 AM, Victor Stinner <vstin...@redhat.com> wrote:
>>
>> Julien Palard and me (Victor) propose to promote Stéphane Wirtel as
>> core developer. We open a vote until March 31 (~one week). "[A
>> promotion] is granted by receiving at least two-thirds positive votes
>> in a core team vote and no veto by the steering council."
>> https://www.python.org/dev/peps/pep-0013/#the-core-team
> 
> For some reason, I can't vote on discourse. The message is "you can vote 
> because you can't post in this topic."  So please add this post to the tally.
> 
> On the plus side, I've enjoyed working with Stéphane Wirtel and think he is a 
> great person and Python enthusiast. That said, I think we should wait.  The 
> contributions thus far have been very light weight. Also, I've not seen 
> active, critical decision making on the bug tracker that would demonstrate an 
> understanding of what to approve and what not to approve.

Doesn't a good core dev have to have two main characteristics:
1. be passionate about Python and 2. be knowledgeable in a
field of expertise ?

Decision making is something you grow into with experience and
you first have to get a feel for the group you're making decisions
for. I don't believe we should make this a number one criterion
for voting someone in.

> Nominating someone too early puts us all in an awkward position. It's no fun 
> to vote with a -1.  If the nomination has been allowed to mature, this could 
> be a more positive experience for everyone.  We shouldn't have just one 
> person spewing out nominations and doing it prematurely (imo). We had that 
> situation happen in the PSF and it quickly degraded as people started 
> nominating their friends some of whom had only light associations with 
> Python. In the end, that situation necessitated a reorg to where the new 
> standard was zero.  We already have a number of core-devs who are core devs 
> in name only, having never made a commit or actively participated in 
> developing the core.

Sorry, Raymond, but the above comment on the PSF isn't quite accurate.
At the time when the PSF was invite only, we tried very hard to grow
the organization and luckily reached a point where we no longer had
the much too comfortable situation of everyone knowing everyone else.

It's just natural that people then had to start voting in people
based on nomination text only knowledge. While I know that there were
many discussions around this at the time (much like we have now
on this list), the reorg did not come out of frustration about
the way we dealt with the nominations, but instead out of the
desire to be an open organization, rather than an elite club.

Now, the situation with the core devs is a bit different, since
we are actively working together on a project and people put a lot
of trust into us. The bar definitely is higher and we cannot
simply allow anyone to join.

I agree with your point about letting nominations mature, but
I'm also concerned about the lack of active core devs and the
push back the two nominations are getting. Here we have two
very candidates who are very passionate about Python and would
like to help, yet we have nothing better to do than to criticize
their readiness.

We do have to make up our minds: either we do want this group to
grow or we don't. If we do, we should probably come up with more
structure for nomination texts to make existing group members
feel more comfortable about voting someone in based on those,
instead of relying on other group members votes and only
amplifying them.

> Socially, there are two other concerns. One concern is unevenness -- the bar 
> was very high for some people and very low for others. It really seems to 
> matter who nominated you and who your friends are.  The other concern is 
> formation of cliques of friends who approve each other's proposals, but 
> falling into groupthink because of light experience and low diversity of 
> ideas.

Yes, there is a risk and yes, some core devs got in easier than
others (think of the need for speed sprint participants), but
I think all this is manageable.

I don't think that vote amplification is the right way, though,
for much the same reasons you state above, hence my push back
against that strategy.

-- 
Marc-Andre Lemburg
eGenix.com

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

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

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

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

Reply via email to