orc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lefty Leverenz <leftylever...@gmail.com>
Subject Re: [DISCUSS] Creating Orc bylaws
Date Tue, 14 Jul 2015 07:05:18 GMT
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]
   - 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.' -- 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.

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

Actions

   - Why no action for release plans?
   - Code Change:  'The code can be committed after the first +1.' --
   Without any wait time?
   - Product Release:  Why lazy majority instead of lazy consensus?
    [DISCUSS]

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?

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]

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.
   - '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?)

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