On 03/09/18 05:53, P. Taylor Goetz wrote: > > >> On Sep 3, 2018, at 12:10 AM, Greg Stein <gst...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
