[Python-Dev] tracker contribution

[Alexander Belopolsky]

Antoine,

You've just saved me from composing essentially the same message.  I
am top-posting because I have very little to add.

Mark,

I actually reviewed the issues that got closed thanks to your "bumping
them up".  That was 30+ issues over the last week or two.   Quite
impressive.  However, I see you "nosy" on about 180 open issues.
This raises a question about signal to noise ratio that Antoine
mentioned.

I would like to join Antoine recommending that you concentrate on
issues that you are competent in.  In addition, I think your breadth
first approach is also valuable, but don't comment of every issue that
you read.  Unless you feel that the issue was simply forgotten (last
message is from OP and no response from assignee or issue is not
assigned), it may be better to move on when you don't have something
meaningful to contribute.

On Sun, Jul 18, 2010 at 10:34 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
..
> On Sun, 18 Jul 2010 00:45:09 +0100
> Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
..
>> Some people have complained at me about my approach.  Others have said
>> great job.  Obviously there's no correct or incorrect way, there's nowt
>> as queer as folk.
>
> Well, I would still encourage you to adopt a different approach.
> Simply bumping up bugs without adding any useful content to the
> discussion does not help much. Especially if you do so several times in
> a day, because it increases a lot the bandwidth of messages we have to
> deal to. And, given we have a limited amount of time and cognitive
> capacity to devote to Python (we're all volunteers), that means we
> either spend a lot of time reading your messages and context switching
> between several issues per day, or start filtering out your messages in
> order to stay focussed. And if we start doing the latter, it means you
> are just wasting your own time.
>
> It would be IMHO much more useful if you concentrated on a
> couple of issues which interest you, or which you feel competent in,
> and where you either:
>
> - produce a review of a posted patch
> - post a patch yourself
> - give suggestions as to how the issue could be solved (or,
>  alternatively, explain why it is detrimental, or useless, or too late
>  (etc.) to solve the issue)
> - ask questions to the original submitter if things seem fuzzy
>
> It is especially useful if you manage to produce a negative review,
> that is point out something wrong with the patch/issue. Things that can
> get wrong with a patch (non-exhaustive list follows):
>
> - the patch doesn't apply cleanly anymore (on the py3k or 2.7 SVN
>  branch, depending on whether the issue regards 3.x or only 2.x)
> - the proposed solution breaks compatibility in an obvious or subtle way
> - the patch lacks unit tests
> - unit tests don't adequately test behaviour (too strict, too laxist,
>  too fragile, etc.)
> - portability problems, i.e. patch wouldn't have guaranteed or proper
>  behaviour on all platforms
> - inconsistent or improper coding style
> - performance problems on arguably performance-critical code
> - undesireable side effects
> - etc.
>
> I would stress that this kind of involvment would also be able to get
> you much higher on the learning curve than your current involvment does:
> i.e., non-trivial contributions will build the competences to improve
> both yourself (assuming that's something you're interested in) and the
> complexity, correctness and completeness of your future contributions.
> Which in the middle-term is generally quite gratifying.
>
> Regards
>
> Antoine.