Hi Andy and all, I've now rolled some of the points that we seem to have consensus on into the original charter I suggested back at the beginning of April. I've posted it on the Wiki page [*] where Berin had kindly placed his reworking of that document. I'm also attaching a diff of my original suggestion to the modified one, in case that makes review easier for people: (See attached file: charter-changes.txt) If we can get agreement on that, then I for one would be cool for actually voting on the resolution Berin drafted for us (which I've included below, with a few modifications, chief among them an attempt at specifying the composition of the PMC based on who it seems to me are the active committers these days). I haven't tried to fill in the field for PMC Chair though. :) As always, feedback more than appreciated! Cheers, Neil [*]: http://nagoya.apache.org/wiki/apachewiki.cgi?XMLProjectPages/XercesCharterDiscussion ************* Draft Motion on Xerces ************** WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to XML parsers, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the "Xerces PMC", be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Xerces PMC be and hereby is responsible for the creation and maintenance of open-source software related to XML parsing and closely related technologies based on software licensed to the Foundation; and be it further RESOLVED, that the office of "Vice President, Xerces" be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Xerces PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Xerces PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Xerces PMC: * Neeraj Bajaj <[EMAIL PROTECTED]> * James Berry <[EMAIL PROTECTED]> * Andy Clark <[EMAIL PROTECTED]> * Sandy Gao <[EMAIL PROTECTED]> * Michael Glavassevich <[EMAIL PROTECTED]> * Neil Graham <[EMAIL PROTECTED]> * Kohsuke Kawaguchi <[EMAIL PROTECTED]> * Elena Litani <[EMAIL PROTECTED]> * Alberto Massari <[EMAIL PROTECTED]> * Khaled Noaman <[EMAIL PROTECTED]> * K.Venugopal Rao <[EMAIL PROTECTED]> * Gareth Reakes <[EMAIL PROTECTED]> * Jason Stewart <[EMAIL PROTECTED]> * PeiYong Zhang <[EMAIL PROTECTED]> NOW, THEREFORE, BE IT FURTHER RESOLVED, that REPLACE WITH CHAIR be and hereby is appointed to the office of Vice President, Xerces, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Xerces PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Xerces Project; and be it further RESOLVED, that the initial Xerces PMC be and hereby is tasked with the migration and rationalization of the Apache XML PMC Xerces subproject; and be it further RESOLVED, that all responsibility pertaining to the XML Xerces sub-project and encumbered upon the Apache XML PMC are hereafter discharged. Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] Andy Clark <[EMAIL PROTECTED] To: [EMAIL PROTECTED] et> cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [VOTE]: motion to transform Xerces into a top-level project as a member 05/12/2004 01:44 of the "federation" of XML projects PM Please respond to pmc Neil Graham wrote: >>So "Xerces" would be the project whereas "Xerces-J" would >>be a product release of Xerces in Java. An example sub-project >>would be "HTML" which, again, would have products based on the >>implementation language. They would be bundled together for >>organizational reasons, not for releases. > > Conceptually, the only difficulty I'd have with this is that it's no longer > crystal clear what the commonality between the subprojects is. I'd thought It's not clear to *you*, is what you mean. It's perfectly clear to me. ;) > that the "Xerces" TLP would be all about Apache's offerings related > specifically to XML parsing first, and perhaps very closely related > technologies second. That sounds exactly like what I'm proposing through my use of the terms "project" and "sub-project". Parsing is the project and things related to parsing are sub-projects. Products is the way that the implementations are separated from each other within the project. So someone comes to the website looking for XML parsers and they go the the Xerces Project. Then they decide what language they need, Java, so they download the Xerces-J product. Next, they want to be able to parse HTML, so they look at the Xerces HTML sub-project. There they see that there is an implementation in Java for use with the XML parser they just downloaded. In this situation, of course there are things that need to be broken out of Xerces-J as it stands today. But once that is done, they are each developed and packaged separately. It's primarily the website organization that reflects the hierarchy and relationships between these separate things. >>I'm specifically trying to organize the Xerces TLP so that >>I can formally donate NekoHTML to the Xerces project for the >>Xerces-J product. > > I'd been guessing that. :) I'm asked on a regular basis if/when it will be merged into Xerces-J so this is a perfect opportunity to do that. > * project: the top level project (TLP), charged with XML parsing > and closely allied technologies > * sub-project: either > o an XML parser implementation in a particular language, or > o a "tools" subproject containing useful products that are > tightly bound, usually by nonstandard API's, to one of the other > subprojects But this puts dependent products at the same level as the parser. You would think they would be *under* the parser because of the dependency. > The tools subproject could contain products from as many languages as there > were parsers. I'm also fine with removing the restriction that we have one > parser per language; we may want a Xerces-J-Pull at some point. Well, that was certainly one of my biggest problems with the original draft. > Once again, I'd love to call on other folks from Xerces-land. Andy and I > are having a good time talking among ourselves, but it's tough to gauge the > consensus of a community when you only ever hear two voices... It does seem rather quiet around here. I'm surprised that noone else has added their ideas to the discussion. Perhaps they're scared of me. ;) -- Andy Clark * [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
charter-changes.txt
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
