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.

2010/4/25 :

   >> 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

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antoine Pitrou wrote:

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-----

On 26/04/2010 00:18, Steve Holden wrote:

Tres Seaver wrote:

...

Antoine Pitrou wrote:

...

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.

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 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

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/

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

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.

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: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 Tue, 27 Apr 2010 01:42:10 am R. David Murray wrote:

On Mon, 26 Apr 2010 12:45:34 +0100, 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 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

Antoine Pitrou wrote:

Steven D'Aprano 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/

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.

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 17:16:48 +0900, "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).

Except for the "vehemently" part, I think that's an accurate summary of my position. -- R. David Murray www.bitdance.com

On Sun, 02 May 2010 22:39:01 +1000, Yaniv Aknin 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

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.

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.

On Mon, 26 Apr 2010 14:15:01 -0400, Steve Holden wrote:

Antoine Pitrou wrote:

...

Steven D'Aprano 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:

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 03:45:39 am Antoine Pitrou wrote:

Steven D'Aprano 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

On Tue, 27 Apr 2010 05:37:31 am Antoine Pitrou wrote:

Steven D'Aprano 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 01:38 pm, rdmurray@bitdance.com wrote:

On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano 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 Tue, 27 Apr 2010 11:16:51 -0400, 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

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 Tue, Apr 27, 2010 at 5:16 PM, 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.

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.

-----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-----

-----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-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 R. David Murray wrote:

On Tue, 27 Apr 2010 11:15:49 +1000, Steven D'Aprano 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-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antoine Pitrou wrote:

Tres Seaver 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-----

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

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

Lennart Regebro writes:

On Mon, Apr 26, 2010 at 17:42, R. David Murray

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.

Lennart Regebro writes:

On Mon, Apr 26, 2010 at 20:30, Antoine Pitrou 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.

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

Jesse Noller 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_...

http://news.ycombinator.com/item?id=1285897

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.

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 ---------------------------------------------------------------

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.

On Tue, Apr 27, 2010 at 09:18, Georg Brandl 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 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 tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability

-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 イェルーン ラウフロック ヴァン デル ウェルヴェン 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 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.

Antoine Pitrou 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.

Martin v. Löwis 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.

On Mon, Apr 26, 2010 at 01:19, Paul Moore wrote:

On 26 April 2010 07:12, Sean Reifschneider 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

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.

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 ---------------------------------------------------------------