Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Georg Brandl]

On 01/10/2015 12:03 AM, M.-A. Lemburg wrote:

>>> Antoine and Victor argued that new developers should first
>>> show their skills by submitting patches to tickets, working
>>> with other core devs before getting the commit bit set.
>>>
>>> My suggestion was allowing new developers to start committing
>>> patches themselves before having worked on dozens of tickets
>>> using the usual patch approach.
>> 
>> What would that bring? Reverting commits or asking people to make post
>> hoc changes is much more bothersome than making pre-commit code reviews.
>> 
>> And I don't see how it's beneficial to ask developers to commit up front
>> while we're trying to promote a culture of code review, anyway.
> 
> Sorry, that was not what I meant. There should still be code reviews.
> 
> The point here is getting people to take responsibility.
> 
> As core dev you do have responsibility. A contributor uploading
> a patch to a ticket can still rely on the final judgement of the
> core dev applying the patch, so there's less responsibility
> involved for the contributor.
> 
> If the contributor gets to work as core dev early, the motivation
> and feeling for responsibility will change. That's main driver.

I think this is a good point.  We who already are committers might think
that it's not a big deal if the contributor has the commit bit or not,
since the patches are always going to be reviewed by the mentor and/or
others, but it certainly is a difference in feeling for them.

As far back as I can remember, we never had to remove someone's commit
privileges because they wreaked havoc.  That probably means that
a) people are decent and b) our timing of giving commit bits is very
much on the "safe" side.

Georg


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[M.-A. Lemburg]

Hi Ezio,

I think I'm not making myself clear enough :-)

Technically, operations would stay the same (tickets, patches, reviews),
but from a motivational point of view, you change things a lot for the
better if you put trust into people by giving them the commit bit early.

The "incubation" period idea is just meant to make the process clear
to new developers. They should not feel offended if they don't end
up keeping the commit bit.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 10 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


: Try our mxODBC.Connect Python Database Interface for free ! ::

   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/

On 10.01.2015 01:19, Ezio Melotti wrote:
> Hi,
> 
> On Fri, Jan 9, 2015 at 11:47 PM, M.-A. Lemburg  wrote:
>> On 09.01.2015 23:26, Ezio Melotti wrote:
>>> Hi,
>>>
>>> On Fri, Jan 9, 2015 at 1:09 PM, M.-A. Lemburg  wrote:

 BTW: How about having an "incubator" phase for new core devs ?
 The new candidate will get commit rights for say 3 months and
 after those 3 months, the mentor then suggests whether make
 the status permanent or not.

>>>
>>> Not sure this will work too well.  I'm assuming that new candidates
>>> are good developers and reasonable persons that will still be chosen
>>> based on their merits (previous contributions, recommendations from
>>> other core devs, etc.), so nearly all of them will probably get the
>>> permanent status.
>>> I can't imagine many reasons why we wouldn't eventually accept a
>>> candidate.  If they wreak havoc in the repo we will probably remove
>>> their commit rights immediately, if they do something wrong we would
>>> just tell them and they would hopefully fix the problem and keep it in
>>> mind for the next time.  If they really can't figure out/follow our
>>> workflow or have similar problems they will probably gave up being
>>> contributors on their own, even if they still have rights.
>>>
 As long as this is stated clearly from the beginning, I don't
 think people will feel offended if they end up not receiving
 the permanent status, and this will reduce the barrier for
 entry a lot. Learning on the job is a rather common practice
 in the industry these days :-)

>>>
>>> If they do something clearly wrong they shouldn't be surprised if we
>>> revoke their right, 3 months period or not.  If they are just not good
>>> enough they won't be offended but they will probably be disappointed.
>>> Comparing Python with a paid job is also somewhat misleading, since
>>> the only investment we have to do is following the new contributor for
>>> a while and possibly intervene if something goes wrong (e.g. they made
>>> a wrong commit and don't know how to fix it/revert it).  IME this
>>> doesn't happen often and it's not a particularly time-consuming task.
>>>
>>> TL;DR We can give access rights to whoever proves to be up to the task
>>> and willing to contribute, the three month period is not necessary, if
>>> they cause trouble we will just revoke the right (but that shouldn't
>>> happen).
>>
>> Perhaps I wasn't clear about the context. The discussion was
>> focusing on requirements for a new developer to get commit
>> rights.
>>
>> Antoine and Victor argued that new developers should first
>> show their skills by submitting patches to tickets, working
>> with other core devs before getting the commit bit set.
>>
> 
> IMHO if the contributors are already known for their skills, then they
> just need to submit a couple of patches.  This is useful both for the
> contributors (so they get the hang of it and learn the workflow) and
> for the team (so we see they understand the workflow and they are
> indeed up to the task).  If everything is fine then they can get the
> commit bit.  This group includes devs that already work on other
> projects/Python implementations, that have successful packages on
> PyPI, or that are recommended by other core devs.
> 
> If the contributor is relatively "unknown", then he/she has to prove
> that he/she is up to the task by contributing a larger number of
> patches before getting the commit bit.
> 
>> My suggestion was allowing new developers to start committing
>> patches themselves before having worked on dozens of tickets
>> using the usual patch approach.
>>
> 
> The usual patch approach varies from person to person.  Some
> contributors works on dozen of trivial issues before moving to
> something more complex, others specialize on a si

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Berker Peksağ]

On Sat, Jan 10, 2015 at 12:33 PM, M.-A. Lemburg  wrote:
> Hi Ezio,
>
> I think I'm not making myself clear enough :-)
>
> Technically, operations would stay the same (tickets, patches, reviews),
> but from a motivational point of view, you change things a lot for the
> better if you put trust into people by giving them the commit bit early.

Contributing to open source is all about motivation. If people are
already willing to spend their free time working on an open source
project(by writing and/or reviewing patches, for example), I think
they are motivated enough and things like "commit rights", a
@python.org mail address, a Python t-shirt etc. shouldn't be used as
motivational items. From a contributor point of view, I can say that I
would be more motivated if my patches were reviewed and committed in a
shorter time frame (note: I was a contributor until six months ago).

--Berker
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[M.-A. Lemburg]

On 10.01.2015 13:38, Berker Peksağ wrote:
> On Sat, Jan 10, 2015 at 12:33 PM, M.-A. Lemburg  wrote:
>> Hi Ezio,
>>
>> I think I'm not making myself clear enough :-)
>>
>> Technically, operations would stay the same (tickets, patches, reviews),
>> but from a motivational point of view, you change things a lot for the
>> better if you put trust into people by giving them the commit bit early.
> 
> Contributing to open source is all about motivation. If people are
> already willing to spend their free time working on an open source
> project(by writing and/or reviewing patches, for example), I think
> they are motivated enough and things like "commit rights", a
> @python.org mail address, a Python t-shirt etc. shouldn't be used as
> motivational items. From a contributor point of view, I can say that I
> would be more motivated if my patches were reviewed and committed in a
> shorter time frame (note: I was a contributor until six months ago).

... which is the direct result of us not having enough active
committers and this most probably being the result of the process
being too strict, not because there are too few people willing
to work on Python.

Anyway, I think I've made my point now :-) If other committers
feel that we don't need to have a more welcoming approach to
new developers, that's fine.

PS: If there's anything I've learned in the many years working
in and for open-source communities, it's that enabling people
to do collaborative work is the key factor to success. Give them
access, let people make mistakes and fix them, thank them for
doing a great job every now and then.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 10 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...   http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


: Try our mxODBC.Connect Python Database Interface for free ! ::

   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/
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Antoine Pitrou]

Le 10/01/2015 14:53, M.-A. Lemburg a écrit :
> 
> Anyway, I think I've made my point now :-) If other committers
> feel that we don't need to have a more welcoming approach to
> new developers, that's fine.

I half-agree with Berker: the number one problem is enough people to
review patches and guide contributors. Being welcoming is not the same
as giving away commit rights in the hope that people will contribute.

I only half-agree because it seems lately we have been having an
attractivity problem. I may be biased, but I see much less interesting
contributions nowadays than 2/3 years ago. Python may be becoming less
exciting compared to Rust / Go / etc.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Ethan Furman]

On 01/06/2015 11:09 PM, Raymond Hettinger wrote:
> 
> I would like to propose Davin Potts as core developer to take on the 
> responsibility for maintaining the multiprocessing
> package.
> 
> I've been working with him on and off for over a year and found him to be 
> highly skilled, thoughtful, and responsible.
>  He is willing to devote time to a much neglected part of the standard 
> library (186 open issues).  He would be a valued
> member of the team.
> 
> I would be happy to serve as his mentor for his early contributions.

Having read the thread, and seeing that Raymond is willing to vouch for and to 
mentor Davin, I am

+1

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Gregory P. Smith]

+1 for commit access, Raymond volunteered as a mentor.

I agree with MAL, it is more beneficial to trust people and give out commit
access early.

-gregory.p.smith

On Sat Jan 10 2015 at 9:16:26 AM Ethan Furman  wrote:

> On 01/06/2015 11:09 PM, Raymond Hettinger wrote:
> >
> > I would like to propose Davin Potts as core developer to take on the
> responsibility for maintaining the multiprocessing
> > package.
> >
> > I've been working with him on and off for over a year and found him to
> be highly skilled, thoughtful, and responsible.
> >  He is willing to devote time to a much neglected part of the standard
> library (186 open issues).  He would be a valued
> > member of the team.
> >
> > I would be happy to serve as his mentor for his early contributions.
>
> Having read the thread, and seeing that Raymond is willing to vouch for
> and to mentor Davin, I am
>
> +1
>
> --
> ~Ethan~
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Ned Deily]

On Jan 10, 2015, at 12:09, Gregory P. Smith  wrote:
> 
> +1 for commit access, Raymond volunteered as a mentor.
> 
> I agree with MAL, it is more beneficial to trust people and give out commit 
> access early.

+1, for all of those reasons.  My only concern is trying to ensure that Richard 
(sbt) is involved as much as he wishes to be in any work on multiprocessing.

--
  Ned Deily
  n...@acm.org -- []


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Brett Cannon]

I'm +1 as well since Raymond has said he will mentor Davin the way through
and I'm willing to experiment with giving commit rights earlier based on
personal vouching of a core developer.

On Sat Jan 10 2015 at 3:09:43 PM Gregory P. Smith  wrote:

> +1 for commit access, Raymond volunteered as a mentor.
>
> I agree with MAL, it is more beneficial to trust people and give out
> commit access early.
>
> -gregory.p.smith
>
> On Sat Jan 10 2015 at 9:16:26 AM Ethan Furman  wrote:
>
>> On 01/06/2015 11:09 PM, Raymond Hettinger wrote:
>> >
>> > I would like to propose Davin Potts as core developer to take on the
>> responsibility for maintaining the multiprocessing
>> > package.
>> >
>> > I've been working with him on and off for over a year and found him to
>> be highly skilled, thoughtful, and responsible.
>> >  He is willing to devote time to a much neglected part of the standard
>> library (186 open issues).  He would be a valued
>> > member of the team.
>> >
>> > I would be happy to serve as his mentor for his early contributions.
>>
>> Having read the thread, and seeing that Raymond is willing to vouch for
>> and to mentor Davin, I am
>>
>> +1
>>
>> --
>> ~Ethan~
>>
>> ___
>> python-committers mailing list
>> python-committers@python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Antoine Pitrou]

Le 10/01/2015 21:16, Brett Cannon a écrit :
> I'm +1 as well since Raymond has said he will mentor Davin the way
> through and I'm willing to experiment with giving commit rights earlier
> based on personal vouching of a core developer.

We have already experimented with that. People like Jean-Paul Calderone
have been given commit privs and they committed very little.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Brett Cannon]

 On Sat, Jan 10, 2015, 18:01 Antoine Pitrou  wrote:


Le 10/01/2015 21:16, Brett Cannon a écrit :
> I'm +1 as well since Raymond has said he will mentor Davin the way
> through and I'm willing to experiment with giving commit rights earlier
> based on personal vouching of a core developer.

We have already experimented with that. People like Jean-Paul Calderone
have been given commit privs and they committed very little.

 But it wasn't detrimental either. And I don't remember JP having a
specific champion like Raymond. In this instance we have someone who is
staking their reputation on someone.

-Brett


Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https ://
mail.python.org
/mailman/
listinfo

/python-committers

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Antoine Pitrou]

Le 11/01/2015 03:01, Brett Cannon a écrit :
> 
> On Sat, Jan 10, 2015, 18:01 Antoine Pitrou  > wrote:
> 
> 
> Le 10/01/2015 21:16, Brett Cannon a écrit :
> > I'm +1 as well since Raymond has said he will mentor Davin the way
> > through and I'm willing to experiment with giving commit rights
> earlier
> > based on personal vouching of a core developer.
> 
> We have already experimented with that. People like Jean-Paul Calderone
> have been given commit privs and they committed very little.
> 
> But it wasn't detrimental either. And I don't remember JP having a
> specific champion like Raymond. In this instance we have someone who is
> staking their reputation on someone.

So we're talking about champions, stakes and reputation, rather than
building a community?

By the way, did anyone ask Richard what he thought about this?
I am not aware that Raymond is an expert in the multiprocessing module,
how exactly is he gonna evaluate Davin's work?

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] Proposed core developer for contributing to multiprocessing

[Senthil Kumaran]

I have not been active for past year or so. But here is are thoughts on
this process.

The important thing should be "contribution"  and a developer's personal
satisfaction comes from contribution. The commit access IMO is secondary,
but is very important and as it helps contributor to move at a faster pace
and increase his scope.

I think, that anyone who contributes frequently through patches will get
the satisfaction and when a developer who has been committing the patches
notices it, he will automatically suggest the next step of giving the
commit access to person who has been contributing.

I think, this works well instead of giving commit access to encourage
contribution.  My suggestion will be for David to contribute more
frequently, be aligned with more active developers and the commit access
might be an automatic next step.

-- 
Senthil


On Sat, Jan 10, 2015 at 1:01 PM, Ned Deily  wrote:

> On Jan 10, 2015, at 12:09, Gregory P. Smith  wrote:
> >
> > +1 for commit access, Raymond volunteered as a mentor.
> >
> > I agree with MAL, it is more beneficial to trust people and give out
> commit access early.
>
> +1, for all of those reasons.  My only concern is trying to ensure that
> Richard (sbt) is involved as much as he wishes to be in any work on
> multiprocessing.
>
> --
>   Ned Deily
>   n...@acm.org -- []
>
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers