Scratching your itch [Was Voting and comments]

["Jean T. Anderson" <jt...@bristowhill.com>]

I'd like to chime in (late) on this thread.

I agree with everything Dan wrote below about scratching your itch. 
Besides, motivation produces the best work.

However, I'd also like to suggest that sometimes scratching each other's 
itch just because it's good for the project has much merit to be said 
for it. Apache has built healthy communities in large part due to the 
individuals who volunteer to step up to the plate and take on onerous 
tasks for the greater good even though they'd much rather be working on 
a challenge that is technically stimulating.

Of course, it's purely up to the individual to decide whether he or she 
has cycles and wants to scratch (or help scratch) somebody else's itch.

  -jean


-------- Original Message --------
Subject: Re: Voting and comments
Date: Fri, 21 Oct 2005 21:18:09 -0700
From: Daniel John Debrunner <dj...@debrunners.com>
Reply-To: derby-dev@db.apache.org
To: derby-dev@db.apache.org
References: <43...@sun.com>

<snip>
> ... 
> I'm personally going back a lot more to the basic "scratch your own
> itch" as the starting point and fundamental approach. If someone does
> something that:
> 
>  - scratches their own itch
>  - and adds value to Derby
>  - and is in line with the charter
>  - and is in line with any previous votes
> 
> then it's really likely to be accepted. How could anyone possibly veto
> something that did provide all of the above? If someone says they could
> do better, then that's fine, but until their code exists, the first
> submission is it. Remember adding some, possibly imperfect, value is
> better than adding "perfect" value, and that you can't require a
> contributor to do anything more than they want to.
> 
> Take a different example, Mamta's optimizer hints. Let's play out a
> possible scenario, based upon some existing emails:
> 
>   1) Mamta submits code in-line with her functional spec, it adds value
> to Derby, in-line with everything, so it looks good, and people either
> vote +1 or it's lazy consensus.
> 
>   2) The Rick comes along and says no good, -1, there is no syntax
> checking of the optimizer overrides.
> 
>   3) I, or others, would then respond, well that's a great idea Rick,
> but that's your itch, Mamta's patch adds value, so let's commit it. If
> you want to add syntax checking, go ahead, but having some form of
> overrides now, is better than some better version in the future, that
> may not even occur, because maybe Rick doesn't care enough to actually
> work on it. We can't judge future code, only code that is actually
> submitted.
> 
> To go back to the shared code, maybe an detailed proposal is the wrong
> approach, a possible alternative is:
> 
> 1) Set up a vote for the top-level principles, e.g.
>     Derby should support shared/common code between jars
>     Sharing code will not degrade the current ease of use
>     ...
> 
>     and I mean sentences just like those, simple clear, and just a
> handful (1-5).
> 
> If you make these simple, clear and obvious then most likely it's a
> no-brainer to vote +1, or you can have the confidence to use lazy consensus.
> 
> 2) Contribute a patch/set of code that is in line with the principle,
> has the detailed explanation, framework and intial shared code, and
> provides value to Derby.
> 
> Should be accepted because it adds value.
> 
> 3) Build upon 2) to add more shared code. Others will be encouraged to
> follow your example and going against your code will be seen as against
> the grain and so require more explanation.
> 
> 4) If someone provides a better framework/approach that's fine, we can
> switch to theirs, but it has to exist and fall into the principles you
> set up.
> 
> In a way it's politics, you want to setup and position votes and
> contributions so that the only possible answer is, '+1 yes, that's a
> great addition to Derby!'. :-)
> 
> We all learning here, coming mainly from closed source development. I
> think we do have to go through some painful exercises/mistakes as a
> learning process.
> 
> Dan.
>