Re: [python-committers] Proposed core developer for contributing to multiprocessing
On Jan 10, 2015, at 12:09 PM, Gregory P. Smith g...@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 ___ 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
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. ___ 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
On 10.01.2015 13:38, Berker Peksağ wrote: On Sat, Jan 10, 2015 at 12:33 PM, M.-A. Lemburg m...@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/ ___ 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
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
+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 et...@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 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
On Jan 10, 2015, at 12:09, Gregory P. Smith g...@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 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
Le 11/01/2015 03:01, Brett Cannon a écrit : On Sat, Jan 10, 2015, 18:01 Antoine Pitrou anto...@python.org mailto:anto...@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. ___ 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
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
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 n...@acm.org wrote: On Jan 10, 2015, at 12:09, Gregory P. Smith g...@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 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
Re: [python-committers] Proposed core developer for contributing to multiprocessing
On Sat, Jan 10, 2015, 18:01 Antoine Pitrou anto...@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-committersmail.python.org https://mail.python.org/mailman/listinfo/python-committers/mailman/ https://mail.python.org/mailman/listinfo/python-committerslistinfo https://mail.python.org/mailman/listinfo/python-committers /python-committers 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
Hi, On Fri, Jan 9, 2015 at 11:47 PM, M.-A. Lemburg m...@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 m...@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 ___ python-committers mailing list python-committers@python.org
Re: [python-committers] Proposed core developer for contributing to multiprocessing
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/ ___ 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
Hi, On Fri, Jan 9, 2015 at 1:09 PM, M.-A. Lemburg m...@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 ___ 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
On 09.01.2015 12:47, Nick Coghlan wrote: On 7 January 2015 at 20:22, Victor Stinner victor.stin...@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/ ___ 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
On 7 January 2015 at 20:22, Victor Stinner victor.stin...@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 | ncogh...@gmail.com | Brisbane, Australia ___ 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
Hi, 2015-01-07 9:51 GMT+01:00 Antoine Pitrou anto...@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 ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
