incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Birdsall <dave.birds...@esgyn.com>
Subject RE: Should Apache VOTEs be in a first-come, first-serve queue?
Date Mon, 14 Sep 2015 22:30:47 GMT
No, you're not the only one. Though my sense is the proposal was intended to
stimulate discussion.

-----Original Message-----
From: Konstantin Boudnik [mailto:cos@apache.org]
Sent: Monday, September 14, 2015 3:28 PM
To: general@incubator.apache.org
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 <okrammarko@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 <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
> >>>>
> >>>>
> >>>
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message