[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 <mal at egenix.com> wrote:
>> On 09.01.2015 23:26, Ezio Melotti wrote:
>>> Hi,
>>>
>>> On Fri, Jan 9, 2015 at 1:09 PM, M.-A. Lemburg <mal at egenix.com> 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 single package, others
> are able to tackle difficult issues right away.  Working on a few
> difficult issues often tells more about the skills of the contributor
> than working on dozen of trivial ones.
> Since most contributors start with simpler issues, it is not uncommon
> that by the time they are comfortable working on complex issues and
> become core devs they already contributed several patches.
> 
>> The incubator phase is meant to check whether the new developer
>> is up to the task he or she signs up for. The mentor keeps checking
>> the code quality during this phase to avoid broken code or
>> backwards incompatible changes which would need more discussion.
>>
> 
> This should happen before the code is committed, so it doesn't matter
> if they have commit rights or not.
> 
>> In summary, we'd allow developers to start taking on responsibilities
>> earlier than in the current process, while still maintaining
>> the high quality standards we have.
>>
>> I may be misunderstanding your reply, but it appears you'd even
>> want to go beyond that, so we're not really in disagreement it
>> seems :-)
>>
> 
> IMHO people can get the commit bit once they proved they are up to the
> task and contributed at least a couple of patches (for the reasons
> stated above).
> 
> Best Regards,
> Ezio Melotti
>