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 21:16:15 GMT
Building a community is all about enticing humans to participate. The
magical marketing that you refer to is simply an example of giving in order
to get.

The Apache motto is "community over code". This means that Apache is all
about building community and trusting that the community will build the
code. If you don't have the community, then the code doesn't much matter.

There may be issues with the incubator, the voting systems and such, but it
isn't a bug that humans are involved and need care and feeding to get them
motivated.  That is a feature.

I think that Marvin's question to you was pretty cogent. Would you be
willing to spend an hour or so each on 5 different projects you aren't
involved in before getting to put your own project up for a release? Would
it change your willingness if most of the community behind some of those
projects not only aren't willing to review your project, but they aren't
even willing to review their own project carefully and cast a vote?

Your answers will likely say a lot about the dynamics of getting people to
help each other. It is hard to do and a human touch goes further than
setting hurdles.







On Mon, Sep 14, 2015 at 12:45 PM, Marvin Humphrey <marvin@rectangular.com>
wrote:

> Hi Marko,
>
> Have you ever considered reviewing other podlings' incubating release
> candidates and cast non-binding votes yourself?  If podling contributors
> like
> you would all help each other by performing thorough inspections of each
> others release candidates (and by learning enough to perform those thorough
> inspections), it would make things easier for everyone!
>
> I'm sure that some people reading this list are chortling with contempt at
> my
> naivete.  ("Why not?  Because there's nothing in it for ME, dummy!")  But
> helping out with other people's projects was part of what got me elected
> onto
> the IPMC while Lucy (the main project I contribute to) was still
> incubating.
> So then I was able to cast binding votes -- and our podling was largely
> insulated from the problem that so vexes you now.
>
> Participating in wider Apache activities is also its own reward.  The
> Apache
> Software Foundation is a worthy institution contributing great value to the
> world at large.  Helping out the Incubator, now or later, is both
> personally
> enriching and more meaningful than what a lot of people get to do at their
> software day jobs.
>
> On Mon, Sep 14, 2015 at 9:26 AM, Marko Rodriguez <okrammarko@gmail.com>
> wrote:
>
> > 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.
>
> Groovy got 4 +1 votes and 2 -1 votes.  If you aren't reading these threads
> closely, you should.  The Groovy release vote thread would have been
> extremely
> educational -- contended votes are rare, and thread touched on not just
> legal
> issues but the fundamental reasons behind release policy.
>
> > 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.
>
> I sympathize.  This problem used to be WAY worse than it is now.  And we
> did
> something about it, back in late 2013.
>
>     http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
>
>     2013 Alternate Release Voting Process
>
>     Select podlings pre-cleared by a majority vote of the IPMC MAY
> participate
>     in an alternate release voting process:
>
>     Should a Podling decide it wishes to perform a release, the Podling
> SHALL
>     hold a vote on the Podling's dev list and create a permanently archived
>     Release Manifest as described in the Experimental Release Guide. At
> least
>     three +1 votes from PPMC members are required (see the Apache Voting
>     Process page). If the majority of PPMC votes is positive, then the
> Podling
>     SHALL send a summary of that vote to the Incubator's general list and
>     formally request the Incubator PMC approve such a release. Formal
> approval
>     requires three binding +1 votes and more positive than negative votes.
>     Votes cast by members of the Incubator PMC are always binding. For all
>     releases after the first, votes cast by members of the PPMC are
> binding if
>     a Mentor approves the Release Manifest.
>
> So it's actually possible to get by with a single Mentor vote, if the
> podling
> contributors are willing to do some extra work.  Are you?
>
> Ironically, that provision, which was so difficult to get consensus for,
> has
> only been used once -- because these days we make better use of the limited
> IPMC capacity for freelance (i.e. non-Mentor) votes.
>
> But to drill down to the immediate issue... The specific TinkerPop VOTE
> thread
> you're concerned about is here, right?
>
>     http://s.apache.org/VPv
>
> One thing that's confusing is that it mentions having 4 binding votes
> already.
>
>     Result summary: +1 (4 binding, 2 non-binding), 0 (0), -1 (0)
>
> I recommend supplying "IPMC", "PPMC", and "community" subtotals rather than
> only the ambiguous "binding"/"non-binding".  It looks like the TinkerPop
> dev
> list VOTE produced one Mentor/IPMC vote (Daniel Gruno's).  Writing that the
> release candidate has "1 IPMC vote" communicates that 2 more are needed in
> a
> way that "4 binding" does not.
>
> Regardless, pinging general@incubator asking for IPMC votes usually works
> these days and it will probably work for this specific TinkerPop release
> candidate as well.  I see that you've already gotten one more IPMC vote
> today.
>
> Marvin Humphrey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

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