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]
