orc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Owen O'Malley" <omal...@apache.org>
Subject Re: [DISCUSS] Creating Orc bylaws
Date Mon, 20 Jul 2015 22:32:09 GMT
On Tue, Jul 14, 2015 at 12:05 AM, Lefty Leverenz <leftyleverenz@gmail.com>
wrote:

> Aarrgh, accidental Send.  Continuing, with overlap:
>
> Voting
>
>    - Although it's hedged with 'In general ...', I have qualms about saying
>    a +1 vote indicates willingness to make it happen.  I've already given
> some
>    +1 votes on the Orc project without any intention of lifting a finger to
>    take the action.  [DISCUSS]
>

Your votes are encouraged, Lefty. :) And I certainly appreciate your
efforts reviewing these
bylaws. The intent is to encourage voters to volunteer to work on issues
that are important to them.


>    - Why no vanilla '0' vote, as well as '+0' and '-0'?  [DISCUSS]
>

I just added that.


>    - 'Non binding votes are still useful for those with binding votes to
>    understand the perception of an action in the wider Orc community.' -- I
>    get the meaning, but find the phrasing of 'for those with binding votes'
>    awkward.  Besides, non-binding votes are useful to the whole community.
>    Sometimes they stimulate lively discussions.
>

How about:

All participants in the ORC project are encouraged to show their
agreement for or against a particular action by voting, regardless of
whether their vote is binding. Nonbinding votes are useful for
encouraging discussion and understanding the scope of opinions within
the project.


> Vetoes
>
>    - 'If a veto is not withdrawn, any action that has been vetoed must be
>    reversed in a timely manner.' -- Should that say 'any action that has
>    already been taken'?
>

ok


>
> Actions
>
>    - Why no action for release plans?
>

As I said above, I think we don't need to make the release plans a formal
vote. A discussion should be fine.


>    - Code Change:  'The code can be committed after the first +1.' --
>    Without any wait time?
>

Hive was a pretty special case. Very few projects have a wait period after
the code approval. Many let commits happen and review afterwards.


>    - Product Release:  Why lazy majority instead of lazy consensus?
>     [DISCUSS]
>

Mostly because Apache requires three active +1's for a release.


>
> New PMC Member
>
>    - 'To promote a committer to a PMC member, ...' -- This implies a
>    requirement of becoming a committer before joining the PMC.  None of the
>    current PMC members did that.  ;)  But seriously, do we want that
>    implication?
>

By far the majority of PMC members that are added to projects are first
added as committers. I think it makes the standard flow clearer.


>
> Committer Removal & PMC Member Removal
>
>    - Why allow removals with lazy majority instead of (non-lazy)
>    consensus?  I have serious misgivings about that.  Of course I don't
> expect
>    it will ever be a problem, but if there were a minority faction then its
>    members could be booted out one by one.  That doesn't sound like the
> Apache
>    Way.  [DISCUSS]
>

In a lot of ways, it is completely academic. I've never been on an Apache
project that removed anyone's access. To use the non-lazy form, you'd need
to be very aggressive about dropping people to emeritus. Otherwise, you'd
never get enough votes.


>
> Voting Timeframes
>
>    - 72 hours:  Should we add some flexibility?  Should releases have
>    longer timeframes?  What about long weekends or convention weeks?  I
>    suggest making the timeframe for releases longer and making 72 hours the
>    minimum, with an option of longer timeframes when appropriate.
>

Hmm. I agree that having flexibility is good. I'd rather not make the
minimum vote length even longer. I'd like ORC to be able make quick
releases for a while.


>    - 'Votes relating to code changes are not subject to a strict timetable
>    but should be made as timely as possible.' -- What does that mean?  The
>    Code Change section says patches can be committed after the first +1,
> which
>    implies immediately after.  Doesn't that cut off debate?  If anyone
> wants
>    to give a -1 vote to a patch, they'd better be quick about it.
> [DISCUSS]
>
> Whew!  Sorry about the long list.  (Aren't you glad I omitted the trivial
> items?)
>

If there is contention, we can always roll things back out. I'd rather not
have a mandatory
waiting period, if we can avoid it.

.. Owen

>
> -- Lefty
>
>
>
> On Tue, Jul 14, 2015 at 2:38 AM, Lefty Leverenz <leftyleverenz@gmail.com>
> wrote:
>
> > I have some questions and comments, plus a long list of edits and trivia.
> > I'll put the latter in a separate message tomorrow.
> >
> > Introduction
> >
> >    - '*Be collaborative.* Working together on the open lists to make
> >    decisions helps the project grow.' -- Does 'open lists' mean the
> mailing
> >    lists?  How about 'open mailing lists, JIRA, and review board'?  (or
> 'bug
> >    database' instead of JIRA)
> >
> > Committers
> >
> >    - Please explain active vs. emeritus, for example by adding a sentence
> >    such as 'Emeritus committers are inactive and lose their ability to
> >    commit code or cast binding votes.'
> >    - Are emeritus committers removed from the Apache committers mailing
> >    list?
> >
> > Release Manager
> >
> >    - Why must release managers be committers?  (In Hive that's not
> >    required.)
> >    - 'The RM shall publish a Release Plan on the dev mailing list' --
> >    Note that the Actions section doesn't include release plans, so this
> >    sentence implies that the RM makes all the decisions.
> >
> > Project Management Committee
> >
> >    - Again, explain active vs. emeritus.
> >    - Are emeritus PMC members taken off the private mailing list?
> >
> > Voting
> >
> >    - Although it's hedged with 'In general ...', I have qualms about
> >    saying a +1 vote indicates willingness to make it happen.  I've
> already
> >    given some +1 votes on the Orc project without any intention of
> lifting a
> >    finger to take the action.  [DISCUSS]
> >    - Why no vanilla '0' vote, as well as '+0' and '-0'?  [DISCUSS]
> >    - 'Non binding votes are still useful for those with binding votes to
> >    understand the perception of an action in the wider Orc community.' --
> >
> >
> >
> >
> >
> >
> > -- Lefty
> >
> > On Tue, Jul 14, 2015 at 12:26 AM, Lefty Leverenz <
> leftyleverenz@gmail.com>
> > wrote:
> >
> >> Is the name officially "Orc" instead of "ORC"?
> >>
> >>
> >> -- Lefty
> >>
> >> On Tue, Jul 7, 2015 at 3:11 PM, Sandryhaila, Aliaksei <
> >> aliaksei.sandryhaila@hp.com> wrote:
> >>
> >>> +1
> >>>
> >>> On 07/06/2015 11:25 PM, Owen O'Malley wrote:
> >>> > Although a community of Orcs seems unlikely to have any rules (other
> >>> than
> >>> > the strongest one makes the rules), Apache projects are supposed to
> >>> create
> >>> > a set. I've borrowed heavily from the Hadoop and Hive bylaws, but
> take
> >>> a
> >>> > look to see if they look reasonable.
> >>> >
> >>> > Comments desired.
> >>> >
> >>> > https://github.com/omalley/orc/blob/bylaws/site/develop/bylaws.md
> >>> >
> >>> > .. Owen
> >>> >
> >>>
> >>>
> >>
> >
>

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