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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4