Enhanced tracker privileges for "dangerjim" to do triage.
I'm trying to get a good friend of mine to start doing bug triage on Python. As part of my trying to mentor him on it, I've found that many of the common things I do in triage, like setting a priority for priorityless bugs, assigning them to people who obviously are the next step, requires enhanced privileges. He has no reputation in the Python community, so I'd be up for getting him started on things that require fewer privileges like verifying older patches still apply against newer Pythons, or maybe summarizing priority/assignment changes to the list and having someone (possibly me) make the changes, etc... However, I will step up for him and say that I've known him a decade, and he's very trustworthy. He has been the president (we call that position Maximum Leader) of our Linux Users Group here for 5 years or so. Thoughts? Thanks, Sean -- Sean Reifschneider, Member of Technical Staff <jafo@tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
Sean> However, I will step up for him and say that I've known him a Sean> decade, and he's very trustworthy. He has been the president (we Sean> call that position Maximum Leader) of our Linux Users Group here Sean> for 5 years or so. Given that Sean is vouching for him I'm fine with it. Skip
<skip <at> pobox.com> writes:
Sean> However, I will step up for him and say that I've known him a Sean> decade, and he's very trustworthy. He has been the president (we Sean> call that position Maximum Leader) of our Linux Users Group here Sean> for 5 years or so.
Given that Sean is vouching for him I'm fine with it.
I'm not sure I agree. Of course it could be argued the risk is minimal, but I think it's better if all people go through the same path of proving their motivation and quality of work. And if there's something wrong with that process we'd better address it than give random privileges to people we like :) Regards Antoine.
>> Given that Sean is vouching for him I'm fine with it. Antoine> I'm not sure I agree. Of course it could be argued the risk is Antoine> minimal, but I think it's better if all people go through the Antoine> same path of proving their motivation and quality of work. And Antoine> if there's something wrong with that process we'd better Antoine> address it than give random privileges to people we like :) Let me expand on my original message. Sean has been an integral part of the Python community for many years, keeping much of our hardware and software humming and providing critical network expertise at PyCon. I don't think we have to be such slaves to a set of rules that we can't use an implicit trust network to make decisions in certain cases. I trust Sean's judgement. Skip
2010/4/25 <skip@pobox.com>:
>> Given that Sean is vouching for him I'm fine with it.
Antoine> I'm not sure I agree. Of course it could be argued the risk is Antoine> minimal, but I think it's better if all people go through the Antoine> same path of proving their motivation and quality of work. And Antoine> if there's something wrong with that process we'd better Antoine> address it than give random privileges to people we like :)
Let me expand on my original message. Sean has been an integral part of the Python community for many years, keeping much of our hardware and software humming and providing critical network expertise at PyCon. I don't think we have to be such slaves to a set of rules that we can't use an implicit trust network to make decisions in certain cases. I trust Sean's judgement.
I don't think Antoine is questioning Sean's judgement but rather that we should get into the habit of giving some people "shortcuts" through the regular process. -- Regards, Benjamin
Le Sun, 25 Apr 2010 16:59:14 -0500, Benjamin Peterson a écrit :
I don't think Antoine is questioning Sean's judgement but rather that we should get into the habit of giving some people "shortcuts" through the regular process.
Yes, exactly. If we often take shortcuts with our own process, it can appear unfair and demotivating to regular people (who must go through the normal process). I'm sure we all know people who are demonstrably competent in other communities, still we don't give them privileges right away.
On Sun, Apr 25, 2010 at 10:18:47PM +0000, Antoine Pitrou wrote:
I don't think Antoine is questioning Sean's judgement but rather that we should get into the habit of giving some people "shortcuts" through the regular process.
Yes, exactly. If we often take shortcuts with our own process, it can appear unfair and demotivating to regular people (who must go through the normal process).
I agree with Antoine's point here. As much as I respect Sean and his contributions, it is important to consider the implications as it may appear to others. If you look at Daniel Diniz, who has enhanced tracker privileges, he started off by using the normal tracker privilege commenting on bugs, patches and within *weeks*, he started triaging bugs with enhanced privs. That kind of seems to me a middle-way, as in you start off triaging in a normal mode with a backing of mentor, it becomes a easy way to upgrade very soon. -- Senthil Man must shape his tools lest they shape him. -- Arthur R. Miller
On 09:39 pm, solipsis@pitrou.net wrote:
<skip <at> pobox.com> writes:
Sean> However, I will step up for him and say that I've known him a Sean> decade, and he's very trustworthy. He has been the president (we Sean> call that position Maximum Leader) of our Linux Users Group here Sean> for 5 years or so.
Given that Sean is vouching for him I'm fine with it.
I'm not sure I agree. Of course it could be argued the risk is minimal, but I think it's better if all people go through the same path of proving their motivation and quality of work. And if there's something wrong with that process we'd better address it than give random privileges to people we like :)
+1 As others have said, I don't have any problem with Sean's judgement. That's not what's being questioned here. Jean-Paul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antoine Pitrou wrote:
<skip <at> pobox.com> writes:
Sean> However, I will step up for him and say that I've known him a Sean> decade, and he's very trustworthy. He has been the president (we Sean> call that position Maximum Leader) of our Linux Users Group here Sean> for 5 years or so.
Given that Sean is vouching for him I'm fine with it.
I'm not sure I agree. Of course it could be argued the risk is minimal, but I think it's better if all people go through the same path of proving their motivation and quality of work. And if there's something wrong with that process we'd better address it than give random privileges to people we like :)
I think there is a definite "unpriced externality" to keeping the process barriers high here. I don't belive from conversations at the language summit / PyCon that the community is being overrun with hordes of unworthies clamoring to triage Python bugs: rather the opposite, in fact. It seems to me that backing from an established community member ought to be enough to get a prospective triageur at least provisional roles to do the work, with the caveat that it might be revoked it it didn't turn out well. If it does turn out well, then look to *expand* that user's roles in the community, with a nice helping of public acclaim to go with it. I am not arguing for "making exceptions for friends" here; rather that the acknowledged issues with inclusiveness / espansion of the developer community require making changes to the rules to encourage more participation. BTW, language like "prov[ing] their motivation" is itself demotivating, and likely contributes to the status quo ante. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvUxqMACgkQ+gerLs4ltQ7Z9gCgn9Rox2dPLR/Vkj9WLMziUdcl 9a8AoLgzXSIUAKsibm1e2ww9feBNd3P/ =iHgN -----END PGP SIGNATURE-----
Tres Seaver wrote:
Antoine Pitrou wrote:
<skip <at> pobox.com> writes:
Sean> However, I will step up for him and say that I've known him a Sean> decade, and he's very trustworthy. He has been the president (we Sean> call that position Maximum Leader) of our Linux Users Group here Sean> for 5 years or so.
Given that Sean is vouching for him I'm fine with it.
I'm not sure I agree. Of course it could be argued the risk is minimal, but I think it's better if all people go through the same path of proving their motivation and quality of work. And if there's something wrong with that process we'd better address it than give random privileges to people we like :)
I think there is a definite "unpriced externality" to keeping the process barriers high here. I don't belive from conversations at the language summit / PyCon that the community is being overrun with hordes of unworthies clamoring to triage Python bugs: rather the opposite, in fact. It seems to me that backing from an established community member ought to be enough to get a prospective triageur at least provisional roles to do the work, with the caveat that it might be revoked it it didn't turn out well. If it does turn out well, then look to *expand* that user's roles in the community, with a nice helping of public acclaim to go with it.
I am not arguing for "making exceptions for friends" here; rather that the acknowledged issues with inclusiveness / espansion of the developer community require making changes to the rules to encourage more participation.
BTW, language like "prov[ing] their motivation" is itself demotivating, and likely contributes to the status quo ante.
With my PSF hat on I'd like to support Tres here (and, by extension, Sean's proposal). Lowering the barriers of entry is a desirable goal. If adding people created work for already-busy developers then I'd be against it*, but with Sean offering to mentor his new protege and ensure that he limits his role to triage initially that doesn't seem to be an issue. Maybe it's time to review the way people "prove their motivation and the quality of their work"? regards Steve * I'd be against it, but I'd fight to change the development process so that adding new people *didn't* create work. We should, in my opinion, be looking for a continual influx of new worker bees. -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
On 26/04/2010 00:18, Steve Holden wrote:
Tres Seaver wrote:
Antoine Pitrou wrote:
<skip<at> pobox.com> writes:
Sean> However, I will step up for him and say that I've known him a Sean> decade, and he's very trustworthy. He has been the president (we Sean> call that position Maximum Leader) of our Linux Users Group here Sean> for 5 years or so.
Given that Sean is vouching for him I'm fine with it.
I'm not sure I agree. Of course it could be argued the risk is minimal, but I think it's better if all people go through the same path of proving their motivation and quality of work. And if there's something wrong with that process we'd better address it than give random privileges to people we like :)
I think there is a definite "unpriced externality" to keeping the process barriers high here. I don't belive from conversations at the language summit / PyCon that the community is being overrun with hordes of unworthies clamoring to triage Python bugs: rather the opposite, in fact. It seems to me that backing from an established community member ought to be enough to get a prospective triageur at least provisional roles to do the work, with the caveat that it might be revoked it it didn't turn out well. If it does turn out well, then look to *expand* that user's roles in the community, with a nice helping of public acclaim to go with it.
I am not arguing for "making exceptions for friends" here; rather that the acknowledged issues with inclusiveness / espansion of the developer community require making changes to the rules to encourage more participation.
BTW, language like "prov[ing] their motivation" is itself demotivating, and likely contributes to the status quo ante.
With my PSF hat on I'd like to support Tres here (and, by extension, Sean's proposal). Lowering the barriers of entry is a desirable goal.
If adding people created work for already-busy developers then I'd be against it*, but with Sean offering to mentor his new protege and ensure that he limits his role to triage initially that doesn't seem to be an issue.
Maybe it's time to review the way people "prove their motivation and the quality of their work"?
Perhaps mentoring by an established committer could become a *standard* acceptable way to gain tracker privileges. It makes a lot of sense for the barriers to entry for bug triaging to be substantially lower than for commit privileges. I agree that we should try and establish straightforward and consistent procedures, but also agree that those procedures should serve the community rather than vice-versa. All the best, Michael
regards Steve
* I'd be against it, but I'd fight to change the development process so that adding new people *didn't* create work. We should, in my opinion, be looking for a continual influx of new worker bees.
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On 25 Apr, 11:18 pm, steve@holdenweb.com wrote:
Tres Seaver wrote:
Antoine Pitrou wrote:
<skip <at> pobox.com> writes:
Sean> However, I will step up for him and say that I've known him a Sean> decade, and he's very trustworthy. He has been the president (we Sean> call that position Maximum Leader) of our Linux Users Group here Sean> for 5 years or so.
Given that Sean is vouching for him I'm fine with it.
I'm not sure I agree. Of course it could be argued the risk is minimal, but I think it's better if all people go through the same path of proving their motivation and quality of work. And if there's something wrong with that process we'd better address it than ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Don't overlook this part of Antoine's post.
give random privileges to people we like :)
I think there is a definite "unpriced externality" to keeping the process barriers high here. I don't belive from conversations at the language summit / PyCon that the community is being overrun with hordes of unworthies clamoring to triage Python bugs: rather the opposite, in fact. It seems to me that backing from an established community member ought to be enough to get a prospective triageur at least provisional roles to do the work, with the caveat that it might be revoked it it didn't turn out well. If it does turn out well, then look to *expand* that user's roles in the community, with a nice helping of public acclaim to go with it.
I am not arguing for "making exceptions for friends" here; rather that the acknowledged issues with inclusiveness / espansion of the developer community require making changes to the rules to encourage more participation.
BTW, language like "prov[ing] their motivation" is itself demotivating, and likely contributes to the status quo ante.
With my PSF hat on I'd like to support Tres here (and, by extension, Sean's proposal). Lowering the barriers of entry is a desirable goal.
If adding people created work for already-busy developers then I'd be against it*, but with Sean offering to mentor his new protege and ensure that he limits his role to triage initially that doesn't seem to be an issue.
Maybe it's time to review the way people "prove their motivation and the quality of their work"?
Sounds good. Why is the barrier for this permission any higher than someone asking for it? Is there really a need to protect against contributors with malicious intent? I think there should be a page on python.org that says all contributors are welcome, and one way to become a contributor is to wrangle the issue tracker, and explains what this involves (I don't really have any idea, actually; I assume it's things like setting the owner of new tickets to someone who might actually fix it, things that would happen automatically if roundup had the right information), and then anyone who steps up gets the necessary access. Jean-Paul
regards Steve
* I'd be against it, but I'd fight to change the development process so that adding new people *didn't* create work. We should, in my opinion, be looking for a continual influx of new worker bees. -- Steve Holden +1 571 484 6266 +1 800 494 3119
Sounds good. Why is the barrier for this permission any higher than someone asking for it? Is there really a need to protect against contributors with malicious intent?
There is a little risk. People doing triage can make two common mistakes, and both do happen in the Python tracker from time to time: a) they reject some contribution, even though a long-time contributor might have accepted it with modifications; sometimes this rejection happens for overly formal reasons, and b) they assign issues to someone who might be formally in charge, but is unlikely to act on the issue in a reasonable amount of time. Of course, long-term contributors can and do also make the same mistakes; it's just that new people are often unfamiliar with the conventions. This was all in the abstract, independent of dangerjim (whom I don't know). Regards, Martin
On Mon, Apr 26, 2010 at 08:33, "Martin v. Löwis" <martin@v.loewis.de> wrote:
There is a little risk. People doing triage can make two common mistakes, and both do happen in the Python tracker from time to time: a) they reject some contribution, even though a long-time contributor might have accepted it with modifications; sometimes this rejection happens for overly formal reasons, and b) they assign issues to someone who might be formally in charge, but is unlikely to act on the issue in a reasonable amount of time.
Sure. But these errors can be fixed, just as a checkin can be reverted. That's what I mean with the risk being low, you can't make permanent damage. The Zope community gives commit access by recommendation. This works well. The easier it is to contribute, the more people contributes. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Mon, Apr 26, 2010 at 02:25:33AM -0000, exarkun@twistedmatrix.com wrote:
I think there should be a page on python.org that says all contributors are welcome, and one way to become a contributor is to wrangle the issue tracker, and explains what this involves (I don't really have any idea, actually; I assume it's things like setting
Actually there already is such a page: http://www.python.org/dev/contributing/ . Excerpt: If you have helped out in the issue tracker for a little while or have been a good participant on python-dev you may ask for Developer privileges on the tracker which allow you to change any and all metadata on an issue. Please don't be shy about asking for the privilege! We are more liberal with giving out this ability than with commit privileges, so you don't need to have been contributing for a year to gain this ability. And with Developer privileges you can work more autonomously and be an even greater help by narrowing down what issues on the tracker deserve the most attention at any one time. Issue workflow is specified in http://www.python.org/dev/workflow/. Suggestions for text improvements/changes are welcomed. --amk
If adding people created work for already-busy developers then I'd be against it*
I most certainly does create work, but that could be as little as sending an email message to some administrator. There is no other way: somebody will have to make a decision, and that is "work". Regards, Martin
Martin v. Löwis wrote:
If adding people created work for already-busy developers then I'd be against it*
I most certainly does create work, but that could be as little as sending an email message to some administrator.
There is no other way: somebody will have to make a decision, and that is "work".
Well, I'm sorry to have put you to the work of penning that reply, when you could have used the effort instead to triage a bug. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
Tres Seaver writes:
I think there is a definite "unpriced externality" to keeping the process barriers high here.
The proposed trial period is not a high barrier, except to those who really didn't want to being doing the work anyway. Note that There is also an externality to having accounts with unused privileges lying around the server. The fact is that there just aren't very many people willing to do the work. I've considered doing it (especially since Daniel has gone out of his way to inform me of fixes to the Python tracker, since I maintain a couple of Roundup instances for other projects), but I just don't have the time. Both personally and in general, I really don't think this barrier is high enough that removal would make a significant difference. The example of Daniel Diniz *is* salient. A couple of weeks of doing things the long way (which forces the mentor to look at them, among other things), a week for discussion by the people who work most closely with the candidate and the administrators of the host/tracker where privileges will be granted -- if this matters in the grand scheme of things, the person probably didn't want to be doing the work in the first place. They should find a way to contribute more suited to their capabilities and interests.
I am not arguing for "making exceptions for friends" here; rather that the acknowledged issues with inclusiveness / espansion of the developer community require making changes to the rules to encourage more participation.
BTW, language like "prov[ing] their motivation" is itself demotivating, and likely contributes to the status quo ante.
Unlikely IMHO. Yes, if you allow anybody to make changes, you'll get more contributions. You'll also create a lot of janitorial work for the people who take care of project hygiene, and *they* will lose incentive. That is a *really* big risk. Remember, because of the sexiness/mission criticality of the Linux kernel, a couple of *hundred* people world wide get paid to spend significant amounts of time on it. That's not the comparison to make here; Python is a great language, but there are several reasonable alternatives, and it's not suited to all projects. Look at the 99.5% of Sourceforge projects (or the fact that GNU Savannah can't attract contributions to get the "official" GNU VCS -- Bazaar -- working properly), and you'll see that Python actually has a really well- functioning, attractive process.
I'd say there is something wrong with the process. If a trusted developer can't get somebody more privilege on the tracker by saying that "I trust this guy", then a new process is needed. That's it's too hard to get privileges in the Python development community has been evident too long, I think. There is one privilege that should be hard to get: Permanent delete. But being able to triage bugs isn't such a privilege. Heck, not even commit access is, because of someone makes something bad, you can back out the checkin. Giving people rights to a bugtracker or versioning system is not dangerous, and should not be hard. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
Lennart Regebro writes:
I'd say there is something wrong with the process. If a trusted developer can't get somebody more privilege on the tracker by saying that "I trust this guy", then a new process is needed. That's it's too hard to get privileges in the Python development community has been evident too long, I think.
It is entirely *not* evident to me that it's too hard to get privileges in the Python development community (Python's development process works -- and it works really well by comparison to 99% of the processes out there). And processes are delicate; they should be changed only when the people involved in them have the time and inclination to work on rebalancing them.
There is one privilege that should be hard to get: Permanent delete. But being able to triage bugs isn't such a privilege. Heck, not even commit access is, because of someone makes something bad, you can back out the checkin.
Sure, but that's still *work*, and it's work for *somebody else*. The person who made the mistake is unlikely to detect it, and needs to be told to fix it, if they even fix it themselves.
Giving people rights to a bugtracker or versioning system is not dangerous, and should not be hard.
As someone who does a lot more managing of shared resources than coding in the projects I'm active in, I disagree about the danger. Enthusiastic newbies can do a lot of minor damage in a short period of time, and cleaning that up is *work*. This danger is almost entirely mitigated by a small amount of mentoring -- which is precisely what the current process requires -- not only of the recomending party, but also of the existing workers. I'm not claiming that the current balance is right. Just that it's not obvious that it's *wrong*, and therefore the decision should be left up to the people who will do the mentoring, the supervision, and -- if necessary -- the cleanup. If the existing tracker crew is happy with Sean's recommendation, and similar recommendations in the future, I'm happy too. But it is a process change, and they should be comfortable with it.
On 26/04/2010 11:58, Stephen J. Turnbull wrote:
[snip...]
I'm not claiming that the current balance is right.
Hmm... the core development team (those who make commits once a month or more frequently) is very small, the number of people doing bug triaging is currently good but also small. We have patches and issues in the tracker that may have responses but will never get properly looked at because no-one on the core team is interested or has the mental bandwidth, we have possibly hundreds of modules in the standard library without a maintainer. I think it is very much in the interest of Python to evolve our processes in order to encourage more core-developers. Evolving means experimenting *and* being willing to change. It is certainly less *effort* to accept the status quo, but with several more committed and enthusiastic (and good) core developers there is an awful lot (more) we could achieve. All the best, Michael Foord
Just that it's not obvious that it's *wrong*, and therefore the decision should be left up to the people who will do the mentoring, the supervision, and -- if necessary -- the cleanup. If the existing tracker crew is happy with Sean's recommendation, and similar recommendations in the future, I'm happy too. But it is a process change, and they should be comfortable with it.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
Hello,
I think it is very much in the interest of Python to evolve our processes in order to encourage more core-developers. Evolving means experimenting *and* being willing to change. It is certainly less *effort* to accept the status quo, but with several more committed and enthusiastic (and good) core developers there is an awful lot (more) we could achieve.
I certainly agree we should try to attract more good-willed and competent contributors. I also agree with Stephen that, in a project with a non-trivial amount of complexity such as CPython, not having (tracker or commit) privileges is not the real barrier to entry. You have to learn how the software works, how its development works, who are the people working on it, etc. Regards Antoine.
On 4/26/2010 7:24 AM, Antoine Pitrou wrote:
I think it is very much in the interest of Python to evolve our processes in order to encourage more core-developers. Evolving means experimenting *and* being willing to change. It is certainly less *effort* to accept the status quo, but with several more committed and enthusiastic (and good) core developers there is an awful lot (more) we could achieve.
I certainly agree we should try to attract more good-willed and competent contributors.
I also agree with Stephen that, in a project with a non-trivial amount of complexity such as CPython, not having (tracker or commit) privileges is not the real barrier to entry. You have to learn how the software works, how its development works, who are the people working on it, etc.
I'd like to respond to Michael's comment about the "possibly hundreds of modules in the standard library without a maintainer." My own experience (issue5949) has been positive despite the lack of a dedicated maintainer. When I had my own itch to scratch, nobody stopped me from scratching it.. some people told me when I could scratch it and how they'd like it scratched.. but I wasn't ignored or rejected despite the lack of a maintainer. Thanks to RDM for giving my issue attention. -- Scott Dial scott@scottdial.com scodial@cs.indiana.edu
On 26/04/2010 12:40, Scott Dial wrote:
On 4/26/2010 7:24 AM, Antoine Pitrou wrote:
I think it is very much in the interest of Python to evolve our processes in order to encourage more core-developers. Evolving means experimenting *and* being willing to change. It is certainly less *effort* to accept the status quo, but with several more committed and enthusiastic (and good) core developers there is an awful lot (more) we could achieve.
I certainly agree we should try to attract more good-willed and competent contributors.
I also agree with Stephen that, in a project with a non-trivial amount of complexity such as CPython, not having (tracker or commit) privileges is not the real barrier to entry. You have to learn how the software works, how its development works, who are the people working on it, etc.
I'd like to respond to Michael's comment about the "possibly hundreds of modules in the standard library without a maintainer." My own experience (issue5949) has been positive despite the lack of a dedicated maintainer. When I had my own itch to scratch, nobody stopped me from scratching it.. some people told me when I could scratch it and how they'd like it scratched.. but I wasn't ignored or rejected despite the lack of a maintainer. Thanks to RDM for giving my issue attention.
Right, but finding counterexamples is not at all hard... Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On 26/04/2010 12:24, Antoine Pitrou wrote:
Hello,
I think it is very much in the interest of Python to evolve our processes in order to encourage more core-developers. Evolving means experimenting *and* being willing to change. It is certainly less *effort* to accept the status quo, but with several more committed and enthusiastic (and good) core developers there is an awful lot (more) we could achieve.
I certainly agree we should try to attract more good-willed and competent contributors.
I also agree with Stephen that, in a project with a non-trivial amount of complexity such as CPython, not having (tracker or commit) privileges is not the real barrier to entry. You have to learn how the software works, how its development works, who are the people working on it, etc.
So the question remains - for *tracker* privileges, should the recommendation and commitment to mentor from an established commiter be sufficient (and therefore a standard part of our process)? I think this is a reasonable barrier for entry and should be acceptable. It should be stated as part of our standard procedure however rather than being an exception to our standard procedure. All the best, Michael
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Mon, 26 Apr 2010 12:45:34 +0100, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
So the question remains - for *tracker* privileges, should the recommendation and commitment to mentor from an established commiter be sufficient (and therefore a standard part of our process)?
I think that in a technical sense a commitment to mentoring by an established contributor would be enough. But it seems to me that there are a couple of arguments against it being sufficient in the wider picture. The first is that open source projects tend to be meritocracies. An otherwise unknown person being introduced to the community and immediately given privileges *just* because of the recommendation of another person may feel (especially to the non privileged) like a kind of nepotism. ("It's not what you contribute, it's who you know"). The second is in some ways a subtle variation on the first. If a new person, even with a well respected mentor standing behind them, first approaches the tracker by reviewing and commenting without privileges, it does two things: it allows people in the community who are not the mentor to get a sense of them, and it gives them the benefit of input from people other than the mentor, and all of this happens *before* they have the opportunity (and the worry) of making mistakes(*). Both of these things serve to build community, and the second, IMO, results in a stronger, more confident contributor. I think that someone who has a mentor sponsoring them from the first should be able to go from zero to privileged in a very short period of time (a couple weeks perhaps, mostly depending on their activity level). Someone without a pre-existing mentor could do the same, if their activity level is high enough, and would probably pick up a mentor along the way...or be mentored by #python-dev as a whole if they hang out there. In other words, I think the goal is not just to add new developers to the community, but to continue to build a strong community of developers. -- R. David Murray www.bitdance.com (*) Even a seasoned developer from another project will make mistakes because some of our development process is a part of our culture and not written down, and even that which is written down is not necessarily easy for a newcomer to absorb by reading.
On Tue, 27 Apr 2010 01:42:10 am R. David Murray wrote:
On Mon, 26 Apr 2010 12:45:34 +0100, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
So the question remains - for *tracker* privileges, should the recommendation and commitment to mentor from an established commiter be sufficient (and therefore a standard part of our process)?
I think that in a technical sense a commitment to mentoring by an established contributor would be enough. But it seems to me that there are a couple of arguments against it being sufficient in the wider picture.
The first is that open source projects tend to be meritocracies. An otherwise unknown person being introduced to the community and immediately given privileges *just* because of the recommendation of another person may feel (especially to the non privileged) like a kind of nepotism. ("It's not what you contribute, it's who you know").
Hang on, are we talking about paying these people? Giving them keys to the executive washroom? Flying them around the world on First Class flights on expensive junkets? Fame and fortune? What privileges are we giving them? Oh yeah, the privilege of working for nothing in a thankless job that takes time and effort and returns nothing but a bullet point on your resume and the knowledge that you've given back to an Open Source project. Who are we worried about offending? The crowds on the Internet who never volunteer for anything, who never submit patches, let alone offer to do the unglamourous work? I think we worry too much about them -- they complain about everything, and have the attention span of a gnat. (Yes, I have had a bad day, why do you ask? *wink*) Other committers? I would hope that, being members of good standing in a meritocracy, they can recognise the difference between "I want my mate to be given triaging privileges because he's my mate", and "I want him to have triaging privileges because I trust him to do a good job". As I see it, the only people who might have a valid reason to be offended or annoyed are those who have volunteered but were rejected for some reason --perhaps because their skills aren't good enough, perhaps because nobody could vouch that their skills are good enough. Well, life is hard, get over it. In a meritocracy it isn't enough to be good at what you do, you also have to be known to be good. DangerJim has (apparently -- I don't know him myself) spent years building *both* his technical skills and his reputation. Sean is willing to vouch for him and mentor him, and if Sean himself has a sufficiently high reputation that Python-Dev is willing to trust his judgement, then I can't see any reason to reject the offer. What's the worst that could happen? He'll do a bad job of triaging bugs, other committers will have to step in and fix it, and Sean will be embarrassed. Nothing irreparable, except possibly Sean's reputation as a judge of others. I don't see this as a high risk move: we're not making him BDFL on Sean's say-so.
The second is in some ways a subtle variation on the first. If a new person, even with a well respected mentor standing behind them, first approaches the tracker by reviewing and commenting without privileges, it does two things: it allows people in the community who are not the mentor to get a sense of them,
Yes, they will have the opportunity, but will they take it? I've submitted two recent patches which have apparently been swallowed by the black hole of "too much to do, too little time to do it". Am I bitter? No, of course not -- I understand that the committers have much to do, I'm a comparative unknown, and while the patches scratch my itch, they obviously don't scratch anyone else's. But this does demonstrate that just because people have the opportunity to "get a sense of them", doesn't mean that they actually will do so -- if anything, the opposite is the case. By increasing the number of untrusted contributors relative to trusted committers, you increase the burden on committers and lower the chances that they will actually review patches. This in turn discourages people from contributing, and the cycle continues. Instead of this vicious circle, I believe that fast-tracking people on the strength of recommendations from *trusted* members is a good way of getting a virtuous circle: more people available to review patches, which means more competent contributors will gain enough of a reputation to be given committer privileges.
and it gives them the benefit of input from people other than the mentor, and all of this happens *before* they have the opportunity (and the worry) of making mistakes(*). Both of these things serve to build community, and the second, IMO, results in a stronger, more confident contributor.
Surely this will depend on the personality of the contributor? Not everyone appreciates being examined like that, even in an informal ad-hoc way, and while they might suck it up and accept it, they don't necessarily benefit from it. I reckon that for every one or two would-be contributors who value having that early oversight, you probably alienate a third enough that he goes elsewhere. -- Steven D'Aprano
Steven D'Aprano <steve <at> pearwood.info> writes:
Who are we worried about offending? The crowds on the Internet who never volunteer for anything, who never submit patches, let alone offer to do the unglamourous work?
Perhaps you should look more carefully. We do have contributors who submit patches and advice on the tracker. There isn't just the committers and the passive masses. (oh, and following your logic, we should ignore your advice, unless you actually contribute to the "unglamourous work" - do you?)
In a meritocracy it isn't enough to be good at what you do, you also have to be known to be good.
If this were the criterion then the answer would be simple: nobody seems to knows dangerjim in the Python community. (to make it clear: this is not a shot intended at him, rather at your own logic)
Antoine Pitrou wrote:
Steven D'Aprano <steve <at> pearwood.info> writes:
Who are we worried about offending? The crowds on the Internet who never volunteer for anything, who never submit patches, let alone offer to do the unglamourous work?
Perhaps you should look more carefully. We do have contributors who submit patches and advice on the tracker. There isn't just the committers and the passive masses.
Yes, in the last year in particular there has been some excellent effort of maintaining the issue tracker content. But the question still remains - who are we worried about offending?
(oh, and following your logic, we should ignore your advice, unless you actually contribute to the "unglamourous work" - do you?)
In a meritocracy it isn't enough to be good at what you do, you also have to be known to be good.
If this were the criterion then the answer would be simple: nobody seems to knows dangerjim in the Python community.
Except, of course, the person recommending him. And it seems from the discussion that nobody is particularly bothered about finding out about him, preferring to exercise their various prejudices in preference to taking a PSF member's word that he's a potentially valuable contributor along with an offer of supervision. I didn't realize we had so much effort available that we can ignore such offers.
(to make it clear: this is not a shot intended at him, rather at your own logic)
To make it clear: this is not intended as a criticism of you personally, rather of those who do not seem to feel that increasing the developer community is important. Perhaps diversity is just something you write in a statement. Some of the comments in this thread have seemed positively unwelcoming, even though I doubt that was the authors' intention. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
On 4/26/2010 2:15 PM, Steve Holden wrote:
If this were the criterion then the answer would be simple: nobody seems to knows dangerjim in the Python community.
Except, of course, the person recommending him. And it seems from the discussion that nobody is particularly bothered about finding out about him,
Ahem. As I indicated in my first response to Sean, the first thing I did was to check the tracker for issues listing 'damgerjim' on the nosy list. (Simce people who post messages get auto-added to such and I do not see a message versus issue search page.) I found none and asked Sean for more info. When Sean provided more, I made more particular-to-the-situation responses. I separately posted, in a new thread, a suggestion that we change the tracker to eliminate busywork rather than recruit new people to do it for us. What a way to drive new recruits away. =============== Several people have asked "what danger?". The most delicate part of triage is closing issues that should never have been opened, either because they ask questions that belong on python-list or make foolish bug claims. These come from newbies who could be driven away from Python by less than polite responses from someone with 'official' status. So, again, I think someone should actively exhibit the ability to politely respond to strangers before being given 'official' power to close issues. Terry Jan Reedy
Steve Holden writes:
Yes, in the last year in particular there has been some excellent effort of maintaining the issue tracker content. But the question still remains - who are we worried about offending?
In this thread, we did worry about offending Sean and dangerjim. Now that Sean has commented, I don't think anybody is worrying about offending anybody; there is an understanding that there's a process issue to be resolved. The question is how best to build the community. There are two camps, the quantity camp ("low cost of contribution means more contributors, and that's good"), and the quality camp ("more interaction within the community, especially of experienced developers with newcomers, means more effective contributors and that's good").
I didn't realize we had so much effort available that we can ignore such offers.
Steve, calm down; nobody contributing to the thread is ignoring the offer, and the status quo terms seem to be acceptable to both Sean and dangerjim. They correctly asked for more privilege so that the proposed work can be done more efficiently. Equally correctly, there is a discussion of whether an exception to past practice should be made here, and whether it's worth changing that past practice. I find RDM's argument quite compelling, that the current policy does impose some costs on the newcomer and the mentor, but that on the other hand it does strongly encourage interactions which both build community in the sense of interpersonal relationships and improve the mentoring process for the actual work being done. He concludes that the small costs involved (including the possibility of discouraging some potential contributors) are more than compensated for by the quality of the product. Where do you disagree with that logic?
To make it clear: this is not intended as a criticism of you personally, rather of those who do not seem to feel that increasing the developer community is important. Perhaps diversity is just something you write in a statement.
*By definition*, a community is not diverse in the most fundamental sense. As long as Pythonicity is important to Python, there is danger as well as opportunity in more rapid influx of newcomers.
On Tue, 27 Apr 2010 12:59:26 pm Stephen J. Turnbull wrote:
Steve Holden writes:
Yes, in the last year in particular there has been some excellent effort of maintaining the issue tracker content. But the question still remains - who are we worried about offending?
In this thread, we did worry about offending Sean and dangerjim. Now that Sean has commented, I don't think anybody is worrying about offending anybody; there is an understanding that there's a process issue to be resolved. The question is how best to build the community.
There are two camps, the quantity camp ("low cost of contribution means more contributors, and that's good"), and the quality camp ("more interaction within the community, especially of experienced developers with newcomers, means more effective contributors and that's good").
I'm not sure that is a relevant division between the two camps. I think both sides recognise the need to increase the number of contributors without compromising on their quality. I haven't heard anyone say that we have enough people to do the work that needs doing, or that we should take any warm body who can spell PC. As I see it, the two camps are divided purely on the question of how to get increased privileges. Both sides agree that merit is a requirement, but the disagreement is on how to prove you have such merit. One side insists that the only way to prove merit is to go through a period of untrusted, unprivileged contributions, with no exceptions. One argument for this is that unless we treat everyone identically, some would-be contributors will see the process as nepotism, or otherwise be offended that they didn't get the "special treatment". I believe this misses the point that we *don't* treat people identically, nor can we in a meritocracy. People are treated differently according to not just the quality of their patches, but also the speed at which they submit them, and even more importantly, their ability to gain recognition for their merit. It's not enough to be good at what you do, people have to know it. Ten high-quality patches for high-profile bugs in a week may get you enhanced privileges, while thirty high-quality patches for low-profile bugs in six years might not, simply because nobody notices you. The other side says that a second way of proving merit is through reputation and having a trusted contributor vouch for you, and offer to mentor you. The major difference here is that it's not mandatory to prove your merit to the entire community, but sufficient to prove it to a single trusted member of the community who is willing to stake his own reputation on your ability to perform. Suppose the PSF were to hire somebody specifically to work on patches in the tracker, chances are they would be somebody well-known to the community. But suppose they weren't -- suppose the hirer read dozens of CVs, performed interviews, and determined that the best person for the job was somebody utterly unknown to the community, somebody who had been working quietly away doing brilliant things in Python but with no public profile, and offered her the job of committing patches. Would she get elevated privileges immediately? [...]
*By definition*, a community is not diverse in the most fundamental sense.
I think you're using a definition of community that doesn't appear in any dictionary I'm aware of, nor do I understand what you mean by "most fundamental sense" of diverse. Talking about diversity within a single community is not an oxymoron.
As long as Pythonicity is important to Python, there is danger as well as opportunity in more rapid influx of newcomers.
This at least is true. I can't dispute that. -- Steven D'Aprano
Steven D'Aprano writes:
As I see it, the two camps are divided purely on the question of how to get increased privileges.
As I see it, the division is over what constitutes merit, and how it is created or improved.
Both sides agree that merit is a requirement, but the disagreement is on how to prove you have such merit.
I disagree vehemently with that characterization of my position (and I strongly suspect David would, too). The primary argument of the "quality" camp as I see it is that the familiarization period *creates* value, both in terms of training ("merit" for the job) and interpersonal relationships ("building community"). Thus it is a *net benefit*, not a *net cost*. AFAICS, the "quantity" camp sees it as a nearly pure loss, simply slowing down inflow of preexisting "merit" (and perhaps discouraging it entirely).
*By definition*, a community is not diverse in the most fundamental sense.
I think you're using a definition of community that doesn't appear in any dictionary I'm aware of, nor do I understand what you mean by "most fundamental sense" of diverse. Talking about diversity within a single community is not an oxymoron.
Where did I write "oxymoron"? The grammar was a bit awkward, but my point is simple: the root of the word "community" is *common*. Therefore it makes sense to bring in newcomers via a process which accustoms them to the commonality, of whatever degree, the community is based on.
On Wed, 28 Apr 2010 06:16:48 pm Stephen J. Turnbull wrote:
Steven D'Aprano writes:
As I see it, the two camps are divided purely on the question of how to get increased privileges.
As I see it, the division is over what constitutes merit, and how it is created or improved.
Both sides agree that merit is a requirement, but the disagreement is on how to prove you have such merit.
I disagree vehemently with that characterization of my position (and I strongly suspect David would, too). The primary argument of the "quality" camp as I see it is that the familiarization period *creates* value, both in terms of training ("merit" for the job) and interpersonal relationships ("building community"). Thus it is a *net benefit*, not a *net cost*. AFAICS, the "quantity" camp sees it as a nearly pure loss, simply slowing down inflow of preexisting "merit" (and perhaps discouraging it entirely).
Thank you for clarifying your position. I disagree with it, but at least now I understand it better. -- Steven D'Aprano
On Wed, 28 Apr 2010 17:16:48 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:
Steven D'Aprano writes:
As I see it, the two camps are divided purely on the question of how to get increased privileges.
As I see it, the division is over what constitutes merit, and how it is created or improved.
Both sides agree that merit is a requirement, but the disagreement is on how to prove you have such merit.
I disagree vehemently with that characterization of my position (and I strongly suspect David would, too). The primary argument of the "quality" camp as I see it is that the familiarization period *creates* value, both in terms of training ("merit" for the job) and interpersonal relationships ("building community"). Thus it is a *net benefit*, not a *net cost*. AFAICS, the "quantity" camp sees it as a nearly pure loss, simply slowing down inflow of preexisting "merit" (and perhaps discouraging it entirely).
Except for the "vehemently" part, I think that's an accurate summary of my position. -- R. David Murray www.bitdance.com
Yes, in the last year in particular there has been some excellent effort of maintaining the issue tracker content. But the question still remains - who are we worried about offending?
The people who are potential new contributors but don't currently know anyone in the Python community.
By definition these 'potential new and unknown contributors' are discrete and probably can't be characterized as a whole. However, seeing myself as one of the discrete elements in that group, I think it's worthwhile for me to pipe in here and say that I won't be 'offended' or think of it as nepotism if someone gets foo-privilege before I do because he happens to know core developer (some other 'potential new contributer' lurking here feels otherwise? - speak up!). I don't know the community (yet) and I can't say this for sure, but my current gut feeling about the Python community (and pretty much any OSS I can think of) is that in the long run, I'll be judged on merit just like any other guy, no matter who they know. - Yaniv
On Sun, 02 May 2010 22:39:01 +1000, Yaniv Aknin <yaniv@aknin.name> wrote:
Yes, in the last year in particular there has been some excellent effort of maintaining the issue tracker content. But the question still remains - who are we worried about offending?
The people who are potential new contributors but don't currently know anyone in the Python community.
By definition these 'potential new and unknown contributors' are discrete and probably can't be characterized as a whole. However, seeing myself as one of the discrete elements in that group, I think it's worthwhile for me to pipe in here and say that I won't be 'offended' or think of it as nepotism if someone gets foo-privilege before I do because he happens to know core developer (some other 'potential new contributer' lurking here feels otherwise? - speak up!).
I don't know the community (yet) and I can't say this for sure, but my current gut feeling about the Python community (and pretty much any OSS I can think of) is that in the long run, I'll be judged on merit just like any other guy, no matter who they know.
Thank you very much for this feedback. -- R. David Murray www.bitdance.com
On Wed, Apr 28, 2010 at 10:46:37AM +1000, Steven D'Aprano wrote:
their ability to gain recognition for their merit. It's not enough to be good at what you do, people have to know it. Ten high-quality patches for high-profile bugs in a week may get you enhanced privileges, while thirty high-quality patches for low-profile bugs in six years might not, simply because nobody notices you.
True. This makes me wonder if we should be data-mining the tracker information to look for significant contributors that no one has noticed. --amk
A.M. Kuchling <amk <at> amk.ca> writes:
True. This makes me wonder if we should be data-mining the tracker information to look for significant contributors that no one has noticed.
I'd say that we usually notice them, since we process their patches or read their reviews and comments. Unless perhaps they're called "John Smith" or "Jean Dupont" (if French). Regards Antoine.
A.M. Kuchling writes:
True. This makes me wonder if we should be data-mining the tracker information to look for significant contributors that no one has noticed.
It's an interesting idea. But I've done something similar to this, ad hoc[1], a few times in XEmacs, and it has never worked out. That's not to say it never will, but I found that people with a long-term low-level interest generally have a reason for being that way. Footnotes: [1] In looking through logs, I see a person whose name I recognize from other commits associated with a currently problematic area, and get in touch. They've been happy to give what advice they can on the current issue, but then gracefully decline more regular involvement.
On Mon, 26 Apr 2010 14:15:01 -0400, Steve Holden <steve@holdenweb.com> wrote:
Antoine Pitrou wrote:
Steven D'Aprano <steve <at> pearwood.info> writes:
Who are we worried about offending? The crowds on the Internet who never volunteer for anything, who never submit patches, let alone offer to do the unglamourous work?
Perhaps you should look more carefully. We do have contributors who submit patches and advice on the tracker. There isn't just the committers and the passive masses.
Yes, in the last year in particular there has been some excellent effort of maintaining the issue tracker content. But the question still remains - who are we worried about offending?
The people who are potential new contributors but don't currently know anyone in the Python community.
(oh, and following your logic, we should ignore your advice, unless you actually contribute to the "unglamourous work" - do you?)
In a meritocracy it isn't enough to be good at what you do, you also have to be known to be good.
If this were the criterion then the answer would be simple: nobody seems to knows dangerjim in the Python community.
Except, of course, the person recommending him. And it seems from the discussion that nobody is particularly bothered about finding out about him, preferring to exercise their various prejudices in preference to taking a PSF member's word that he's a potentially valuable contributor along with an offer of supervision.
I didn't realize we had so much effort available that we can ignore such offers.
This discussion has never been about dangerjim's qualifications, as far as I can tell. I believe we all fully expect him to be a valuable contributor within a very short time, because Sean is recommending him, and we welcome him to the community, The discussion, in my view, is about the process in general, and how to make sure that it continues to promote good, inclusive community, by holding everyone to the same standards. (And the discussion, then, is should we change the current standard.)
(to make it clear: this is not a shot intended at him, rather at your own logic)
To make it clear: this is not intended as a criticism of you personally, rather of those who do not seem to feel that increasing the developer community is important. Perhaps diversity is just something you write in a statement.
Some of the comments in this thread have seemed positively unwelcoming, even though I doubt that was the authors' intention.
I have not read any of the comments as unwelcoming (although I could be misremembering), so I'm not sure why you heard that. We are talking about process and what works best for community building (which includes increasing the number of people in the developer community). And I at least am in the mode of *discussing* it, not speaking from a position set in stone...if the consensus that develops is that the familiarization period can be skipped in certain cases, I'm not going to block that consensus or get mad about it...but I don't think we have a developing consensus right now, and I'm not sure how to move forward on that. For the record, note that both Antoine and I have been instrumental in bringing more than one new person into both the triage and the committer ranks. We (along with others) *are* the ones doing the welcoming and the mentoring and the growing of the developer community. -- R. David Murray www.bitdance.com
R. David Murray wrote:
On Mon, 26 Apr 2010 14:15:01 -0400, Steve Holden <steve@holdenweb.com> wrote: [...] For the record, note that both Antoine and I have been instrumental in bringing more than one new person into both the triage and the committer ranks. We (along with others) *are* the ones doing the welcoming and the mentoring and the growing of the developer community.
For which work I am truly grateful, as I am sure are many others. Please forgive any prickliness I may have evinced in this conversation. It *is* important to make people feel welcome, and I am happy to see the development community growing. As regards the procedural discussions, while I may have my opinions it's clearly best if the procedures are maintained by those operating them. I am usually fine with that happening, and this is no exception. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
R. David Murray wrote:
And I at least am in the mode of *discussing* it, not speaking from a position set in stone...if the consensus that develops is that the familiarization period can be skipped in certain cases, I'm not going to block that consensus or get mad about it...but I don't think we have a developing consensus right now, and I'm not sure how to move forward on that.
Having a recommendation officially mean accelerating-but-not-skipping the familiarisation period doesn't seem to have met with any significant objections. We basically do that anyway, this would just mean adding a note about it to the "getting involved" documentation. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Tue, 27 Apr 2010 23:34:48 +1000, Nick Coghlan <ncoghlan@gmail.com> wrote:
R. David Murray wrote:
And I at least am in the mode of *discussing* it, not speaking from a position set in stone...if the consensus that develops is that the familiarization period can be skipped in certain cases, I'm not going to block that consensus or get mad about it...but I don't think we have a developing consensus right now, and I'm not sure how to move forward on that.
Having a recommendation officially mean accelerating-but-not-skipping the familiarisation period doesn't seem to have met with any significant objections.
We basically do that anyway, this would just mean adding a note about it to the "getting involved" documentation.
Sounds good to me. -- R. David Murray www.bitdance.com
On Tue, 27 Apr 2010 03:45:39 am Antoine Pitrou wrote:
Steven D'Aprano <steve <at> pearwood.info> writes:
Who are we worried about offending? The crowds on the Internet who never volunteer for anything, who never submit patches, let alone offer to do the unglamourous work?
Perhaps you should look more carefully. We do have contributors who submit patches and advice on the tracker. There isn't just the committers and the passive masses.
Yes, I know, I'm one of those contributors who have submitted patches. Only a couple, so far, but provided I'm not discouraged by the lack of anyone with the time or motivation to review them, there will probably be more in time. (By the way, if anyone wants to review issues 4037 and 8128, I'd be grateful.)
(oh, and following your logic, we should ignore your advice, unless you actually contribute to the "unglamourous work" - do you?)
That depends on what you call unglamourous work. No, I don't triage bugs. I don't have commit privileges, so I can't. Does hand-holding newbies who don't know the difference between a list and a dict count as unglamourous work? I'm not looking for a medal, I'm just trying to give back whatever little I'm able.
In a meritocracy it isn't enough to be good at what you do, you also have to be known to be good.
If this were the criterion then the answer would be simple: nobody seems to knows dangerjim in the Python community.
Sean is nobody? We trust Sean to check in code. We trust him not to hand his username and password to dangerjim and let him loose. But do we trust his judgement that dangerjim is ready, willing and able to triage bugs? I think we can all take it as a given that commit privileges shouldn't be just given out to anyone. I think we can all agree that one good way to gain that trust is to submit lots of high-quality patches. But what I don't understand is why there is so much resistance to the idea of accepting a personal recommendation from somebody who is trusted with commit privileges, even in principle. The reasons given don't strike me as convincing, especially the idea that it is nepotistic. It's not like commit privileges is a reward that is valuable in and of itself, or that they can't be revoked if dangerjim turns out not to have the chops that Sean said. Dangerjim doesn't know Python, he can't contribute by writing patches, but he could make a valuable contribution by reviewing them. Sean has said he'll mentor him. Meritocracies are reputation-based, and the thing about reputation-based systems is that reputation propagates: I trust Alice because I've seen direct evidence of her merit, and I trust Bob on the basis that Alice vouches for him and I trust her to be a good judge of merit. Such propagation is lossy, of course. I trust Alice more than Bob. The further away from direct evidence of merit, the less confidence I have. -- Steven D'Aprano
Steven D'Aprano <steve <at> pearwood.info> writes:
That depends on what you call unglamourous work. No, I don't triage bugs. I don't have commit privileges, so I can't.
Is this the sole reason? You could try to review patches which are proposed, or give advice where you are competent. As Terry (I believe) said, it's certainly as useful as changing form values and checkboxes :) By the way, it isn't about commit privileges, but tracker rights. I don't think we would consider giving commit rights to someone who hasn't ever participated in the community, and apparently isn't a Python user. Regards Antoine.
On Tue, 27 Apr 2010 05:37:31 am Antoine Pitrou wrote:
Steven D'Aprano <steve <at> pearwood.info> writes:
That depends on what you call unglamourous work. No, I don't triage bugs. I don't have commit privileges, so I can't.
Is this the sole reason? You could try to review patches which are proposed, or give advice where you are competent.
No, of course not. There are always other reasons, the biggest is too many things to do and not enough time to do it. If I did review patches, would they be accepted on the strength on my untrusted reviews? But this isn't about my reasons for not being more active on the bug tracker. This is about how we decided whether or not to give tracker rights to a volunteer. I think that being vouched for by a trusted member of good standing who offers to act as mentor should be sufficient grounds for giving tracker rights to the volunteer. Apparently some disagree. How do we resolve this, since we're obviously not persuading each other. Put it to a vote? Ask the BDFL?
By the way, it isn't about commit privileges, but tracker rights. I don't think we would consider giving commit rights to someone who hasn't ever participated in the community, and apparently isn't a Python user.
Correction noted, thank you. -- Steven D'Aprano
On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano <steve@pearwood.info> wrote:
No, of course not. There are always other reasons, the biggest is too many things to do and not enough time to do it. If I did review patches, would they be accepted on the strength on my untrusted reviews?
It is very very helpful for *anyone* to review patches. Let's see if I can clarify the process a little. (This is, of course, my take on it, others can chime in if they think I got anything wrong.) Someone submits a bug. Someone submits a patch to fix that bug (or add the enhancement). Is that patch ready for commit? No. Is it ready for *commit review* (ie: someone with commit privileges to look at it with an eye toward committing it)? Probably not. What makes a patch ready for commit review? The patch should: 1) conform to pep 7/8 2) have unit tests that fail before the patch and succeed after 3) have documentation updates if needed 4) have a py3k port *if and only if* the port is non-trivial (well, if someone wants to add one when it is trivial that's OK, but it probably won't get used) 5) if it is at all likely to have system dependencies, be tested on at least linux and windows Making sure that these items are true does not require any in-depth expertise. In many cases it doesn't even require much time. 'Trusted' or 'untrusted' doesn't really come in to it, though doing these sorts of reviews will build trust. If you can in addition look at the patch content and critique it, so much the better. Again, *any* critique is useful, even if you can't review the whole patch in detail, because it gets it that much closer to being commit ready. And there are enough uncommitted patches in the tracker that it ought to be possible for almost anyone to find something they can usefully do a content critique on. The goal is to make the commit review step as simple and fast for the committer as possible. The more eyes on the patch before hand, the faster the commit review will be. And those people who do a good job making patches commit ready will be on the fast track to getting commit privileges. -- R. David Murray www.bitdance.com PS: note that I'm using 'commit review' above with a different sense than that value is currently defined to have in the workflow. I'm thinking about advocating that the definition in the workflow be changed, and indeed we (the informal triage crew) have already occasionally used that setting with the meaning I give it above.
On 01:38 pm, rdmurray@bitdance.com wrote:
On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano <steve@pearwood.info> wrote:
No, of course not. There are always other reasons, the biggest is too many things to do and not enough time to do it. If I did review patches, would they be accepted on the strength on my untrusted reviews?
It is very very helpful for *anyone* to review patches. Let's see if I can clarify the process a little. (This is, of course, my take on it, others can chime in if they think I got anything wrong.)
Someone submits a bug. Someone submits a patch to fix that bug (or add the enhancement). Is that patch ready for commit? No. Is it ready for *commit review* (ie: someone with commit privileges to look at it with an eye toward committing it)? Probably not.
What makes a patch ready for commit review? The patch should:
1) conform to pep 7/8 2) have unit tests that fail before the patch and succeed after 3) have documentation updates if needed 4) have a py3k port *if and only if* the port is non-trivial (well, if someone wants to add one when it is trivial that's OK, but it probably won't get used) 5) if it is at all likely to have system dependencies, be tested on at least linux and windows
This list would make a good addition to one of the cpython development pages. If potential contributors could find this information, then they'd be much more likely to participate by doing reviews. Jean-Paul
On Apr 27, 2010, at 02:40 PM, exarkun@twistedmatrix.com wrote:
On 01:38 pm, rdmurray@bitdance.com wrote:
2) have unit tests that fail before the patch and succeed after
This list would make a good addition to one of the cpython development pages. If potential contributors could find this information, then they'd be much more likely to participate by doing reviews.
It would be kind of cool if there were some best practices for running said unittest both with and without the patch enabled. Kind of like using #ifdefs in C but without all the commenting-out-commenting-in error proneness. I guess you could do something like if os.getenv('BUG1234'): # Patch the frobnicator to not bloviate. Maybe more trouble than it's worth, and not always feasible of course, but I'm wondering how (or maybe if) people do things this way. With Bazaar, I often use a loom with two threads - a bottom one that contains the test that fails, and a top one that contains the fix for the test. It's a great way to develop a patch, but you lose that once you flatten the code for review. -Barry
On Tue, 27 Apr 2010 11:16:51 -0400, Barry Warsaw <barry@python.org> wrote:
It would be kind of cool if there were some best practices for running said unittest both with and without the patch enabled. Kind of like using #ifdefs in C but without all the commenting-out-commenting-in error proneness. I guess you could do something like
if os.getenv('BUG1234'): # Patch the frobnicator to not bloviate.
Maybe more trouble than it's worth, and not always feasible of course, but I'm wondering how (or maybe if) people do things this way.
With Bazaar, I often use a loom with two threads - a bottom one that contains the test that fails, and a top one that contains the fix for the test. It's a great way to develop a patch, but you lose that once you flatten the code for review.
Well, the way I do it for review is brute force: I download the patch, delete everything except the unit test, apply that, run it, revert, apply the original patch, run it. For developing, I generally write the unit test first <grin>, but when the fix is confined to one file I can just revert the file for testing the tests while keeping the fixed copy in my edit buffer (or a save file if I'm feeling paranoid, like when it is a substantial fix). For more complex fixes I generate separate patch files for the tests and the fix as a whole, and do a revert-patch-revert-patch dance to test things. I wonder if it would be better to encourage people to post the unit tests and the fix as separate patch files. -- R. David Murray www.bitdance.com
On Apr 27, 2010, at 11:43 AM, R. David Murray wrote:
I wonder if it would be better to encourage people to post the unit tests and the fix as separate patch files.
I think this is not bad idea for larger fixes, where it's not trivial to manually edit the diff. -Barry
On Tue, Apr 27, 2010 at 5:16 PM, Barry Warsaw <barry@python.org> wrote:
On Apr 27, 2010, at 02:40 PM, exarkun@twistedmatrix.com wrote:
On 01:38 pm, rdmurray@bitdance.com wrote:
2) have unit tests that fail before the patch and succeed after
This list would make a good addition to one of the cpython development pages. If potential contributors could find this information, then they'd be much more likely to participate by doing reviews.
It would be kind of cool if there were some best practices for running said unittest both with and without the patch enabled. Kind of like using #ifdefs in C but without all the commenting-out-commenting-in error proneness. I guess you could do something like
if os.getenv('BUG1234'): # Patch the frobnicator to not bloviate.
When I'm writing the patch it's usually easy, I write the tests, see that they fail, write the fix, see that they pass. When I'm reviewing the patch, I apply the patch, see that the tests pass, svn revert the fix, check that they fail. Most of the patches affect just a couple of files, so applying the whole patch and then revert is usually trivial and probably easier than having to deal with two separate files for patch and tests.
Ezio Melotti wrote:
When I'm writing the patch it's usually easy, I write the tests, see that they fail, write the fix, see that they pass. When I'm reviewing the patch, I apply the patch, see that the tests pass, svn revert the fix, check that they fail. Most of the patches affect just a couple of files, so applying the whole patch and then revert is usually trivial and probably easier than having to deal with two separate files for patch and tests.
This would be pretty close to my typical workflow as well (*looks at list of assigned bugs that hasn't moved in weeks* well, it is the workflow when I actually *do* some Python coding...) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Warsaw wrote:
On Apr 27, 2010, at 02:40 PM, exarkun@twistedmatrix.com wrote:
On 01:38 pm, rdmurray@bitdance.com wrote:
2) have unit tests that fail before the patch and succeed after This list would make a good addition to one of the cpython development pages. If potential contributors could find this information, then they'd be much more likely to participate by doing reviews.
It would be kind of cool if there were some best practices for running said unittest both with and without the patch enabled. Kind of like using #ifdefs in C but without all the commenting-out-commenting-in error proneness. I guess you could do something like
if os.getenv('BUG1234'): # Patch the frobnicator to not bloviate.
Maybe more trouble than it's worth, and not always feasible of course, but I'm wondering how (or maybe if) people do things this way.
With Bazaar, I often use a loom with two threads - a bottom one that contains the test that fails, and a top one that contains the fix for the test. It's a great way to develop a patch, but you lose that once you flatten the code for review.
You can always "shelve" the part of the patch which isn't the test: I do that pretty frequently in the Zope tree, where I am now doing most development with bzr. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvXLuMACgkQ+gerLs4ltQ5HBQCgw7kqJ52kPz+0cwNSpyVUkCFA yQUAoLHJiYi+59Cc7BCeL46hA+Wygo66 =93vQ -----END PGP SIGNATURE-----
On Apr 27, 2010, at 02:37 PM, Tres Seaver wrote:
You can always "shelve" the part of the patch which isn't the test: I do that pretty frequently in the Zope tree, where I am now doing most development with bzr.
Yes definitely. bzr-loom just makes that much easier to manage. -Barry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27/04/10 17:16, Barry Warsaw wrote:
It would be kind of cool if there were some best practices for running said unittest both with and without the patch enabled. Kind of like using #ifdefs in C but without all the commenting-out-commenting-in error proneness. I guess you could do something like
Mercurial queues are very useful here. You apply/deapply patches with a single command: <http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html> I am using python SVN mercurial mirror and MQ (Mercurial Queues) for development, waiting for the "real thing" (Mercurial native working). - -- Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBS9dofJlgi5GaxT1NAQIyAQP/avvYJxxlY4lr58nHbjsuoROz1rQi7RrR qd8G3grsS9NXlYbygw0rERJyg9UgjDhJrZbwYEPGJkxTIUd/Vcnw/fIB6J+xuLlY sRnmh0P6ILOFTHYoZZZ/hxtfdMiZxqiMHO3Pfs8uBc5bGC0f23cqiTOFY0+ze7mU 3vUIcljhuRE= =oyQb -----END PGP SIGNATURE-----
On Tue, Apr 27, 2010 at 02:40:19PM -0000, exarkun@twistedmatrix.com wrote:
This list would make a good addition to one of the cpython development pages. If potential contributors could find this information, then they'd be much more likely to participate by doing reviews.
If anyone wants to write the updated text, the following command will make an anonymous read-only checkout of the /dev/ pages: svn ls https://svn.python.org/www/trunk/beta.python.org/build/data/dev I can apply a patch. --amk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 R. David Murray wrote:
On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano <steve@pearwood.info> wrote:
No, of course not. There are always other reasons, the biggest is too many things to do and not enough time to do it. If I did review patches, would they be accepted on the strength on my untrusted reviews?
It is very very helpful for *anyone* to review patches. Let's see if I can clarify the process a little. (This is, of course, my take on it, others can chime in if they think I got anything wrong.)
Someone submits a bug. Someone submits a patch to fix that bug (or add the enhancement). Is that patch ready for commit? No. Is it ready for *commit review* (ie: someone with commit privileges to look at it with an eye toward committing it)? Probably not.
What makes a patch ready for commit review? The patch should:
1) conform to pep 7/8 2) have unit tests that fail before the patch and succeed after 3) have documentation updates if needed 4) have a py3k port *if and only if* the port is non-trivial (well, if someone wants to add one when it is trivial that's OK, but it probably won't get used) 5) if it is at all likely to have system dependencies, be tested on at least linux and windows
This is an excellent set of guidelines. The only drawback I see here is that the current VCS situation makes doing the review more tedious than it should be, especially for non-committers. Or maybe the Hg mirrors are truly up-to-date and working? Last I looked, they were lagging or unavailable.
Making sure that these items are true does not require any in-depth expertise. In many cases it doesn't even require much time. 'Trusted' or 'untrusted' doesn't really come in to it, though doing these sorts of reviews will build trust. If you can in addition look at the patch content and critique it, so much the better. Again, *any* critique is useful, even if you can't review the whole patch in detail, because it gets it that much closer to being commit ready. And there are enough uncommitted patches in the tracker that it ought to be possible for almost anyone to find something they can usefully do a content critique on.
The goal is to make the commit review step as simple and fast for the committer as possible. The more eyes on the patch before hand, the faster the commit review will be. And those people who do a good job making patches commit ready will be on the fast track to getting commit privileges.
-- R. David Murray www.bitdance.com
PS: note that I'm using 'commit review' above with a different sense than that value is currently defined to have in the workflow. I'm thinking about advocating that the definition in the workflow be changed, and indeed we (the informal triage crew) have already occasionally used that setting with the meaning I give it above.
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvXLtkACgkQ+gerLs4ltQ79DACbB35/XFGyiYjd79OtTx+kgoNl mcsAnA4TNlM1ARjyrDrQIwv4KG48w/7h =1hGI -----END PGP SIGNATURE-----
Tres Seaver <tseaver <at> palladion.com> writes:
This is an excellent set of guidelines. The only drawback I see here is that the current VCS situation makes doing the review more tedious than it should be, especially for non-committers. Or maybe the Hg mirrors are truly up-to-date and working? Last I looked, they were lagging or unavailable.
If you only a review a patch (rather than say maintain and evolve it), there's no point in using hg rather than SVN. However, the mirrors are most of the time alive and up-to-date (sync period is around 5 minutes): http://code.python.org/hg (perhaps you're thinking about http://hg.python.org/, which is an experimental conversion of the SVN repo, not really meant for daily use) Regards Antoine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antoine Pitrou wrote:
Tres Seaver <tseaver <at> palladion.com> writes:
This is an excellent set of guidelines. The only drawback I see here is that the current VCS situation makes doing the review more tedious than it should be, especially for non-committers. Or maybe the Hg mirrors are truly up-to-date and working? Last I looked, they were lagging or unavailable.
If you only a review a patch (rather than say maintain and evolve it), there's no point in using hg rather than SVN.
Hmm, it feels exactly the other way around to me: working with the DVCS tools while reviewiing a patch allows me to be more productive (e.g., using 'bzr shelve' or the equivalent hg subcommand). Making a local branch / clone for each issue also feels more natural than working in a read-only SVN checkout.
However, the mirrors are most of the time alive and up-to-date (sync period is around 5 minutes): http://code.python.org/hg
That was the URL I was trying to work with: it has been a couple of months since I last tried, however.
(perhaps you're thinking about http://hg.python.org/, which is an experimental conversion of the SVN repo, not really meant for daily use)
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvXOacACgkQ+gerLs4ltQ6ZTwCfQ96RYQ6h/zdMOnFUJU3MkSC1 +o8An2CqK7fbpiCM3gBWZuRReG46xv+U =iWug -----END PGP SIGNATURE-----
On Tue, Apr 27, 2010 at 03:23:19PM -0400, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Antoine Pitrou wrote:
Tres Seaver <tseaver <at> palladion.com> writes:
This is an excellent set of guidelines. The only drawback I see here is that the current VCS situation makes doing the review more tedious than it should be, especially for non-committers. Or maybe the Hg mirrors are truly up-to-date and working? Last I looked, they were lagging or unavailable.
If you only a review a patch (rather than say maintain and evolve it), there's no point in using hg rather than SVN.
Hmm, it feels exactly the other way around to me: working with the DVCS tools while reviewiing a patch allows me to be more productive (e.g., using 'bzr shelve' or the equivalent hg subcommand).
Making a local branch / clone for each issue also feels more natural than working in a read-only SVN checkout.
+1. I find it to be an excellent way to muck around with patches and make my own changes / diffs / etc. for a review process. (Not that I do any Python reviews, note. But it's a great technique in general.) It's also fantastically simple and esay to interact with patches that are branches on someone's bitbucket or github repo; much better than uploading and downloading patch files while in the middle of a discussion. cheers, --titus -- C. Titus Brown, ctb@msu.edu
Hmm, it feels exactly the other way around to me: working with the DVCS tools while reviewiing a patch allows me to be more productive (e.g., using 'bzr shelve' or the equivalent hg subcommand).
Just try using Subversion for some time again, and you'll see that it is not difficult at all. Start with a clean sandbox, then apply the patch. If you want to go back to the state without patch, revert the sandbox, if you need it again, apply it again. It's really simple. Regards, Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin v. Löwis wrote:
Hmm, it feels exactly the other way around to me: working with the DVCS tools while reviewiing a patch allows me to be more productive (e.g., using 'bzr shelve' or the equivalent hg subcommand).
Just try using Subversion for some time again, and you'll see that it is not difficult at all. Start with a clean sandbox, then apply the patch. If you want to go back to the state without patch, revert the sandbox, if you need it again, apply it again. It's really simple.
I use Subversion daily as a committer on multiple projects. Keeping multiple readon-only checkouts around to evaluate patches is much clunkier than maintaining DVCS branches for the same purpose. As a non-committer, what I would miss most is the ability to make local commits. Features like "shelve", "log -p", etc., are aslo extremely useful when analyzing a patch. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvXVV8ACgkQ+gerLs4ltQ7JqwCfVZPkm8/3XUuuzpm/N+08x2RI KWYAn004cLJS3poYZ/4BvSFOGzMpwNuC =j3lH -----END PGP SIGNATURE-----
On 4/26/2010 3:22 PM, Steven D'Aprano wrote:
That depends on what you call unglamourous work. No, I don't triage bugs. I don't have commit privileges, so I can't.
Tracker 'privileges' (responsibilities, really) are different from commit privileses.
Does hand-holding newbies who don't know the difference between a list and a dict count as unglamourous work?
Whether on python-list or tracker issues (which possibly should not have been opened), yes.
I'm not looking for a medal, I'm just trying to give back whatever little I'm able.
I would not want you to drop hand-holding to do tracker admin.
I don't understand is why there is so much resistance to the idea of accepting a personal recommendation from somebody who is trusted with commit privileges, even in principle.
Python tracker admins represent the core community to the larger Python world. There are two skills needed for such a responsibility. One is the ability to categorize in accord with vague norms. The other is social sensitivity in responding to strangers, especially tracker newbies. These are quite orthogonal to the ability to code or be someone's good buddy. Since one can do hard-to-repair damage, I think minimal evidence of these two needed skills is appropriate.
Dangerjim doesn't know Python, he can't contribute by writing patches, but he could make a valuable contribution by reviewing them.
Which he can do now, without tracker admin privileges. If successful, that would be more helpful than busywork admin. Actually, I can imagine a C coder writing certain C patches, given a decent spec, without really knowing Python. Terry Jan Reedy
On Mon, Apr 26, 2010 at 17:42, R. David Murray <rdmurray@bitdance.com> wrote:
The first is that open source projects tend to be meritocracies. An otherwise unknown person being introduced to the community and immediately given privileges *just* because of the recommendation of another person
Since the recommendation is based on the persons merit, I fail to see the difference.
may feel (especially to the non privileged) like a kind of nepotism. ("It's not what you contribute, it's who you know").
That is only a problem if we break the rules for certain people. But this discussion isn't about breaking the rules, but changing them. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro <regebro <at> gmail.com> writes:
On Mon, Apr 26, 2010 at 17:42, R. David Murray <rdmurray <at> bitdance.com>
wrote:
The first is that open source projects tend to be meritocracies. An otherwise unknown person being introduced to the community and immediately given privileges *just* because of the recommendation of another person
Since the recommendation is based on the persons merit, I fail to see the difference.
In an open source community, "merit" relates to that community. We don't give Linus Torvalds all rights on the project just because we know (or assume ;-)) he is tremendously competent. Regards Antoine.
On Mon, Apr 26, 2010 at 20:30, Antoine Pitrou <solipsis@pitrou.net> wrote:
Lennart Regebro <regebro <at> gmail.com> writes:
On Mon, Apr 26, 2010 at 17:42, R. David Murray <rdmurray <at> bitdance.com>
wrote:
The first is that open source projects tend to be meritocracies. An otherwise unknown person being introduced to the community and immediately given privileges *just* because of the recommendation of another person
Since the recommendation is based on the persons merit, I fail to see the difference.
In an open source community, "merit" relates to that community. We don't give Linus Torvalds all rights on the project just because we know (or assume ;-)) he is tremendously competent.
Well, that's a blow against the merit-based position then. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro writes:
On Mon, Apr 26, 2010 at 20:30, Antoine Pitrou <solipsis@pitrou.net> wrote:
In an open source community, "merit" relates to that community. We don't give Linus Torvalds all rights on the project just because we know (or assume ;-)) he is tremendously competent.
Well, that's a blow against the merit-based position then. :)
Not at all. Merit is determined not by "absolute" competence, but by fitness for the range of tasks to be performed. I don't really understand how someone who is not familiar with Python internals or with the Python community can be expected to have any *immediate* merit beyond "fast learner". Until a newcomer does that learning, what's the hurry in granting privileges? Note that this discussion has brought up a number of fine points about tracker work (cf Terry Reedy's posts) that Sean may not have been aware of. Had tracker privilege been granted without discussion, he still would not know about them! *Nor would I.* The discussion has had educational benefits beyond the newcomer. This is RDM's thesis about "growing the community" in action.
In other words, I think the goal is not just to add new developers to the community, but to continue to build a strong community of developers.
FWIW, from a Python community newbie that has submitted a few patches and commented on the tracker for a few months, I agree with this statement and the way things are now. I was attracted to the Python community, in part, because the development model seemed so mature and well specified. I felt that it was clear from the current documented policies on how I could contribute -- do these things and get these privileges. That simple. Moreover, by having the different stages (do these things to get tracker privileges, do these other things to get commit privileges, etc...) it was more clear how I could set personal milestones for myself to become a contributing member of the community. I find these "stages" useful for the current community to somewhat gauge an unknown person's ability, but also for that unknown person to develop and learn about the community at a reasonable pace. Yes, I know that the issue in question involves not a _completely_ unknown person, but someone who is known by an existing member of the community. However, this is about a community choice and not just one person's choice. Not to mention the fact that most anyone could have already submitted the amount of comments needed to get enhanced tracker privileges in the amount of time that has been spent on this thread :-) -- Meador
On 4/26/2010 7:45 AM, Michael Foord wrote:
So the question remains - for *tracker* privileges, should the recommendation and commitment to mentor from an established commiter be sufficient (and therefore a standard part of our process)?
I think this is a reasonable barrier for entry and should be acceptable. It should be stated as part of our standard procedure however rather than being an exception to our standard procedure.
Asking that one make public comments on a minimum of, say, 5 issues is hardly onerous. Terry Jan Reedy
On Mon, Apr 26, 2010 at 7:05 AM, Michael Foord <fuzzyman@voidspace.org.uk> wrote:
On 26/04/2010 11:58, Stephen J. Turnbull wrote:
[snip...]
I'm not claiming that the current balance is right.
Hmm... the core development team (those who make commits once a month or more frequently) is very small, the number of people doing bug triaging is currently good but also small. We have patches and issues in the tracker that may have responses but will never get properly looked at because no-one on the core team is interested or has the mental bandwidth, we have possibly hundreds of modules in the standard library without a maintainer.
I think it is very much in the interest of Python to evolve our processes in order to encourage more core-developers. Evolving means experimenting *and* being willing to change. It is certainly less *effort* to accept the status quo, but with several more committed and enthusiastic (and good) core developers there is an awful lot (more) we could achieve.
[snip] Just to add fuel to the fire w.r.t this discussion about process-improvements, lowering friction, etc. I'd like to point out (unintentionally tooting my own horn) a discussion I started up on this exact topic last week: http://jessenoller.com/2010/04/22/why-arent-you-contributing-to-python/ http://www.reddit.com/r/Python/comments/burio/why_arent_you_contributing_to_... http://news.ycombinator.com/item?id=1285897 I'm going to avoid summarizing the comments - ignoring my original post, I can honestly say I received an alarming amount of feedback some of which was private, but most of which is sitting there for us to possible consume and act on. jesse
Jesse Noller <jnoller <at> gmail.com> writes:
Just to add fuel to the fire w.r.t this discussion about process-improvements, lowering friction, etc. I'd like to point out (unintentionally tooting my own horn) a discussion I started up on this exact topic last week:
http://jessenoller.com/2010/04/22/why-arent-you-contributing-to-python/
http://www.reddit.com/r/Python/comments/burio/why_arent_you_contributing_to_...
I have read most of the comments there and I haven't seen anyone suggest that privileges should be given earlier or more easily. (on the other hand, a clearer process perhaps wouldn't hurt) Does your private feedback suggest otherwise? Regards Antoine.
On Mon, Apr 26, 2010 at 2:27 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Jesse Noller <jnoller <at> gmail.com> writes:
Just to add fuel to the fire w.r.t this discussion about process-improvements, lowering friction, etc. I'd like to point out (unintentionally tooting my own horn) a discussion I started up on this exact topic last week:
http://jessenoller.com/2010/04/22/why-arent-you-contributing-to-python/
http://www.reddit.com/r/Python/comments/burio/why_arent_you_contributing_to_...
I have read most of the comments there and I haven't seen anyone suggest that privileges should be given earlier or more easily. (on the other hand, a clearer process perhaps wouldn't hurt)
Does your private feedback suggest otherwise?
I brought this up in the context of lowering the barrier to contribution; not as a value statement surrounding whether or not we should give out privileges sooner rather than later - most of the comments echo the sentiment of "it's hard or unapproachable to become part of this project". I personally feel that if a person is willing to do the work, and someone vouches for them and is willing to be their mentor, there's no reason to wave our hands and say no. jesse
Stephen J. Turnbull wrote:
There is one privilege that should be hard to get: Permanent delete. But being able to triage bugs isn't such a privilege. Heck, not even commit access is, because of someone makes something bad, you can back out the checkin.
Sure, but that's still *work*, and it's work for *somebody else*. The person who made the mistake is unlikely to detect it, and needs to be told to fix it, if they even fix it themselves.
As someone who's main contribution these days (other than kibbitzing here) is reviewing checkins that go by on python-checkins, there generally *is* a slight uptick in that workload when someone new is given commit privileges (e.g. reminders to update docs, NEWS, tests, what's new, ACKS, pointing out potential cross-platform or backwards compatibility problems, reminders to check with active maintainers for some modules). It usually doesn't last long, because those people are currently familiar with the basics of the process from submitting patches to the tracker and seeing them applied for a while before commit privileges are granted. Actually having to revert commits and rerun the test suite to make sure everything is back the way it should be can probably be taken as a 1-for-1 loss in patches applied without being too far off the mark (fortunately, that is rather rare under the current system - I expect it would be significantly more common if we were more casual about handing out commit privileges). However, I will also point out that a large chunk of the motivation in moving to a DVCS is to make life easier for *non-committers*. Existing devs get some benefit in being able to use something less clunky than svnmerge to manage the maintenance branches, but that is pretty minor compared to the gain in usability for everyone else.
If the existing tracker crew is happy with Sean's recommendation, and similar recommendations in the future, I'm happy too. But it is a process change, and they should be comfortable with it.
Agreed that it is the existing triage team that really needs to OK this (since they'll likely be the ones cleaning up any mistakes). Getting someone to do things the clunky way for a couple of weeks still seems like a decent way for them to show they understand the basics of our tracker management policies (since merely commenting on issues can't cause a mess the way inadvertent misuse of tracker privileges can). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Mon, Apr 26, 2010 at 12:58, Stephen J. Turnbull <stephen@xemacs.org> wrote:
It is entirely *not* evident to me that it's too hard to get privileges in the Python development community (Python's development process works -- and it works really well by comparison to 99% of the processes out there).
Well, that's true, all to often a project is controlled by a few developers with no intent of sharing access ever.
Sure, but that's still *work*, and it's work for *somebody else*.
Yes, but only when the checkin was wrong. For all other checkins, it's *less* work. Hence, a committer needs to basically fudge up every second checkin to cause more work than he relieves work. :)
As someone who does a lot more managing of shared resources than coding in the projects I'm active in, I disagree about the danger. Enthusiastic newbies can do a lot of minor damage in a short period of time, and cleaning that up is *work*. This danger is almost entirely mitigated by a small amount of mentoring -- which is precisely what the current process requires -- not only of the recomending party, but also of the existing workers.
And I'm saying that the recommending party is enough. If an established developer says "this guy will not fuck things up", then that is enough guarantee that he won't fuck things up.
But it is a process change, and they should be comfortable with it.
Of course. I'm just arguing for that this process change is correct, and that the current balance is wrong, and that a change is comfortable and safe. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro writes:
Sure, but that's still *work*, and it's work for *somebody else*.
Yes, but only when the checkin was wrong. For all other checkins, it's *less* work. Hence, a committer needs to basically fudge up every second checkin to cause more work than he relieves work. :)
Counting checkins is not the appropriate way to measure work here, and there are externalities. In my experience (in other projects, I suspect it applies to Python, too), most patches produced by newcomers scratch very personal itches that almost nobody else cares about. Many of their bugs, however, affect a large number of users. Similarly, but much less seriously, I suspect that issue triage by newcomers will not result in very "Pythonic" decisions. I won't say that setting priority or assignee inappropriately "fucks things up", but they do increase entropy of the project. Terry Reedy disagreed with Sean's judgment about setting priority and assignee, a useful discussion that would *not* have happened with the policy you propose. It might be preferable for that discussion to have happened on the tracker-discuss list, of course, but IMHO it's good for such threads to happen somewhere that tracker workers can see it.
Am 26.04.2010 15:34, schrieb Lennart Regebro:
On Mon, Apr 26, 2010 at 12:58, Stephen J. Turnbull <stephen@xemacs.org> wrote:
It is entirely *not* evident to me that it's too hard to get privileges in the Python development community (Python's development process works -- and it works really well by comparison to 99% of the processes out there).
Well, that's true, all to often a project is controlled by a few developers with no intent of sharing access ever.
Sure, but that's still *work*, and it's work for *somebody else*.
Yes, but only when the checkin was wrong. For all other checkins, it's *less* work. Hence, a committer needs to basically fudge up every second checkin to cause more work than he relieves work. :)
Reviewing the checkins is not work, then? Georg
On Tue, Apr 27, 2010 at 09:18, Georg Brandl <g.brandl@gmx.net> wrote:
Am 26.04.2010 15:34, schrieb Lennart Regebro:
Yes, but only when the checkin was wrong. For all other checkins, it's *less* work. Hence, a committer needs to basically fudge up every second checkin to cause more work than he relieves work. :)
Reviewing the checkins is not work, then?
Well, yes, so OK, not half. But quite a lot of the checkins need to be bad for the amount of work the established commiters need to do per bug fixed to increase when you add a newbie. Yes, maybe the workload in total increases in the beginning, but that's because the newbie is actually fixing bugs, and as Stephen mentions, it's often itches no one else (read the established committers) cares about, because they didn't encounter that particular issue. I have a problem seeing that as a bad thing. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On 4/25/2010 4:31 PM, Sean Reifschneider wrote:
I'm trying to get a good friend of mine to start doing bug triage on Python.
What is *his* interest? How long has he known and used Python?
As part of my trying to mentor him on it, I've found that many of the common things I do in triage, like setting a priority for priorityless bugs, assigning them to people who obviously are the next step, requires enhanced privileges.
And enhanced knowledge of the process (and people, for assigning).
He has no reputation in the Python community, so I'd be up for getting him started on things that require fewer privileges like verifying older patches still apply against newer Pythons, or maybe summarizing priority/assignment changes to the list and having someone (possibly me) make the changes, etc...
To me, this seems the appropriate way to start. Has he registered for the tracker yet? With his real name? How many issues has he commented on? I searched for issues with 'dangerjim' on the nosy list and found none. I think someone should have read at least, say, 10 issues and commented on at least, say, 5, to show real interest and sanity before being elevated.
However, I will step up for him and say that I've known him a decade, and he's very trustworthy. He has been the president (we call that position Maximum Leader) of our Linux Users Group here for 5 years or so.
Thoughts?
I consider particular knowledge and interest to be as important and trustworthness. Terry Jan Reedy
On Sun, Apr 25, 2010 at 08:42:00PM -0400, Terry Reedy wrote:
What is *his* interest? How long has he known and used Python?
Good points have been made on both sides of the issue here. Despite my having a vested interest, I really have no strong feelings one way or another on the initial request. But, the answers to your questions above may make it more clear why I was looking for the enhanced privileges. James (dangerjim) has *NO* knowledge of Python -- he has done primarily C and Java coding. He *DOES* have time on his hands. This is why I proposed to him to do tracker triage. However, as I started walking him through some examples of triage, I realized that regular accounts don't have the privileges to do any of the things I was proposing. For example: Go into the list of task tasks and look at the ones with no priority. Read through the description and any follow-ups and try to figure out what priority to give it. In most cases it will be "normal". However, for some issues it will be clear they should be a higher or lower priority, even to someone who doesn't know Python. Then we went on to issue 5575 and read through it. In reading this one to determine the priority, it was clear that the ball was back in Collin's court, so I showed that I would look to see if Collin was a valid assignee (which he was) and assign it to him, with a comment about why. Go into old bugs that have patches, and see if the patches cleanly apply against the trunk. If they do, do a "make" and "make test". Add a comment with the outcome. Two of the 3 easiest things I came up with for an outsider to help out with, are things that his account couldn't do. But, as I said above, I'm fine with having him push those changes through me and I can make them when he can't. Thanks, Sean -- "It was a sneaky lawyer's trick, and I fell for it. Because... She's much smarter than me." -- _High_Fidelity_ Sean Reifschneider, Member of Technical Staff <jafo@tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
On 26 April 2010 07:12, Sean Reifschneider <jafo@tummy.com> wrote:
Two of the 3 easiest things I came up with for an outsider to help out with, are things that his account couldn't do.
Would in not therefore be reasonable to question whether the *default* privileges be changed to allow "outsiders" to do these things, rather than asking for escalated privileges for one individual? (Or more likely, as well as doing so, as changing the default is likely to be a longer discussion...) Paul.
-On [20100426 10:21], Paul Moore (p.f.moore@gmail.com) wrote:
Would in not therefore be reasonable to question whether the *default* privileges be changed to allow "outsiders" to do these things, rather than asking for escalated privileges for one individual? (Or more likely, as well as doing so, as changing the default is likely to be a longer discussion...)
Be careful. Trackers are often hit by spam bots which change random form field values. I cannot from memory recall whether or not we had this issue on either the tracker tracker or Python's tracker. -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B A wise man that walks in the dark with a blindfold on, is not much of a wise man...
On Mon, Apr 26, 2010 at 5:31 AM, Jeroen Ruigrok van der Werven <asmodai@in-nomine.org> wrote: ..
Be careful. Trackers are often hit by spam bots which change random form field values. I cannot from memory recall whether or not we had this issue on either the tracker tracker or Python's tracker.
I would think a comment area is a more attractive target for spam bots than "random form field values" such as "assignee" or "priority." (Note that assignee values that a default user can set may be limited to themselves and previous assignees. This will reasonably protect this field from abuse and allow better tracking of whose court the ball is in.) Among the form fields, I would think "nosy" list would be targeted the most because it allows effectively turning the tracker into a mail relay, but I don't remember ever seeing it abused. I also I don't remember ever seeing spam in the bugs.python.org comments which suggests that the subscription process weeds bots reasonably well. +1 on giving dangerjim requested privileges and using his experience to review and change the default privileges.
Terry Reedy <tjreedy <at> udel.edu> writes:
On 4/26/2010 11:09 AM, Alexander Belopolsky wrote:
I also I don't remember ever seeing spam in the bugs.python.org comments which suggests that the subscription process weeds bots reasonably well.
And when it fails, spam is deleted just so no one does see it.
Speaking of which, what is the procedure to delete a spam message and remove a spamming user? We have an example here: http://bugs.python.org/user12283 Regards Antoine.
Antoine Pitrou <solipsis <at> pitrou.net> writes:
Speaking of which, what is the procedure to delete a spam message and remove a spamming user?
Well, for some reason I hadn't seen the "remove button" message... As for deleting the user, I suppose an admin can do it. Regards Antoine.
Antoine Pitrou wrote:
Antoine Pitrou <solipsis <at> pitrou.net> writes:
Speaking of which, what is the procedure to delete a spam message and remove a spamming user?
Well, for some reason I hadn't seen the "remove button" message... As for deleting the user, I suppose an admin can do it.
For true spam (off-topic links, porn, advertisements, etc), please don't "remove". Instead, people in the "Coordinator" role also have a "mark as spam" button, which causes SpamBayes training of the message, and also makes the message unreadable for anonymous users (including search engines). People posting spam for SEO thus get truly blocked. A mere remove will just detach the message - the message URL in itself remains accessible. In the specific case (msg104314), "remove" was probably the right thing, since it isn't real spam, but just non-sensical. I don't think the user needs to be banned from the tracker. Regards, Martin
Martin v. Löwis <martin <at> v.loewis.de> writes:
In the specific case (msg104314), "remove" was probably the right thing, since it isn't real spam, but just non-sensical. I don't think the user needs to be banned from the tracker.
The message was a copy of a previous message by someone else, with an additional HTML link in the middle. The target of that link was clearly the kind that would pay to increase its Google rank through whatever means (bogus diploma stuff, IIRC). Regards Antoine.
The message was a copy of a previous message by someone else, with an additional HTML link in the middle. The target of that link was clearly the kind that would pay to increase its Google rank through whatever means (bogus diploma stuff, IIRC).
Ah, I missed that. I've marked it as spam now. Regards, Martin
On Mon, Apr 26, 2010 at 01:19, Paul Moore <p.f.moore@gmail.com> wrote:
On 26 April 2010 07:12, Sean Reifschneider <jafo@tummy.com> wrote:
Two of the 3 easiest things I came up with for an outsider to help out with, are things that his account couldn't do.
Would in not therefore be reasonable to question whether the *default* privileges be changed to allow "outsiders" to do these things, rather than asking for escalated privileges for one individual? (Or more likely, as well as doing so, as changing the default is likely to be a longer discussion...)
No, the permission levels are purposefully where they are. I have personally had back-and-forths with bug submitters over the priority of an issue because they just happened to think it was more important than it really was. It gets really annoying when you start to get constant bug updates because someone chose to change the priority on their own. Besides the fields under discussion are for developers, not the bug submitters. Sean's friend can start off easily by simply commenting on an issue saying "this issue should probably have a normal priority" and someone with Developer privileges can then go in and either set it or disagree. As he does that more and more he will get noticed and recommended for elevated privileges or he can ask for them. -Brett
Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
On 4/26/2010 2:12 AM, Sean Reifschneider wrote:
On Sun, Apr 25, 2010 at 08:42:00PM -0400, Terry Reedy wrote:
What is *his* interest? How long has he known and used Python?
Good points have been made on both sides of the issue here. Despite my having a vested interest, I really have no strong feelings one way or another on the initial request.
Of course, much of the discussion has little to do with the particulars of your request ;-).
But, the answers to your questions above may make it more clear why I was looking for the enhanced privileges.
James (dangerjim) has *NO* knowledge of Python -- he has done primarily C and Java coding. He *DOES* have time on his hands. This is why I proposed to him to do tracker triage.
However, as I started walking him through some examples of triage, I realized that regular accounts don't have the privileges to do any of the things I was proposing. For example:
Go into the list of task tasks and look at the ones with no priority.
No priority effectively means normal priority. I will separately suggest that the latter be made the default so there is no need for anyone to make such busywork changes.
Read through the description and any follow-ups and try to figure out what priority to give it. In most cases it will be "normal".
As said above, the need to do this should be fixed. In the meantime, if people really care about having 'no selection' replaced by 'normal', I could do more. I have not bothered because I regard the two as synonyms and have not bothered. What a boring thing to give to a newcomer.
However, for some issues it will be clear they should be a higher or lower priority, even to someone who doesn't know Python.
After years on the tracker, *I* do not try to make such judgemnts, so I am dubious about the ability of a non-Python newcomer to do so terribly sensibly.
Then we went on to issue 5575 and read through it. In reading this one to determine the priority, it was clear that the ball was back in Collin's court, so I showed that I would look to see if Collin was a valid assignee (which he was) and assign it to him, with a comment about why.
To my understanding, the 'asignee' is the person who will make a decision on the issue, which usually is the maintainer of the component. Who maintains the sqlite, hashlib and ssl modules? I do not know that 'asignee' should change every time the ball moves to another's court. I thought it stayed constant except when the assignee cannot deal with the issue. Is my understanding obsolete?
Go into old bugs that have patches, and see if the patches cleanly apply against the trunk. If they do, do a "make" and "make test". Add a comment with the outcome.
This, and related C patch review activities, which do not require escalated privileges, would be *much* more useful, and probably more interesting to your C coding friend.
Two of the 3 easiest things I came up with for an outsider to help out with, are things that his account couldn't do.
But, as I said, one of those two should be fixed, and I believe auto-assignment is gradually being improved. The most useful things a C coder can do he can do now. Issues are stalled by lack of review, not by blank priority fields. Terry Jan Reedy
Terry Reedy writes:
As said above, the need to do this should be fixed. In the meantime, if people really care about having 'no selection' replaced by 'normal', I could do more. I have not bothered because I regard the two as synonyms and have not bothered.
Technically they're very close to synonymous (I find it hard to imagine that people specify "priority: normal" in searches very often), but it's not synonymous to the reporter in most cases. I've had users tell me that "unselected" looks untidy, so except for assignee, where "not assigned" is very significant information, I either provide a default (which is not hard to do), or require that the user provide values in my tracker (where I've managed to reduce those fields to two, the issue summary line and the component).
What a boring thing to give to a newcomer. [...] Issues are stalled by lack of review, not by blank priority fields.
Sure, some people would be massively turned off by such duty, but others hardly mind it at all. The newcomer can always just say no. I don't think the point was to find a person to be Priority-Setter- for-Life, but rather to familiarize dangerjim with the bug tracker, the issues, and do something at least a little bit useful. Agreed, I doubt that setting priority would increase the amount of review done, since developers will generally disagree with the reporter (and non-dev third parties) about priority anyway. But getting bugs assigned to people so that they would appear in "my bugs" might help a little bit.
On Mon, 26 Apr 2010 14:23:00 -0400, Terry Reedy <tjreedy@udel.edu> wrote:
On 4/26/2010 2:12 AM, Sean Reifschneider wrote:
Then we went on to issue 5575 and read through it. In reading this one to determine the priority, it was clear that the ball was back in Collin's court, so I showed that I would look to see if Collin was a valid assignee (which he was) and assign it to him, with a comment about why.
To my understanding, the 'asignee' is the person who will make a decision on the issue, which usually is the maintainer of the component. Who maintains the sqlite, hashlib and ssl modules? I do not know that 'asignee' should change every time the ball moves to another's court. I thought it stayed constant except when the assignee cannot deal with the issue.
Is my understanding obsolete?
Well, in my recent experience there are two things the assignee gets used for. The first is someone claiming an issue, saying, in effect, I'm going to work this issue until it is closed. The other is to do exactly what Sean did, assign it to the next person whose decision or input is needed in order to move the issue forward. However, as you say, I think the latter is done generally when the issue *can't* move forward without that person's input (or at least not without giving them a significant opportunity to provide input). Usually this is done by the person who previously had the issue assigned to them. My perception is that making someone nosy on an issue is preferred to assigning it to them (allowing them to assign it to themselves if they think that is appropriate), unless the issue is of higher priority or someone actively working on the issue really needs the other person's input in order to move forward. But these are my own rules of thumb, and a discussion of how best to use this field may be appropriate. -- R. David Murray www.bitdance.com
R. David Murray wrote:
Well, in my recent experience there are two things the assignee gets used for. The first is someone claiming an issue, saying, in effect, I'm going to work this issue until it is closed. The other is to do exactly what Sean did, assign it to the next person whose decision or input is needed in order to move the issue forward. However, as you say, I think the latter is done generally when the issue *can't* move forward without that person's input (or at least not without giving them a significant opportunity to provide input). Usually this is done by the person who previously had the issue assigned to them.
My perception is that making someone nosy on an issue is preferred to assigning it to them (allowing them to assign it to themselves if they think that is appropriate), unless the issue is of higher priority or someone actively working on the issue really needs the other person's input in order to move forward. But these are my own rules of thumb, and a discussion of how best to use this field may be appropriate.
That sounds like a fair description of the way I use it as well. The most common case where I will assign a bug directly to someone is if I want a yea or nay from the release manager in deciding whether or not something is acceptable for inclusion in a beta or rc release. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
My perception is that making someone nosy on an issue is preferred to assigning it to them (allowing them to assign it to themselves if they think that is appropriate), unless the issue is of higher priority or someone actively working on the issue really needs the other person's input in order to move forward. But these are my own rules of thumb, and a discussion of how best to use this field may be appropriate.
I personally think issues should not get assigned unless the person it is being assigned to is known to accept such assignments, e.g. by having asked for them to happen. For example, I would prefer not to be assigned any issues, because I'm unlikely to act on them in the six months - unless, as David says, I'm the *only* person who could move the issue forward in that time. Regards, Martin
participants (30)
-
"Martin v. Löwis" -
A.M. Kuchling -
Alexander Belopolsky -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
C. Titus Brown -
exarkun＠twistedmatrix.com -
Ezio Melotti -
Georg Brandl -
Jeroen Ruigrok van der Werven -
Jesse Noller -
Jesus Cea -
Lennart Regebro -
Meador Inge -
Michael Foord -
Nick Coghlan -
Paul Moore -
R. David Murray -
Scott Dial -
Sean Reifschneider -
Senthil Kumaran -
skip＠pobox.com -
Stephen J. Turnbull -
Steve Holden -
Steven D'Aprano -
Terry Reedy -
Tres Seaver -
Yaniv Aknin