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