On 25 Apr, 11:18 pm, st...@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
_______________________________________________
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/archive%40mail-archive.com
