This looks pretty good, Ted. Just a couple of things: * If we're going to introduce the idea of Struts sub-projects right up front, then I would prefer to consider these as purely organisational, at least initially. That is, I'm open to breaking up the code base / docs / etc. into multiple sub-projects, but I would prefer that all people related matters span the Struts project. Specifically, I wouldn't want to allow for "sub-project X committers" as distinct from Struts committers. (Basically, I want to be quite clear that this is not an umbrella project in any shape or form. ;)
* In the Roles page, I'd prefer that the CLA submission be called out in the text, and not just left to the sample letter, as it is now. There has been confusion on this in Jakarta, so let's make it as clear as possible for Struts. ;-) * Should the release process (i.e. the Tomcat-like process we recently adopted) be part of the bylaws, or is that not necessary? That came to mind as I was reading the "Release Testing" section, since they're somewhat related. By the way, Stefan Bodewig put together a very nice wiki page to serve as a resource as the Gump team puts their own bylaws together: http://wiki.apache.org/gump/Drafts/ProjectBylaws It might be worth perusing for additional ideas. (I'm planning on doing some perusing of it myself when I have some time.) -- Martin Cooper On Thu, 18 Mar 2004, Ted Husted wrote: > On Wed, 17 Mar 2004 19:20:54 -0800 (PST), Martin Cooper wrote: > > I'll be putting together a list, shortly, of what needs to happen > > next for us to fully "graduate". Stay tuned... > > One thing the resolution mentions is that we are to draw up a set of bylaws. > > Heretofore, we've been operating under the Jakarta Guidelines, to good effect, IMHO. > > I recently created a proposed patch the guidelines to reflect that the PMC members > are the decisions makers, and that Committers are essentially Contributors with > write privileges. > > http://www.apache.org/~husted/jakarta-site2/site2-patch.txt > > copies of the affected pages as HTML: > > http://www.apache.org/~husted/jakarta-site2/guidelines.html > http://www.apache.org/~husted/jakarta-site2/roles.html > http://www.apache.org/~husted/jakarta-site2/communication.html > http://www.apache.org/~husted/jakarta-site2/decisions.html > http://www.apache.org/~husted/jakarta-site2/management.html > > Of course, the Bylaws or "management" page would have to be revised to reflect our > project. > > I would propose an extension to the Subproject section that says something like: > > ---- > > Subprojects are the project's unit of release. Each subproject should represent an > implementation of the Struts core or a related component. Each subproject should > focus on creating, maintaining, and releasing a single software product or > "deliverable". > > All PMC members have voting rights in all subprojects. Members not familiar with a > subproject codebase may abstain from any given vote. > > ---- > > The intent being that as we "rationalize" Struts, we can move things like the > taglibs and some of the contrib packages into their own subprojects, with their own > release cycles. > > When a subproject is created, we could decide whether a subproject needs its own > mailing list or not. I have no opinion as to USER lists, but would lean toward > keeping a single DEV list, for the sake of cross-pollination. In any event, mailing > list allocation is not part of the proposed, initial bylaws. > > If this sounds all right, I'll merge this with our existing documentation. Of > course, we can always change any of this later. But at least we will have fulfilled > that portion of the resolution. > > -Ted. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
