On Tue, Jul 14, 2015 at 12:05 AM, Lefty Leverenz <[email protected]> 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 <[email protected]> > 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 < > [email protected]> > > wrote: > > > >> Is the name officially "Orc" instead of "ORC"? > >> > >> > >> -- Lefty > >> > >> On Tue, Jul 7, 2015 at 3:11 PM, Sandryhaila, Aliaksei < > >> [email protected]> 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 > >>> > > >>> > >>> > >> > > >
