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