incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Graduation Resolutions Should Not Include Project Bylaws Clause
Date Mon, 03 Sep 2018 08:10:12 GMT
On 03/09/18 05:53, P. Taylor Goetz wrote:
> 
> 
>> On Sep 3, 2018, at 12:10 AM, Greg Stein <gstein@gmail.com> wrote:
>>
>> Personally, I'd prefer that the concept of project bylaws disappear. Move
>> to "community guides". A *guide* rather than a *ruleset*. The Board has
>> kinda gone quiet on the discussion, but hopefully it will pick it back up,
>> to provide some guidance here.
> 
> ++1
> 
> All projects need is sane (in ASF terms) developer guidelines.

Exactly.

Repeating some points I made on board@

There is a lot of good content in project bylaws.

Some project bylaws duplicate content that exists at the foundation
level. I think that sort of duplication is unhelpful as, over
time, the duplicates tend to diverge.

I would prefer to see the project level content as community guidelines.
Codifying them as bylaws makes them harder to change and reduces
flexibility.

For example, some project level bylaws appear require a 72 hour voting
period for a release. That might not be in the best interest of the
project if a security release needs to be made in a hurry. I have seen
release votes that have lasted just a few hours when a security fix
needed to be made quickly.

A further issue is that if a security release is made with a voting
period of less than 72 hours is that still an act of the foundation if
it violates the project's bylaws? I don't know the answer to that
question and I don't think it is a good use of anyone's time figuring it
out.

Similarly, I can think a several situations where I've used CTR on an
RTC branch because - in my judgement - doing so was in the best
interests of the project. (And as it happens none of the committers at
the time disagreed.)

It is my view that codifying a PMC's standard way of operating in bylaws
can limit the PMC's options when dealing with non-standard situations. I
think it is better for the PMC to retain the flexibility to use if they
need to.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message