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 <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 > >>>> > >>>> > >>> > > >
--------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
