Ceki Gülcü wrote:
>Does this mean that equals rights for women should be abolished because there are
>just too few men to promote it?
In a volunteer meritocracy, equal rights would not exist if someone did
not implement it. Under the Apache model, they would announce they are
working on some equal rights code, and people might respond to that with
voting symbols. But that would not be a vote. (We really only vote on
actual code or documentation, not hypotheticals.) When someone committed
an equal rights patch to the CVS, it would be a product change subject
to lazy consensus. If another committer tossed a (-1) at that, then we
would have a consensus vote on whether equal rights stay or go.
Once implemented, abolishing equal rights would be another product
change. If someone removed it, someone else would need to post a (-1)
before we'd have another consensus vote.
The reason we work together is peer review of our work. Some committers
like the shades of meaning that (-0) and (+0) represent. If someone sees
a bunch of (-0)'s, they might take the hint and refactor their approach.
It helps to keep us all on the same page. We could change the
guidelines, but I doubt that would change how people cast their votes.
The muddy waters would then ~continue~ to be the difference between all
these (-0) and (+0) votes.
> It seems to me that we (Apache) have a tradition of mixing a call for volunteers
>with a decision making (voting) process. A call for volunteers for a release can be
>made with a [POLL] and a decision to make a release can be made with a [VOTE].
People sometimes take polls before making a major decision that will
significantly affect everyone. For example, whether to support 1.1 or
move onto 1.2. In the end, a decision regarding a product change,
showstopper, release plan issue, or public release is made by tallying
the (+1)s and the (-1)s. Anything (0) just doesn't count.
If there are tasks which a committer thinks is worthwhile, but cannot
work on personally in the immediate future, a good approach is to start
a TODO list as part of the documentation package. This tells people we
have already thought of that, and just need people to work on it. This
can also be a good way to manage the final TODOs in a Release Plan.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
