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.
