Bylaws (was Re: [ANNOUNCE] Struts goes TLP with unanimous vote...)
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]
Re: Bylaws (was Re: [ANNOUNCE] Struts goes TLP with unanimous vote...)
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
Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
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]
Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
At 7:11 AM -0500 3/18/04, 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 Maybe I'm reading the diffs wrong, but I think that it says + However, the only binding votes are those cast by a PMC Member. (in decisions.xml, patch line 51) and also + Those who have been longterm or valuable contributors to the project + can earn the right to commit directly to the source repository and to + cast binding votes during the decision-making process. (roles.xml, patch lines 279-281) Actually, now that I read the generated HTML, I can see how this isn't actually a conflict -- the roles.xml blurb isn't actually saying that committers get to cast binding votes... I'm not coming up with better verbiage, but one clarification would be to add some text later in the document under the PMC section specifically mentioning voting. Not a huge deal really, but clarity is a good thing. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
On Thu, 18 Mar 2004 08:01:35 -0600, Joe Germuska wrote: Actually, now that I read the generated HTML, I can see how this isn't actually a conflict -- the roles.xml blurb isn't actually saying that committers get to cast binding votes... I'm not coming up with better verbiage, but one clarification would be to add some text later in the document under the PMC section specifically mentioning voting. Not a huge deal really, but clarity is a good thing. Agreed. The point is that only the PMC Members have binding votes, and we should be sure the posted text relects that. I think in our case, like HTTPD, any active Committers will end up as PMC Members anyway. But, given our experience, I think the now-conventional two-step process will help reduce the number of inactive PMC Members. It's not been uncommon for a new Struts Committer to fall away after a few months. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Struts goes TLP with unanimous vote...
Guys, Just got the summary email from the Apache board meeting, and the Struts proposal went through with flying colours. Congrats guys, really. So much never-ending quality work. I guess that with everyone else out driking Irish alcohol I was the first to see the email, and I got to be the whistle-blower. :) Cheers, Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANNOUNCE] Struts goes TLP with unanimous vote...
On Wed, 17 Mar 2004, Arron Bates wrote: Guys, Just got the summary email from the Apache board meeting, and the Struts proposal went through with flying colours. Congrats guys, really. So much never-ending quality work. I guess that with everyone else out driking Irish alcohol I was the first to see the email, and I got to be the whistle-blower. :) Nah, you just type a little faster than I do. ;-) I'll be putting together a list, shortly, of what needs to happen next for us to fully graduate. Stay tuned... -- Martin Cooper Cheers, Arron. - 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]
RE: [ANNOUNCE] Struts goes TLP with unanimous vote...
Yay, Struts! Congratulations to everyone and special thanks to Martin for preparing the proposal. Thanks also to Craig for agreeing to be the scapego.. err.. VP of the new project. Steve -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: March 17, 2004 7:21 PM To: Struts Developers List Subject: Re: [ANNOUNCE] Struts goes TLP with unanimous vote... On Wed, 17 Mar 2004, Arron Bates wrote: Guys, Just got the summary email from the Apache board meeting, and the Struts proposal went through with flying colours. Congrats guys, really. So much never-ending quality work. I guess that with everyone else out driking Irish alcohol I was the first to see the email, and I got to be the whistle-blower. :) Nah, you just type a little faster than I do. ;-) I'll be putting together a list, shortly, of what needs to happen next for us to fully graduate. Stay tuned... -- Martin Cooper Cheers, Arron. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
