The pages you reference; Participate & Codebase -> Doesn't follow what ASF expects, where everyone are peers.
Playing Field - talks about "reverts", where in ASF there is a concept of "Veto a change", which would lead to discussion and resolution. Whether that is a revert, amendment or something else is not really defined. We used to have a release notes, which was generated from Jira issues solved in the release. Are you talking about something else? // Niclas On Thu, Jul 9, 2015 at 1:19 PM, Paul Merlin <[email protected]> wrote: > 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 > > > -- Niclas Hedhman, Software Developer http://zest.apache.org - New Energy for Java
