Gang, FIY, we already have some "by-laws" content divided in:
https://zest.apache.org/community/participate.html https://zest.apache.org/community/playing_field.html https://zest.apache.org/community/codebase.html What we don't actually do, and maybe should, is maintain a CHANGES files. I like the idea and would like to start building one for 2.0 -> 2.1 changes. Something that should be easy to read, much easier than SCM history. WDYAT? /Paul Niclas Hedhman a écrit : > A discussion erupted recently on ComDev (Community Development mailing > list, open to all I think) about project specific by-laws. > > It was highlighted that the Board resolution for creating projects > instructs the PMC to create the by-laws for the project. > > The conclusion of that thread was roughly; > 1. Projects are allowed to craft their own by-laws. > > 2. When this text was created, it was not known how easy it is to get > things wrong. > > 3. Over time, many/most projects operated without explicit by-laws. > > 4. Board would assume, if intervening, that the HTTPd project's by-laws > would apply by default. > > 5. It would be better for the project to spell it out on its own > website. > > So, I suggest that we all take a look at the HTTPd's by-laws and bring up > anything we have questions about, disagrees with or perhaps don't > understand. > > However I can't find those right now, unless what people mean are the > "guidelines"... http://httpd.apache.org/dev/guidelines.html > > The immediate thing is Commit-Then-Review vs Review-Then-Commit. Almost no > projects do RTC for 'develop', only for changes in stable branches. > In general RTC slows down progress a bit, and I don't think we need it, > although in reality we are doing it with feature branches.... > > Cheers >
