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 >>> >>> >>
