incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Should Apache VOTEs be in a first-come, first-serve queue?
Date Mon, 14 Sep 2015 16:50:07 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message