On Sat, 20 Mar 2004 14:27:34 -0800 (PST), Martin Cooper wrote: > 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. ;)
Yes, "All PMC members have voting rights in all subprojects. Members not familiar with a subproject codebase may abstain from any given vote." So, this is not Jakarta, nor the Commons, but more like the fabled "Agora". :) There should only be one list of committers, with equal access to all Struts repositories. And I would say that there should be a single DEV list, for the same reasons. As you say, the subprojects would be "organisation" units of release. Nothing more. No subcommittees, no subcommitters. We could also think about the term "product" rather than "subproject". Subproject just seemed to flow better. > * 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. ;-) Sure. > * 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. We already have that in our release guidelines, which would remain. We'd probably have to resolve some overlap, as you point out. > 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: struts-dev- >> [EMAIL PROTECTED] For additional commands, e-mail: >> [EMAIL PROTECTED] >> > > -------------------------------------------------------------------- > - 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]
