[Python-Dev] Encouraging developers

[Ron Adam]

Neal Norwitz wrote:
> On 3/6/07, Ron Adam <rrr at ronadam.com> wrote:
>> Neal Norwitz wrote:
>>
>> I'm looking forward to a new tracker and hope it manages single 
>> projects...
>> (patches and bugs) better.  It would be great if we could search for 
>> items
>> based on possibly the following conditions.
> 
> The best place to discuss these things are on tracker-discuss.  I
> think everything is pretty much done, we are waiting for someone to
> help write doc (Brett knows more about this).  We are also waiting
> until after 2.5.1 is out before we switch over so there aren't
> unforeseen issues with the release.  Hopefully 2.5.1 will be out in a
> month.

Cool! :-)


>> *Note: Rejections could be done sooner if it obviously a bad idea.
> 
> Agreed.
> 
> Note: I review nearly all traffic on patches through the mailing list.
> If I see someone say this patch should be rejected and I agree, I
> will do it immediately.  I rarely do that because I don't see those
> comments.  Mostly I just close duplicates that happen from time to
> time.
> 
>> In the case of bugs, the tests would probably come first in order to 
>> verify
>> and reproduce the specific bug.
> 
> Yup.  Also write a test case if one doesn't exist.  That will greatly
> speed debugging.  Adding helpful information about what platform the
> problem occurs on can speed things up too.  Writing a NEWS entry would
> also speed things up.
> 
> This may sound kinda stupid, but if enough people help out, it might
> reduce the time it takes to fix a bug from 30 minutes to 15 minutes.
> If I only have 15 minutes to work on a problem, it's the difference
> between it getting fixed or remaining unresolved.

I never consider clarifying statements even a little bit stupid.  Only a 
bit boring if I hear them more than a few times in a short time period. 
But that's definitely not a problem compared with not having them stated at 
all.

For us who aren't (as) familiar with all the issues surround a bug or the 
specific code in question it can take considerably longer.


>> What something like this would do is effectively distribute knowledge
>> as you suggest. For example someone good at writing docs could do a
>> search for all patches that do not have doc's or need docs reviewed
>> and contribute in that way. The same for someone interested in writing
>> and reviewing tests.
> 
> Yes, every little bit helps!

But the tracker needs to be able to actually track the status of individual 
items for this to work.  Currently there's this huge list and you have to 
either wade though it to find out the status of each item, or depend on 
someone bring it to your attention.  (This has been discussed before.)


>> I wonder if a tracker could also have patch requests. Similar to bugs,
>>  except it's more of a todo list. Oh, never mind there is a feature 
>> request group already. Could that possibly be extended to other
>> areas?
> 
> I don't know what you mean, can you clarify?

I suppose I'm thinking of things that are even more general than a feature 
request.  Like possibly a research request.  Or a request for something to 
be done first so that something else can then be done.

Ron