Hello,
It appears that VOTEing in general@ is inefficient and biased. An Apache member
will see a VOTE on the list and can choose whether to participate in that VOTE
or not. I believe there are problems with this algorithm. The first has to do
with efficiency. For instance, Groovy received (out of my foggy memory) some
20+ VOTEs when only 3 were were needed and other project VOTEs were sitting
around hoping for an Apache member to spend time on their project. Second, if
no Apache member really cares about the project's VOTE, then the project
committee is left "hoping" that someone will care --- pinging around to their
mentors (no reply), to the list ("please")… like beggars in the street.
Should general@ have a VOTE queue where if an Apache member has time to VOTE
they can only VOTE on a project at the top of the queue. They can not pick
which projects to VOTE on. This solves the two aforementioned problems:
1. Apache member attention is not wasted on low-entropy states (why are
20 +1 VOTEs needed -- no new information is contributed).
- increased efficiency
2. Apache member attention is not biased by human whim (why are VOTE
requests left idle while later VOTE requests are satiated).
- remove human bias
With a VOTE queue, each project's VOTE requirements are met in the order in
which the VOTE was added to the queue and no project is left pinging mentors
and the list saying -- "can someone please VOTE on our artifacts?"
Thoughts?,
Marko.
http://markorodriguez.com
