incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marko Rodriguez <okramma...@gmail.com>
Subject Re: Should Apache VOTEs be in a first-come, first-serve queue?
Date Mon, 14 Sep 2015 18:18:26 GMT
Hello,

I suppose my concern is exactly what the two replies thus far espouse -- "human whim."

This means that a "song and dance" must be done to "entice" the human to entertain a VOTE.
I suspect The Apache Software Foundation would argue that paying people to VOTE (regardless
if they +1 or -1) is bad. Or is it? However, there seems little difference between paying
someone to vote and doing some other marketing behaviors that would lure the human voter in.

My concern is that this means its a popularity contest and not a "lets develop software that
is respective of the Apache2 license." Shouldn't Apache's VOTE infrastructure be beyond fancying
the human with magical marketing tricks?

Thank you for your thoughts,
Marko.

http://markorodriguez.com

On Sep 14, 2015, at 11:49 AM, John D. Ament <johndament@apache.org> wrote:

> I know one thing that always grabs my attention is when the community
> behind it votes on the topic, regardless of having binding/non-binding
> votes to back it.  It shows me that there is a lot of interest in it, and
> will remind me to look at it closely and throw my vote in.
> 
> Another way to compare it is is against US Voter turn out.  Typically in
> non-presidential elections its down at 40%, but in presidential its up
> around 60%.
> 
> John
> 
> On Mon, Sep 14, 2015 at 12:50 PM Ted Dunning <ted.dunning@gmail.com> wrote:
> 
>> Marko,
>> 
>> Isn't the real problem a project level problem?  Some projects are simply
>> higher profile than others?
>> 
>> As such, wouldn't be better to raise the profile of the projects not
>> getting the votes rather than impair the ability to vote on popular
>> projects?
>> 
>> Votes on project admission haven't generally been a problem.  The problem
>> is generally with release votes.  Doing a good review of a release takes a
>> significant amount of time and I think that it is hard to impose that
>> burden on everybody who wants to vote on a different project's release.
>> 
>> In the projects that I have mentored, I have seen the problem with getting
>> IPMC votes on releases. My own response has been to
>> 
>> 1) make darn sure that the mentors will vote if they possibly can
>> 
>> 2) reach out to others privately to encourage them on a one-to-one basis to
>> review the release and vote
>> 
>> 3) warn the general list that a vote is coming and talk it up
>> 
>> Most projects should have three mentors who are, by definition, IPMC
>> members with the ability to case binding votes. If a project finds that
>> some mentors are persistently MIA, they should find some new ones. If
>> mentors find that other mentors are MIA, then they should describe to the
>> project why that is a problem and suggest ways to get additional mentors
>> involved.
>> 
>> Ultimately, this problem is just a preview of what happens when a project
>> doesn't have enough active participation and needs to be handled using
>> essentially the same community development methods.
>> 
>> 
>> On Mon, Sep 14, 2015 at 9:26 AM, Marko Rodriguez <okrammarko@gmail.com>
>> wrote:
>> 
>>> 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
>>> 
>>> 
>> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message