Proposed core developer for contributing to multiprocessing
Hello all,
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.
Raymond
Begin forwarded message:
Date: December 25, 2014 at 6:46:33 AM PST Subject: contributing to multiprocessing From: Davin Potts <davin@appliomics.com> To: Raymond Hettinger <raymond.hettinger@gmail.com>
Hi Raymond --
You asked if I'd be interested in becoming a maintainer for the multiprocessing package -- I've continued thinking about what I can do or trust myself to do and I think it'd be cool to make some serious ongoing contributions around multiprocessing.
A rambling set of thoughts from my looking into multiprocessing....
I've now read many (most?) of Jesse Noller's blog posts relating to multiprocessing, where it stands and where it should go, his calls for help. I've noted Richard Oudkerk's disappearance from the issue comments and mailing lists for a half year or so now -- people are still referencing him, asking for his take, in new issues from as recent as this past week. I'm still a bit unclear on how multiprocessing should ultimately relate to concurrent.futures though that discussion seems to be an ongoing one. Reading through those discussions makes me realize I must come from a different background (massive distributed computing, scientific computing, HPC) -- it's neat to read and try to understand what's going through other peoples' heads here.
I've spent a decent chunk of time now going through the outstanding issues against multiprocessing. As best as I can tell, I'd break the current set of 186 issues mentioning multiprocessing down like this:
- 50% are either junk or otherwise simply outdated-needing-proper-cleanup items,
- 30% are advocating changes to docs to cover edge cases they've encountered,
- 15% are Windows-specific problems needing investigation,
- the remaining 5% are more interesting or nasty topics.
Many of the edge cases people get surprised by in that 30% are complications related to Windows -- I think a goodly chunk of these problems could be prevented if the documentation were re-oriented a bit more (though documentation is not the answer to them all). The thought of documenting every little gotchya or niche these folks encounter is silly and won't help in practical terms. That said, there's enough of these problems to signal that something is definitely sub-optimal.
The overall volume of Windows-related issues reminds me very much of Trent Nelson telling me at the one point that he figured the real reason he was invited to become a committer was because he didn't at all mind working on Windows issues. In a twisted way, I kind of like sorting out Windows issues too.
I'd guess it'd take me 30-60 minutes to carefully go through each item in that big 50% chunk, bringing a healthy number to some closure in an iteration or two. That'll take a bit of time to chew through but seems important.
If I'm up for helping work through the backlog of issues, including debugging Windows issues, how should I start?
Davin
Le 07/01/2015 08:09, Raymond Hettinger a écrit :
Hello all,
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.
Then let Davin contribute before proposing core developer access? I think it is unusual to make core developer someone who's not known by the community (unless he's known and I'm missing something :-)).
Note multiprocessing has received active maintenance by Richard until ~1 year ago.
Regards
Antoine.
Hi,
2015-01-07 9:51 GMT+01:00 Antoine Pitrou <antoine@python.org>:
I would like to propose Davin Potts as core developer to take on the responsibility for maintaining the multiprocessing package.
Did he already contributed to CPython? What is his nickname on the bug tracker? Can we see his previous contributions?
A difficult part of the multiprocessing is the Windows support. Richard knows well the Windows API. It doesn't mean that someone who doesn't know Windows should not be able to contribute ;-)
Then let Davin contribute before proposing core developer access? I think it is unusual to make core developer someone who's not known by the community (unless he's known and I'm missing something :-)).
If David didn't contribute before, I'm against giving him directly the developer access. Different people repeat that you don't need to have the developer access to contribute. Send patches, review patches, comment issues, etc.
We rejected candidates who had many previous contributions, just because they didn't contribute enough.
Victor
On 7 January 2015 at 20:22, Victor Stinner <victor.stinner@gmail.com> wrote:
If David didn't contribute before, I'm against giving him directly the developer access. Different people repeat that you don't need to have the developer access to contribute. Send patches, review patches, comment issues, etc.
We rejected candidates who had many previous contributions, just because they didn't contribute enough.
That's not quite the guideline I personally use - for me, it's more about whether someone being able to commit their own patches is likely to be more efficient overall or not.
If their patches are to a point where the only parts I'm handling are the mechanics of doing the commit (i.e. they're already up to speed on what makes for an appropriate change to the area under consideration), and I trust them to be appropriately cautious when branching out to other areas of the code base, then I'll propose granting them commit access and teaching them the additional steps involved in actually doing the commits and taking responsibility for them.
The key is whether I feel that extra committer review step is still providing value commensurate with the additional time it takes, and that's something which varies on a case by case basis.
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 09.01.2015 12:47, Nick Coghlan wrote:
On 7 January 2015 at 20:22, Victor Stinner <victor.stinner@gmail.com> wrote:
If David didn't contribute before, I'm against giving him directly the developer access. Different people repeat that you don't need to have the developer access to contribute. Send patches, review patches, comment issues, etc.
We rejected candidates who had many previous contributions, just because they didn't contribute enough.
That's not quite the guideline I personally use - for me, it's more about whether someone being able to commit their own patches is likely to be more efficient overall or not.
If their patches are to a point where the only parts I'm handling are the mechanics of doing the commit (i.e. they're already up to speed on what makes for an appropriate change to the area under consideration), and I trust them to be appropriately cautious when branching out to other areas of the code base, then I'll propose granting them commit access and teaching them the additional steps involved in actually doing the commits and taking responsibility for them.
The key is whether I feel that extra committer review step is still providing value commensurate with the additional time it takes, and that's something which varies on a case by case basis.
I'm with Nick here. The itertools module needs a new maintainer. If Davin can be that maintainer, definitely +1 on adding him, under the condition that Raymond provides some oversight in the first few months.
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.
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 :-)
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Jan 09 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/
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.
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 :-)
As someone who received commit rights based entirely (almost?) on willingness rather than contributions, I think this is a great idea. I certainly would not have been at all offended if I'd been told "don't touch anything apart from X and we'll reevaluate in three months." Being clear about it at the start is the important part - having a title like "probationary" or "provisional" makes that pretty easy.
Cheers, Steve
Hi,
On Fri, Jan 9, 2015 at 1:09 PM, M.-A. Lemburg <mal@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).
Best Regards, Ezio Melotti
On 09.01.2015 23:26, Ezio Melotti wrote:
Hi,
On Fri, Jan 9, 2015 at 1:09 PM, M.-A. Lemburg <mal@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.
My suggestion was allowing new developers to start committing patches themselves before having worked on dozens of tickets using the usual patch approach.
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.
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 :-)
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Jan 09 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/
Le 09/01/2015 23:47, M.-A. Lemburg a écrit :
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.
Regards
Antoine.
On Fri, Jan 9, 2015 at 2:52 PM, Antoine Pitrou <antoine@python.org> wrote:
Le 09/01/2015 23:47, M.-A. Lemburg a écrit :
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.
I'm with Antoine here.
-- --Guido van Rossum (python.org/~guido)
On 09.01.2015 23:52, Antoine Pitrou wrote:
Le 09/01/2015 23:47, M.-A. Lemburg a écrit :
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.
In the current case, there's a developer who has not worked on dozens of tickets, but has the trust of Raymond to do a good job at maintaining the multiprocessing module. By giving Davin commit rights with a probation period, we'd be investing trust and hopefully get motivation as return on investment ;-)
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Jan 09 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/
Hi,
On Fri, Jan 9, 2015 at 11:47 PM, M.-A. Lemburg <mal@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@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
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
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@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@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
On Sat, Jan 10, 2015 at 12:33 PM, M.-A. Lemburg <mal@egenix.com> 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
On 10.01.2015 13:38, Berker Peksağ wrote:
On Sat, Jan 10, 2015 at 12:33 PM, M.-A. Lemburg <mal@egenix.com> 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/
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.
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~
+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 <ethan@stoneleaf.us> 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
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
responsibility for maintaining the multiprocessing 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
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 <greg@krypto.org> 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 <ethan@stoneleaf.us> 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
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
responsibility for maintaining the multiprocessing 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
On Jan 10, 2015, at 12:09, Gregory P. Smith <greg@krypto.org> 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 nad@acm.org -- []
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.
On Sat, Jan 10, 2015, 18:01 Antoine Pitrou <antoine@python.org> 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 <https://mail.python.org/mailman/listinfo/python-committers>:// <https://mail.python.org/mailman/listinfo/python-committers>mail.python.org <https://mail.python.org/mailman/listinfo/python-committers>/mailman/ <https://mail.python.org/mailman/listinfo/python-committers>listinfo <https://mail.python.org/mailman/listinfo/python-committers> /python-committers <https://mail.python.org/mailman/listinfo/python-committers>
Le 11/01/2015 03:01, Brett Cannon a écrit :
On Sat, Jan 10, 2015, 18:01 Antoine Pitrou <antoine@python.org <mailto:antoine@python.org>> 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.
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 <nad@acm.org> wrote:
On Jan 10, 2015, at 12:09, Gregory P. Smith <greg@krypto.org> 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 nad@acm.org -- []
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
On Jan 10, 2015, at 12:09 PM, Gregory P. Smith <greg@krypto.org> wrote:
I agree with MAL, it is more beneficial to trust people and give out commit access early.
For comparison, I think that is the norm for paid work. At companies I've worked for, new programmers are given check-in rights on the first day.
To have become the Chief Data Scientist at Continuum, Davin had to impress the likes of Travis Oliphant and Peter Wang. I've certainly been impressed with how carefully and thoroughly he researches and thinks through everything he does.
Dr. Potts brings a rich skill set and has volunteered to put substantial time into a complex module with many outstanding bugs and that has long been in need of some love.
He's already spent time researching past discussions on the multiprocessing module, reading all of the 180+ open bugs to assess what needs to be done, and preparing two patches currently open on the tracker.
We should at least grant him developer privileges on the tracker
to it much easier for him to move the tracker items forward.
As far as I can tell, no other developer is showing active
interest in those issues (though Antoine did just commit
one of Davin's patches).
Commit rights are a separate issue, but I wouldn't see the point in saying no there either. The final step of committing your work is easy part. The hard part is forming a coherent view of the package as a whole, triaging the open bugs, preparing patches, and engaging in discussion with interested parties (if any).
Raymond
Le 11/01/2015 21:26, Raymond Hettinger a écrit :
We should at least grant him developer privileges on the tracker to it much easier for him to move the tracker items forward.
I just gave him developer privileges (or at least I hope so - I added the role "Developer").
As far as I can tell, no other developer is showing active interest in those issues (though Antoine did just commit
one of Davin's patches).
Interest tends to rise when patches are posted :-) Although of course some patches also linger...
Regards
Antoine.
participants (15)
-
Antoine Pitrou -
Berker Peksağ -
Brett Cannon -
Ethan Furman -
Ezio Melotti -
Georg Brandl -
Gregory P. Smith -
Guido van Rossum -
M.-A. Lemburg -
Ned Deily -
Nick Coghlan -
Raymond Hettinger -
Senthil Kumaran -
Steve Dower -
Victor Stinner