[Python-Dev] Becoming a python contributor

[Gustavo Niemeyer]

> It is clearly unsatisfying for submitters of both patches and bug
> reports if they don't hear anything. While some of these issues are

Indeed.

> tricky and require expertise not everybody might have, I'd still like
> to see more people getting involved with that.

I see..

> For reviewing of patches, I'd suggest the following guidelines:
[...]
> - If you complete evaluation, propose rejection or acceptance. From
>   time to time, post a list of patches that you think we should act
>   upon. If I find your analysis convincing, I'll execute the proposed
>   action quickly.
[...]
> For bug reports, a similar procedure applies. Check:
[...]

Thank you very much for your detailed descriptions. It will be a great
reference for myself and for others which feel in the same situation.
I'll try to understand the whole process and follow your instructions.

> > Also, isn't it easy to point out what's wrong in a commit from
> > someone who is following the development process for a while than
> > taking the time to review its code in the sourceforge patch system?
> 
> I'm not sure what you are proposing here? That all patches are just
> applied, and then backed-out if incorrect?
[...]

Not at all. I meant that people who prove to understand the basic
development strategy, and also provided correct working and non-breaking
patches, could get commit access more easily.

I've read somewhere once something which I took for the projects
I currently maintain. To decide if you should give someone commit
access, it's not important if that person can produce pages of
complex code, but if that person usually provide patches which
follow the general strategy, and don't break anything.

> While this may be appropriate sometimes, I think it would cause to
> many disturbances. It happens from time to time that people reading
> python-checkins find problems by inspection. More often, they find
> problems some time afterwards, because of unexpected side effects.
> This is a good thing, and it is possible only because the patches had
> been reviewed carefully on SF.

I'm not suggesting by any means that the current system should be
dropped, as stated above. OTOH, perhaps if we can improve the reviewing
process somehow, even that wouldn't be important anymore.

> > My feeling is that the Python development is currently overly
> > centralized, and that you might be suffering from that now, by being
> > unable to handover some of your tasks to someone else.
> 
> I agree with your first observation, but disagree with the second:
> there are plenty of tasks that could be handed over. There are just no
> volunteers to perform these tasks.

Here! Here! :-)

Sometimes there's just no obvious open door for people to get in.

> > I feel that everytime I send a patch, besides being contributing,
> > I'm also overloading you with more stuff to review and comment and
> > etc. Perhaps the fallback costs for some wrong commit is too high
> > now (did I heard someone mentioning subversion?)?!
> 
> It's not that. Patches *must* be reviewed, or else they would be just
> incomplete: people might commit the patch, but fail to commit the
> documentation. Then, for a couple of years, there would be no
> documentation. Likewise for test cases. That the patch works is alone
> not good enough.

That's a failure in the process, which can easily be reviewed in a
post-commit fashion. If somebody fail to provide tests/documentation,
drop them a line asking for it before anything else. If they still
don't want to provide it, cut them out.

> It is time-consuming to produce high-quality software. However, that
> should not alone be a reason to give up the high standards of Python
> development.

Fully agreed. And I don't want to contribute to reduce the standards
in any way.

Thank you very much!

-- 
Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5  60E2 2253 B29A 6664 3A0C ]