Voting and comments

["David W. Van Couvering" <Da...@Sun.COM>]

I do want to express one frustration with the voting process.  It seems 
that although I get some feedback, I can't seem to get all the comments 
I need on a proposal until *after* I call for a vote.  I had this 
proposal online for over two weeks, and it wasn't until after I called 
for a vote that I started getting some meaty comments from everyone.

So that means I have to adjust the proposal and the vote basically has 
to be rejected.    I really dislike this, I don't like having to have 
vote after vote as I try to refine the proposal.

Does anyone have any ideas how a vote submitter can get the feedback 
they need *prior* to calling for a vote?  I really would prefer a vote 
to be a "stamp of approval" on a discussion that has already been worked 
through.

Maybe we can have something like "PRE-VOTE" where people know that this 
is coming in for a vote and they should get their comments in *prior* to 
the call for vote?

Thanks,

David

Re: Voting and comments

["David W. Van Couvering" <Da...@Sun.COM>]

Hi, Kathey.  Sorry if I missed your comments on user impact.  I thought 
I fixed the wording to make it a very strong statement in terms of 
impact and compatibility.  Take a look at the diffs and let me know if 
it's still not a strong enough statement.

Regarding providing a summary, I should have responded to your email, 
but I was concerned about that because I am convinced people will want 
to know exactly what they're voting on, versus voting on it in a 
"general" sense.  I was hoping to hear what others thought but nobody 
else piped in.

Anyway, I posted the request for vote, we'll see how it goes.  If it 
continues to get edited and changed I may go for your recommendation :)

David

Kathey Marsden wrote:
> David W. Van Couvering wrote:
> 
> 
>>I do want to express one frustration with the voting process.  It
>>seems that although I get some feedback, I can't seem to get all the
>>comments I need on a proposal until *after* I call for a vote.  I had
>>this proposal online for over two weeks, and it wasn't until after I
>>called for a vote that I started getting some meaty comments from
>>everyone.
>>
> 
> As for documentation of user impact I did ask for that quite a while ago
> and was waiting #:)  I am still troubled by some of the wording as I
> stated this morning.
> 
> 
>>So that means I have to adjust the proposal and the vote basically has
>>to be rejected.    I really dislike this, I don't like having to have
>>vote after vote as I try to refine the proposal.
>>
>>Does anyone have any ideas how a vote submitter can get the feedback
>>they need *prior* to calling for a vote?  I really would prefer a vote
>>to be a "stamp of approval" on a discussion that has already been
>>worked through.
>>
> 
> I was curious your input on  my suggestion to have a more generalized 
> and clear summary, so that the user impact  is clear, more people can be
> involved and .the implementation details can evolve.
> 
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200510.mbox/browser
> 
> Because your document has a lot of implementation details I am guessing
> it will have to continue to change a lot over time. For instance  if I
> wanted to  add a  parameter to a message I don't know how that would
> work, I guess I would have to version the messages somehow, but I bet
> there are a lot of bridges like that we will have to cross when we come
> to them and I wouldn't want to have to revote on the document if the
> basic guidelines were still met.
> 
> 
> Kathey
> 
> 
> 
> 

Re: Voting and comments

[Kathey Marsden <km...@sbcglobal.net>]

David W. Van Couvering wrote:

> I do want to express one frustration with the voting process.  It
> seems that although I get some feedback, I can't seem to get all the
> comments I need on a proposal until *after* I call for a vote.  I had
> this proposal online for over two weeks, and it wasn't until after I
> called for a vote that I started getting some meaty comments from
> everyone.
>
As for documentation of user impact I did ask for that quite a while ago
and was waiting #:)  I am still troubled by some of the wording as I
stated this morning.

> So that means I have to adjust the proposal and the vote basically has
> to be rejected.    I really dislike this, I don't like having to have
> vote after vote as I try to refine the proposal.
>
> Does anyone have any ideas how a vote submitter can get the feedback
> they need *prior* to calling for a vote?  I really would prefer a vote
> to be a "stamp of approval" on a discussion that has already been
> worked through.
>
I was curious your input on  my suggestion to have a more generalized 
and clear summary, so that the user impact  is clear, more people can be
involved and .the implementation details can evolve.

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200510.mbox/browser

Because your document has a lot of implementation details I am guessing
it will have to continue to change a lot over time. For instance  if I
wanted to  add a  parameter to a message I don't know how that would
work, I guess I would have to version the messages somehow, but I bet
there are a lot of bridges like that we will have to cross when we come
to them and I wouldn't want to have to revote on the document if the
basic guidelines were still met.


Kathey

Re: Voting and comments

[Andrew McIntyre <mc...@gmail.com>]

On Oct 21, 2005, at 9:18 PM, Daniel John Debrunner wrote:

> David W. Van Couvering wrote:
>
>> Does anyone have any ideas how a vote submitter can get the feedback
>> they need *prior* to calling for a vote?  I really would prefer a  
>> vote
>> to be a "stamp of approval" on a discussion that has already been  
>> worked
>> through.
>
> I think you have to change your expectations and approach to fit the
> model of open source and the behaviour of the community.
>
> I'm personally going back a lot more to the basic "scratch your own
> itch" as the starting point and fundamental approach.
>
> <snip lots of good examples>
> 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.
>
> 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.

+1!

To paraphrase a recent movie catch phrase: "Show me the code!"

It's a lot easier to talk about something concrete than something  
abstract and vague. And, as long as anyone contributes something real  
that has definite value to the project, who is going to turn it down?  
You'd have to be crazy! :-)

I admit this is a very different approach than the usual closed  
source way of spec-it-out and then implement the spec approach. It's  
more like implement-your-proposal and let the community comment.

This is why I voted -0 to the recent Junit vote. It's great that  
members of the community are interested in developing Junit tests for  
Derby. But it doesn't mean much to say that we require Junit for  
testing when there are no Junit tests for other contributors to run,  
validate, and enhance.

Speaking of which: Rick - I promise I'll get around to reviewing your  
contribution of new Junit compatibility tests w/r/t DERBY-516 as soon  
as I can (early next week?). I guess it's also important to  
understand that everyone has a limited amount of time and that  
individuals get things done according to how strong their itch for  
that particular subject happens to be.

andrew

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.
> 

Re: Voting and comments

[Daniel John Debrunner <dj...@debrunners.com>]

David W. Van Couvering wrote:
> I do want to express one frustration with the voting process.  It seems
> that although I get some feedback, I can't seem to get all the comments
> I need on a proposal until *after* I call for a vote.  I had this
> proposal online for over two weeks, and it wasn't until after I called
> for a vote that I started getting some meaty comments from everyone.
> 
> So that means I have to adjust the proposal and the vote basically has
> to be rejected.    I really dislike this, I don't like having to have
> vote after vote as I try to refine the proposal.
> 
> Does anyone have any ideas how a vote submitter can get the feedback
> they need *prior* to calling for a vote?  I really would prefer a vote
> to be a "stamp of approval" on a discussion that has already been worked
> through.

This is more vague advice than anything concrete ...

I think you have to change your expectations and approach to fit the
model of open source and the behaviour of the community.

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.