No, you're not the only one. Though my sense is the proposal was intended to stimulate discussion.
-----Original Message----- From: Konstantin Boudnik [mailto:[email protected]] Sent: Monday, September 14, 2015 3:28 PM To: [email protected] Subject: Re: Should Apache VOTEs be in a first-come, first-serve queue? Am I the only one who sees an issue of moral hazard in this proposal? On Mon, Sep 14, 2015 at 12:28PM, Marko Rodriguez wrote: > 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 <[email protected]> > 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 <[email protected]> > > 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 <[email protected]> > >> 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 > >>> <[email protected]> > >>> 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 > >>>> > >>>> > >>> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
