Indemnification of the PMC
Here is the clearest description I've found. It's by Roy Fielding, ex chair and board member of the ASF, and from all appearances, extremely knowledgeable in these matters. It was posted here : http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=2642 Indemnification is a promise by the corporation to pay the legal expenses of an *individual* if that *individual* becomes subject to criminal or civil proceedings as a result of their actions under a role identified by the corporation, as long as such person acted in good faith and in a manner that such person reasonably believed to be in, or not be opposed to, the best interests of the corporation. In other words, a member is only indemnified for their actions as a member (not much). A director or officer is only indemnified for their actions as a director or within the scope of their mandate as an officer. A PMC member is indemnified under the category of who is or was serving at the request of the corporation as an officer or director of another corporation, partnership, joint venture, trust or other enterprise and only to the extent of that enterprise (the project). A committer who is not a PMC member is not authorized by the corporation to make decisions, and hence cannot act on behalf of the corporation, and thus is not indemnified by the corporation for those actions regardless of their status as a member, director, or officer. Likewise, we should all realize and understand that the ASF's ability to indemnify an individual is strictly limited to the assets held by the ASF. Beyond that, we are on our own as far as personal liability. It is a far better defense that an outside entity cannot successfully sue an individual for damages due to a decision made by a PMC, so it is in everyone's best interests that all of the people voting on an issue be officially named as members of the PMC (or whatever entity is so defined by the bylaws). So in summary, a PMC member is indemnified for activities done on behalf of the corporation. I think that this would be limited to the official activities of the PMC - things done on behalf of the board for the ASF, such as oversight and releases - and not general day-to-day committer activities, such as technical discussion and personal code commits. Of course, that will probably need to be clarified too. However, the key thing to remember is that the indemnification is only up to the limit of the ASFs resources, which isn't much. So try to keep the litigation to a minimum :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
Oh, and thanks to Noel for the links... On Dec 23, 2003, at 6:49 AM, Geir Magnusson Jr. wrote: Here is the clearest description I've found. It's by Roy Fielding, ex chair and board member of the ASF, and from all appearances, extremely knowledgeable in these matters. It was posted here : http://nagoya.apache.org/eyebrowse/ReadMsg? [EMAIL PROTECTED]msgNo=2642 Indemnification is a promise by the corporation to pay the legal expenses of an *individual* if that *individual* becomes subject to criminal or civil proceedings as a result of their actions under a role identified by the corporation, as long as such person acted in good faith and in a manner that such person reasonably believed to be in, or not be opposed to, the best interests of the corporation. In other words, a member is only indemnified for their actions as a member (not much). A director or officer is only indemnified for their actions as a director or within the scope of their mandate as an officer. A PMC member is indemnified under the category of who is or was serving at the request of the corporation as an officer or director of another corporation, partnership, joint venture, trust or other enterprise and only to the extent of that enterprise (the project). A committer who is not a PMC member is not authorized by the corporation to make decisions, and hence cannot act on behalf of the corporation, and thus is not indemnified by the corporation for those actions regardless of their status as a member, director, or officer. Likewise, we should all realize and understand that the ASF's ability to indemnify an individual is strictly limited to the assets held by the ASF. Beyond that, we are on our own as far as personal liability. It is a far better defense that an outside entity cannot successfully sue an individual for damages due to a decision made by a PMC, so it is in everyone's best interests that all of the people voting on an issue be officially named as members of the PMC (or whatever entity is so defined by the bylaws). So in summary, a PMC member is indemnified for activities done on behalf of the corporation. I think that this would be limited to the official activities of the PMC - things done on behalf of the board for the ASF, such as oversight and releases - and not general day-to-day committer activities, such as technical discussion and personal code commits. Of course, that will probably need to be clarified too. However, the key thing to remember is that the indemnification is only up to the limit of the ASFs resources, which isn't much. So try to keep the litigation to a minimum :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-site2/xdocs/stylesheets project.xml
This message was too big for ezmlm... tetsuya 2003/12/23 04:34:12 Modified:docs index.html docs/site acknowledgements.html agreement.html binindex.html bugs.html communication.html contact.html contributing.html convert-to-mirror.html cvsindex.html cvsonunix.html cvsonwin32.html decisions.html dirlayout.html elsewhere-2003.html elsewhere.html faqs.html getinvolved.html guidelines.html guides.html idedev-rdeclipse.html idedev-rdnetbeans.html idedev-rdtomcat.html idedevelopers.html idiot.html jakarta-site-tags-example.html jakarta-site-tags.html jakarta-site2.html jakarta-site2b.html jars.html jon.html jspa-agreement.html jspa-position.html legal.html library.html mail.html mail2.html management.html methodology.html micromail.html mission.html newbie.html newproject.html news-2000.html news-2001.html news-2002.html news-2003.html news.html os.html other-releases.html overview.html packageversioning.html proposal.html roles.html source.html sourceindex.html understandingopensource.html vendors.html versioning.html whoweare.html docs/site/news 200206.html 200207.html 200208.html 200209.html 200210.html 200211.html 200212.html 200301.html 200303.html 200305.html editor.html index.html docs/site/pmc 01-01-17-meeting-minutes.html 01-01-17-pictures.html 01-03-19-meeting-agenda.html 01-03-19-meeting-irclog.html 01-03-19-meeting-summary.html 01-04-22-meeting-irclog.html 02-01-30-elections.html index.html xdocsindex.xml xdocs/site elsewhere.xml xdocs/stylesheets project.xml Log: Logging Services Project @ Apache Launched -- Log4j = Logging Services snip/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-site2/xdocs/site elsewhere.xml
tetsuya 2003/12/23 04:42:58 Modified:docs index.html docs/site elsewhere.html xdocsindex.xml xdocs/site elsewhere.xml Log: Logging Services Project @ Apache Launched -- Log4j = Logging Services Revision ChangesPath 1.352 +2 -2 jakarta-site2/docs/index.html Index: index.html === RCS file: /home/cvs/jakarta-site2/docs/index.html,v retrieving revision 1.351 retrieving revision 1.352 diff -u -r1.351 -r1.352 --- index.html23 Dec 2003 12:34:06 - 1.351 +++ index.html23 Dec 2003 12:42:58 - 1.352 @@ -616,8 +616,8 @@ lia href=#dbApache DB Project/a/li lia href=#httpdApache HTTP WebServer Project/a/li lia href=#incubatorApache Incubator Project/a/li -lia href=#loggingApache Logging Services Project/a/li lia href=#jamesApache James Project/a/li +lia href=#loggingApache Logging Services Project/a/li lia href=#mavenApache Maven Project/a/li lia href=#wsApache WebServices Project/a/li lia href=#xmlApache XML Project/a/li @@ -916,7 +916,7 @@ /th th bgcolor=#039acc colspan= rowspan= valign=top align=left font color=#00 size=-1 face=arial,helvetica,sanserif -font color=#ffstronga name=james href=http://logging.apache.org/;Apache Logging Services Project/a/strong/font +font color=#ffstronga name=logging href=http://logging.apache.org/;Apache Logging Services Project/a/strong/font /font /th /tr 1.107 +2 -2 jakarta-site2/docs/site/elsewhere.html Index: elsewhere.html === RCS file: /home/cvs/jakarta-site2/docs/site/elsewhere.html,v retrieving revision 1.106 retrieving revision 1.107 diff -u -r1.106 -r1.107 --- elsewhere.html23 Dec 2003 12:34:06 - 1.106 +++ elsewhere.html23 Dec 2003 12:42:58 - 1.107 @@ -199,9 +199,9 @@ h318 December 2003 - Apache Logging Services Project Launched/h3 /a p -The log4j developers are pleased to announce that the Board of +The a href=http://logging.apache.org/log4j/docs/;log4j/a developers are pleased to announce that the Board of Directors of the Apache Software Foundation unanimously passed a -resolution for the creation of the Apache Logging Services project. A +resolution for the creation of the a href=http://logging.apache.org/;Apache Logging Services project/a. A copy of the resolution can be found at: br / a href=http://nagoya.apache.org/wiki/apachewiki.cgi?LoggingApacheOrg/BoardResoluion;http://nagoya.apache.org/wiki/apachewiki.cgi?LoggingApacheOrg/BoardResoluion/a 1.290 +2 -2 jakarta-site2/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-site2/xdocs/index.xml,v retrieving revision 1.289 retrieving revision 1.290 diff -u -r1.289 -r1.290 --- index.xml 23 Dec 2003 12:34:12 - 1.289 +++ index.xml 23 Dec 2003 12:42:58 - 1.290 @@ -199,8 +199,8 @@ lia href=#dbApache DB Project/a/li lia href=#httpdApache HTTP WebServer Project/a/li lia href=#incubatorApache Incubator Project/a/li -lia href=#loggingApache Logging Services Project/a/li lia href=#jamesApache James Project/a/li +lia href=#loggingApache Logging Services Project/a/li lia href=#mavenApache Maven Project/a/li lia href=#wsApache WebServices Project/a/li lia href=#xmlApache XML Project/a/li @@ -325,7 +325,7 @@ /tr tr th/th -th align=centerfont color=#ffstronga name=james href=http://logging.apache.org/;Apache Logging Services Project/a/strong/font/th +th align=centerfont color=#ffstronga name=logging href=http://logging.apache.org/;Apache Logging Services Project/a/strong/font/th /tr tr td align=right valign=top 1.70 +2 -2 jakarta-site2/xdocs/site/elsewhere.xml Index: elsewhere.xml === RCS file: /home/cvs/jakarta-site2/xdocs/site/elsewhere.xml,v retrieving revision 1.69 retrieving revision 1.70 diff -u -r1.69 -r1.70 --- elsewhere.xml 23 Dec 2003 12:34:12 - 1.69 +++ elsewhere.xml 23 Dec 2003 12:42:58 - 1.70 @@ -16,9 +16,9 @@ h318 December 2003 - Apache Logging Services Project Launched/h3 /a p -The log4j developers are pleased to announce that the Board of +The a href=http://logging.apache.org/log4j/docs/;log4j/a developers are pleased to announce that the Board of Directors of the Apache Software Foundation unanimously passed a -resolution for the creation of the Apache Logging Services project. A +resolution for the
Re: [PROPOSAL] As it ever were
steward The proposal is to expand the role of the moderator, rather than invent an overlapping role with similar responsibilities. If the volunteer is not up to task, then another volunteer can be sought. (Hence, the language about the Chair appointing another volunteer.) The idea is that they have *already* volunteered to moderate the list. If one individual doesn't want to volunteer, another can be found. delegate The proposal does not delegate the board's responsibility. To be binding, anything voted on any DEV list would still need the a 3+ quorum of PMC members. PMC members would be voting on PMC business. There is nothing anywhere that says all the PMC business has to take place on a single list. If PMC members want to subscribe to all the lists and monitor all the PMC business, that's their choice. Conversely, if PMC members want to abstain from the routine business surrounding a given codebase, they don't have to subscribe to that DEV list. Meanwhile, through the steward's reports, the committee-at-large is being kept in the loop as to each subproject's big picture. The proposal does the things. * It realizes the fact that Jakarta doesn't have non-binding committers (meaning that all committers must become PMC members). * It provides a clear mechanism for scoping the work of the PMC. The business of each subproject can be conducted by people who are in-touch with that subproject on that subproject's DEV list. * It provides a clear channel for oversight. The steward's reports are designed to ensure that someone is at least thinking about these matters on a regular basis. Since it's someone's role to report on these things, they are more likely to be reported. Some issues we had in the past would not be readily addressed, since all the committers will be on the PMC list. A PMC member won't have to go off and talk to a subproject and report back. The subproject committers can hash issues out on the PMC list, where other members can provide input. And, any committer/PMC-member who thought there *might* be a problem, can now bring it up directly on the PMC list, whether the steward brings it up or not. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
Ted Husted wrote: steward The proposal is to expand the role of the moderator, rather than invent an overlapping role with similar responsibilities. If the volunteer is not up to task, then another volunteer can be sought. (Hence, the language about the Chair appointing another volunteer.) The idea is that they have *already* volunteered to moderate the list. If one individual doesn't want to volunteer, another can be found. They volunteer to moderate a mailing list, not send reports or be a sub-commitee secretary ( if sub-commitee would be allowed - which AFAIK is not ) :-) My point was that there is no need for another role or hierarchy. Would we start organizing elections for mailing list moderator ? delegate The proposal does not delegate the board's responsibility. To be binding, anything voted on any DEV list would still need the a 3+ quorum of PMC members. PMC members would be voting on PMC business. There is nothing anywhere that says all the PMC business has to take place on a single list. If PMC members want to subscribe to all the lists and monitor all the PMC business, that's their choice. Conversely, if PMC members want to abstain from the routine business surrounding a given codebase, they don't have to subscribe to that DEV list. I agree with that. But keep in mind that any PMC member can subscribe to any jakarta mailing list he wants and vote or -1 if he sees a problem ! I still think that important votes should take place on jakarta pmc list - this will keep the entire PMC in the loop. Meanwhile, through the steward's reports, the committee-at-large is being kept in the loop as to each subproject's big picture. The proposal does the things. What about changing from mail list moderator to the current release manager(s) ? Each codebase already has one ( or few ) release managers, and they are already responsible for announcing releases and important events. * It realizes the fact that Jakarta doesn't have non-binding committers (meaning that all committers must become PMC members). May. It is not mandatory. * It provides a clear mechanism for scoping the work of the PMC. The business of each subproject can be conducted by people who are in-touch with that subproject on that subproject's DEV list. +1 ( but votes should still be on [EMAIL PROTECTED] ) * It provides a clear channel for oversight. +1 The steward's reports are designed to ensure that someone is at least thinking about these matters on a regular basis. Since it's someone's role to report on these things, they are more likely to be reported. Some issues we had in the past would not be readily addressed, since all the committers will be on the PMC list. A PMC member won't have to go off and talk to a subproject and report back. The subproject committers can hash issues out on the PMC list, where other members can provide input. And, any committer/PMC-member who thought there *might* be a problem, can now bring it up directly on the PMC list, whether the steward brings it up or not. Well, a PMC member won't talk to a subproject - it may talk with fellow PMC members if he is not tracking that project. Anyway - I think it's a good idea to have someone send reports, I just think that the release managers are a better choice. They are already responsible for making the proposal and vote for the release. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
Make release managers the default stewards Not every subproject has a clearly defined release manager. In Struts, we are even starting to have multiple people collaborate on the release manager role. The key to oversight is persistence. Since it is not possible for every committee member to be personally aware of what's happening in every subproject, we need regular reports from someone who does -- just as the board needs regular reports from each chair. We don't need for subprojects to have a chair, but we do need someone to tender regular reports as to the subproject's status. The keyword being regular. The person making these reports should already have a working knowledge of the subproject and be able to report based on what they already know. Of course, what they know is based on reading and understanding the traffic on the lists. Ideally, the DEV list moderator should also be someone who is plugged into the subproject. So, instead of starting out by creating two roles with overlapping responsibilities, I'm suggesting we try extending the list moderator's role first. List moderator is the only persistent role that must already exist for each subproject's DEV list. In some cases, we may need to have different volunteers fulfilling each role. But, personally, I like to try making do with what we have before running out and creating something new. I also don't want to get bogged down with finding a steward for each subproject. The DEV list moderators are there, so let's use them. If a list moderator doesn't want to steward, then I'm sure they can find someone who does. Hey, we all friends here. :) The key point is that the chair, and its PMC, need consistent, reliable reports, so that the chair can report in turn to the board. We need each subproject to fulfill the responsibility of regular reporting by whatever means necessary. We also need to push that responsibility down to the subproject. The people working in the subproject are the only ones truly aware of its status. Should we encourage subprojects to elect a steward? No. AFAIK, we don't elect roles like list moderator or release manager. People just step up and offer to do the job -- as it should be. But if a subproject wants to a elect a steward, or a list moderator, or a release manager. that's their business. All we need is for the job to get done. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
On Tue, 23 Dec 2003 12:10:03 -0500 (Subject: Re: [PROPOSAL] As it ever were) Ted Husted wrote: steward The proposal is to expand the role of the moderator, rather than invent an overlapping role with similar responsibilities. If the volunteer is not up to task, then another volunteer can be sought. (Hence, the language about the Chair appointing another volunteer.) The idea is that they have *already* volunteered to moderate the list. If one individual doesn't want to volunteer, another can be found. You can check who is/are current moderator(s) of XX subproject, by using the method which can be found at /committers/docs/mailinglist-tips.txt (committers module) 'How to know Who is moderator of XX list / Number of subscribers' section (resource.txt is also good) You may post to the address which can be found there with this two lines body -- === [EMAIL PROTECTED] gump ==(two lines)== -- Hope this helps. -- Tetsuya. ([EMAIL PROTECTED]) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] ORO 2.0.8 maintenance release
+1
On Dec 23, 2003, at 8:39 PM, Daniel F. Savarese wrote:
I know now may not be the best time to have a vote, but I would ask
the PMC to vote on approving the release of jakarta-oro 2.0.8.
The current code base contains important bug fixes and has gone too
long without a public release.
[ ] +1 I approve the release of jakarta-oro version 2.0.8.
[ ] -1 I do not approve the release of jakarta-oro version 2.0.8.
This vote will last until the end of Saturday 27th, 2003 (72 hours
minus the Christmas holiday). In accordance with
http://jakarta.apache.org/site/decisions.html, at least three binding
+1 votes are required for this vote to pass and the number of +1 votes
must exceed the number of -1 votes. Non-PMC members are encouraged
to cast their non-binding votes (please indicate your vote is
non-binding to facilitate vote tabulation).
RELEASE INFORMATION:
The 2.0.8 release will be a maintenance release incorporating the
following
changes since the 2.0.7 release made in January (taken from
http://cvs.apache.org/viewcvs/~checkout~/jakarta-oro/CHANGES?content-
type=text/plain):
o examples moved to an examples package and com.oroinc migration tool
moved to tools package.
o Fixed bug whereby compiling an expression with
Perl5Compiler.MULTILINE_MASK wasn't always having the proper effect
with respect to the matching of $ even though
Perl5Matcher.setMultiline(true) exhibited the proper behavior. For
example, the following input
aaa bbb \n ccc ddd \n eee fff
should produce bbb , ddd , and fff as matches for both the
patterns \S+\s*$ and \S+ *$ when compiled with MULTILINE_MASK.
Perl5Matcher was only producing the correct matches for the second
pattern, producing only fff as a match for the first pattern
unless setMultiline(true) had been called. This has now been fixed.
o Fixed embarrassing bug whereby an expression like (A)(B)((C)(D))+
when matched against input like ABCDE would produce matching groups
of: A B null D instead of A B CD C D.
These changes have been available to the public in the CVS repository
for testing since May 2003. There are no outstanding/unresolved issue
reports for the code.
Daniel Savarese (dfs.apache.org) will serve as the release manager for
this release. A release announcement will be sent to
{oro-dev,oro-user,[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Geir Magnusson Jr 203-247-1713(m)
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were
On Tue, 23 Dec 2003, Ted Husted wrote: Make release managers the default stewards My suggestion: Work out what people on the PMC are members of the PMC for. ie) I consider myself a Taglibs and Commons developer [both umberella projects so not great examples]. List which projects people are on the PMC for. These people are now required to submit a report to the chair (PMC in general). Whether they break it down further [ie) Commons], or choose one amongst themselves is up to themselves. So basically the PMC making a requirement of a part of their community to be responsible for a part of their codebase. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] ORO 2.0.8 maintenance release
I know now may not be the best time to have a vote, but I would ask
the PMC to vote on approving the release of jakarta-oro 2.0.8.
The current code base contains important bug fixes and has gone too
long without a public release.
[ ] +1 I approve the release of jakarta-oro version 2.0.8.
[ ] -1 I do not approve the release of jakarta-oro version 2.0.8.
This vote will last until the end of Saturday 27th, 2003 (72 hours
minus the Christmas holiday). In accordance with
http://jakarta.apache.org/site/decisions.html, at least three binding
+1 votes are required for this vote to pass and the number of +1 votes
must exceed the number of -1 votes. Non-PMC members are encouraged
to cast their non-binding votes (please indicate your vote is
non-binding to facilitate vote tabulation).
RELEASE INFORMATION:
The 2.0.8 release will be a maintenance release incorporating the following
changes since the 2.0.7 release made in January (taken from
http://cvs.apache.org/viewcvs/~checkout~/jakarta-oro/CHANGES?content-type=text/plain):
o examples moved to an examples package and com.oroinc migration tool
moved to tools package.
o Fixed bug whereby compiling an expression with
Perl5Compiler.MULTILINE_MASK wasn't always having the proper effect
with respect to the matching of $ even though
Perl5Matcher.setMultiline(true) exhibited the proper behavior. For
example, the following input
aaa bbb \n ccc ddd \n eee fff
should produce bbb , ddd , and fff as matches for both the
patterns \S+\s*$ and \S+ *$ when compiled with MULTILINE_MASK.
Perl5Matcher was only producing the correct matches for the second
pattern, producing only fff as a match for the first pattern
unless setMultiline(true) had been called. This has now been fixed.
o Fixed embarrassing bug whereby an expression like (A)(B)((C)(D))+
when matched against input like ABCDE would produce matching groups
of: A B null D instead of A B CD C D.
These changes have been available to the public in the CVS repository
for testing since May 2003. There are no outstanding/unresolved issue
reports for the code.
Daniel Savarese (dfs.apache.org) will serve as the release manager for
this release. A release announcement will be sent to
{oro-dev,oro-user,[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
