[Python-Dev] Becoming a python contributor

[Martin v. Loewis]

Armin Rigo <arigo@tunes.org> writes:

> If I may step in here -- let describe my own position, as I feel it
> might be shared by a number of bystanders. I have submitted a couple
> of bugs and patches, and am getting some sense of what is
> expected. I often run into pending patches and bugs that I'd like to
> help review, some that I even feel I could accept or reject
> (according to your guidelines), but I'm not sure I should be trusted
> CVS access right now.

I would hope the majority of Python contributors is in your
position. It's not necessarily a matter of trust, but perhaps also of
obligation: Many people contribute to a number of projects, as they
use these projects in their (possibly paid) work, or else feel
attracted to these projects - yet they would not consider them core
contributors. Contributing to other projects in this way myself, I
*like* not having to worry about CVS, and committing changes, etc.

> What about adding an SF outcome/resolution status ("reviewed" or
> "proposedly closed" or even "low-hanging fruit" :-) meaning that the
> issue has been reviewed and discussed, according to the guidelines,
> and that the reviewer thinks the item should now be closed (commited
> or rejected) ?

Unfortunately, adding a Status field is not possible on SF. However,
if you add a comment in this respect to the bug report, many people
will see your comment. If you think someone should really act on a
report, don't hesitate to post to python-dev.

> I feel it is a better solution than just assigning the item to an
> arbitrary core developer.

Indeed. Leaving those unassigned would be best. The core developer can
then assign the item, just to avoid duplication of efforts.

> This lets anyone step in as a reviewer, which is a status that
> should be clearly documented: review other people's work and not
> your own, of course, and closely follow the guidelines. (SF might
> get in the way if it disallows third-parties to change an issue's
> outcome or resolution status; reviewers could instead use an inline
> keyword or ask the author to change the status.)

I usually phrase this as a recommendation: "I recommend to approve
this patch", or some such. When rejecting patches, this has the
additional benefit of giving the contributor a chance to revise the
patch, or point out potential misunderstandings, before it gets
closed.

Regards,
Martin