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
>

Reply via email to