HI,
Here is an idea:
Can we offer $20 to the first 3 binding voters of a release on general@? We
would structure the contract as such:
"The first 3 binding voters on Apache TinkerPop x.y.z get $20
regardless of their vote being a -1 or +1. However, the binding voter must give
an honest review of the artifacts and specify exactly what they did which led
them to their ultimate vote decision. Any dishonesty in voting disqualifies the
individual from receiving their cash prize."
This seems a reasonable (and fair way) of getting VOTE attention much like the
other marketing models currently being posited by the general@ list.
Thoughts?,
Marko.
http://markorodriguez.com
On Sep 14, 2015, at 12:18 PM, Marko Rodriguez <okramma...@gmail.com> wrote:
> 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 <johndam...@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.dunn...@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 <okramma...@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
>>>>
>>>>
>>>
>
