Re: [VOTE] dims for incubator PMC
Sam Ruby wrote: Davanum Srinivas is an ASF member and an ASF officer and chair of the web services PMC. He is very interested in the incubation of the WSRP4J and Pluto podlings. I would like to see him included in the incubator PMC. Let me start things off with my: +1. Sam, I sent a mail titled: "[VOTE] Davanum Srinivas as committer and PMC member of Incubator" dated 12/09/2003 14.18. The only replies were from Jim and Sander. I'm confused to see this mail now :-? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
Stefano Mazzocchi wrote: On Friday, Sep 19, 2003, at 14:05 Europe/Rome, Nicola Ken Barozzi wrote: Stefano Mazzocchi wrote: ... the members came to consensus agreeing that project umbrellas are a pain in the ass and a PMC should be as close as possible to the code it develops, as to increase the ability to do proper legal oversight. [note: this notion is in *strong* contrast with this virtual-PMC... It is not. Lenya is being incubated under the Cocoon PMC. So we have two flavors of incubation, direct and indirect? Probably you don't read my mails, because I explained this in detail on the Cocoon PMC list, after one of your rants on incubation. The Chair of that PMC is the sponsor. Really? I thought I was the sponsor. Really? Didn's see you there much :-P What happened with the latest Xopus incident it was the Incubator Shepherd, not the Cocoon PMC that started cleaning stuff and addressing the issues. Sorry, can't parse the above. So don't talk to me about virtual stuff, when the recent history shows that the Cocoon PMC, of which you are an important part, has been as virtual as ever, despite being given all the liberty possible in incubating Lenya. please, Nicola, your defensiveness is useless here since I'm confronting with the 'concept' of the incubation PMC not with the people that compose it. Well, I'm talking about facts instead, not mere "concepts". Facts show us that PMCs left on their own do not overlook an incubation process correctly. In the lenya case, oversight doesn't mean "error free operation". The lenya people failed to comply to the advertising clause of one of their included software. As you yourself wrote, it was merely a defect in the build script that didn't copy the appropriate file in the distribution. I wouldn't call this "virtual operation". Lack of involvment on the lenya mailing lists. I call that "virtual operation". As the answers to that thread showed, oversight from Cocoon PMC members is continuous and prompt... but this doesn't mean that we have to do the work for them... This wouldn't scale. I don't parse this. You want to Incubate Lenya? You are free and *encouraged* to do so, nobody has prevented you or any other person on earth from doing it. So why in hell do we need an incubator? for those projects that nobody really cares about? or just to stamp a 'yes go on with that PMC but play nicely' to all those who come with a proposal? I don't understand: what is this incubator doing anyway if all the projects are incubated somewhere else? 1 - votes the projects into Apache after check that all the nitty-gritty stuff has been taken care of 2 - serves as a central place to store incubation history and information 3 - serves as a place where to discuss incubation per se, where shepherds, sponsors and project members can confront 4 - serves as a place where to incubate TLP In essence it's a box, not a club where only the greatest can rule . which, IMO, should be redesigned since it clearly creates more beaurocracy than any good] The problem is that it has *not* created yet any beaurocracy. Oh god, don't you realize that it could be that people don't complain to you because you can get so defensive so fast? I hear enough complaints here, thank you. People complain about lack of rules, not because there are too many. Really? who did? Everyone. For example Berin Lautenbach and Ted Leung, but you can put basically anyone that asked us for something. We have only one true rule, that we should vote for a project to be accepted fully at Apache, based on a simple checklist. If this is beaurocracy... Ok, let's change the word so you don't get defensive: did the presence of the incubator prevent issues or created them? It has made issues that without it are simply ignored finally evident. As for other issues, they are usually created by people complaining here and not helping out. I vote for the second. Then add some explanation to your vote please, because I don't see how the Incubator has created issues to Lenya. Call me defensive, but I have never seen a project that has been under fire from flamers like this one in all my life. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] PMC Vote to incubate Directory Project
Phil, The LDAPd server in its present state could eventually support X.500 over TCP/IP. In fact both X.500 and LDAP seem to be coming closer every day since X.500 made the jump to using TCP/IP. I think the two will eventually come back together. For the time being when we speak about a directory project we could presume any searchable hierarchical namespace to be a form of directory. Let's not limit our selves to just LDAP. As you pointed out there will be more to this endeavor as a consequence of JNDI. It's very natural to associate JDBC related source with the db.apache.org TLP. Likewise a similar association exists between JNDI and the directory project side whatever it may be called. And again as you mentioned the potential for other applications on top of the directory services are possible. An identity management system project is a natural progression. As a matter of fact I founded the LDAPd Group specifically for this purpose. Necessity is the mother of invention right? Other examples of potential subprojects could be an ASN.1 runtime library and its associate stub compiler. LDAPd already has ASN.1 runtime clone of SNACC called 'snickers' - its just missing a compiler. A meta-directory, a virtual directory and a JNDI LDAP provider are all potential subprojects. The embeddable nature of the server brings about incredible synergy between it and other Apache projects. Integration effort will probably be facilitated by the directory people however obviously the end result will reside within its own sphere. Take for example the potential for white pages backed by LDAP in JAMES. Integration could serve as the basis for Geronimo's security subsystem. Integration with Struts and an identity management system built on top of the directory server could allow for authorization driven rendering. There's also UDDI backed by LDAP. All these synergies are very attractive and integration efforts could bring about collaboration with many projects however the end result will rest within the respective domain. Roy, Other synergies certainly exist outside of an embeddable configuration. Obviously certain language barriers are overcome by the protocol. The httpd mod_ldap DSO module can use the directory server. Other plugins can be added to the list like a mod_ldapconf module that pulls Apache virtual host configuration information from a directory. ISP's and ASP's would really love this one. Several possibilities exist and I'll stop here before I bore you. The space is huge and the probability of budding projects and some in other languages is certainly high. Language will be transcended and if API's need to be carved out for other languages they probably will out of necessity. The RFC based protocol makes the server's implementation irrelevant. Any client should be able to talk to it. Plus I'm sure with an Avalon.Net quickly emerging someone with an itch might toy with bringing it over to C# with a JNDI analog in that realm. Naming is so important to directories so I guess I'll put in my $0.02 about what the project could be called. Directory sounds good and so does directory services. It's general enough to allow the full gambit of coverage for the related spin-offs. As a side note, just for the name of the LDAP server (not the overall project) you probably couldn't use AD for the Apache Directory I would imagine ;-). A few months ago while working on the new architecture for LDAPd I looked at AD in Application Mode or ADAM (a.k.a. AD/AM) while still in beta. It suddenly dawned upon me that I had to code name the new LDAP daemon architecture 'Eve' which would be analogous to Tomcat's 'Catalina'. I have a soft spot for her ;-). Folks me know what you think about 'Eve' in particular. Cheers, Alex > -Original Message- > From: Phil Steitz [mailto:[EMAIL PROTECTED] > Sent: Monday, September 22, 2003 1:56 AM > To: [EMAIL PROTECTED] > Subject: Re: [PROPOSAL] PMC Vote to incubate Directory Project > > Roy T. Fielding wrote: > >>> Greg posted a message back on the 18th noting that a PMC vote on the > >>> entry of the project to the incubator would be kicked off under the > >>> private [EMAIL PROTECTED] list. I don't know the specifics of Incubator > >>> voting policies but I guessing we will see a vote result early next > >>> week. > >> > >> > >> I saw that. Nonetheless, I still find it odd that there has been > >> virtually no "public" discussion of the merits of the proposal and I > >> felt the need to express my opinion. No disrespect for the process, > >> de facto or documented, intended. > > > > > > Hmm, in general, the only discussions we ever hold in private are those > > relating to non-disclosure issues or personnel issues. We would have a > > discussion and vote about the directory project on the general list. > > The reason we haven't is because it is being suggested to incubator > itself > > rather than some other project or the board, which means it is wai
Re: Re: [PROPOSAL] PMC Vote to incubate Directory Project
> From: Nicola Ken Barozzi <[EMAIL PROTECTED]> > > I don't understand: what is this incubator doing anyway if all the > > projects are incubated somewhere else? > > 1 - votes the projects into Apache after check that all the nitty-gritty > stuff has been taken care of Or does it recommend to another body that incubation processes have completed sucessfully and that that body can take on subject to their own vote. For example, I don't think the Incubator can approve a new TLP without the board voting, but it might recommend to the board that all necessary activities have been comleted. Again - I am not convinced that the Incubator should be the arbiter of what is accepted, but it definitely should be the guardian of correct process. > 2 - serves as a central place to store incubation history and > information +1. Would be good to formalise. > 3 - serves as a place where to discuss incubation per se, where > shepherds, sponsors and project members can confront +1. > 4 - serves as a place where to incubate TLP > Serves as a place to incubate anything surely? > >> People complain about lack of rules, not because there are too many. > > > > Really? who did? > > Everyone. For example Berin Lautenbach and Ted Leung, but you can put > basically anyone that asked us for something. > Just to clarify - my issue is not too many or to few rules, but that I'd like to see the rules clearly documented so that I can ensure that anything I am involved in incubating is doing what it needs to do. I've also worked a long time in large organisations, so I have a paranoia around being blind-sided by requirements I didn't know existed because they weren't documented. That might be playing in a little here :>. Cheers, Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] PMC Vote to incubate Directory Project
> Facts show us that PMCs left on their own do not overlook > an incubation process correctly. Clearly there are lines of communication that can be improved, as well as roles and responsibilities to clarify. Incubation can be collaborative. And the behavior that the podling sees between its parents is going to set an example, which is something that both the Sponsor and Shephard should take into account in how they interact with each other, as well as with the podling. Starting with displaying respect, even in the face of disagreement. > 1 - votes the projects into Apache after check that all the > nitty-gritty stuff has been taken care of > 2 - serves as a central place to store incubation history > and information > 3 - serves as a place where to discuss incubation per se, > where shepherds, sponsors and project members can confront > 4 - serves as a place where to incubate TLP Good list. I see that Berin just responded to it, agreeing and asking for a bit of clarification. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
Berin Lautenbach wrote: ... Just to clarify - my issue is not too many or to few rules, but that I'd like to see the rules clearly documented so that I can ensure that anything I am involved in incubating is doing what it needs to do. Oh, and to clarify from my side, you are helping us on the issues you noted. I've also worked a long time in large organisations, so I have a paranoia around being blind-sided by requirements I didn't know existed because they weren't documented. That might be playing in a little here :>. You are right in our need to document, and I'm happy that you are indeed actively helping out. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
Jim Jagielski wrote: -- Andrew C. Oliver|acoliverapache.org |2003-08-22| 144| Nicola Ken Barozzi |nicolakenapache.org|2003-09-19| 142| Rodent of Unusual Si|coarapache.org |2003-09-21| 141| Greg Stein |gsteinapache.org |2003-09-19| 68| Tetsuya Kitahata|tetsuyaapache.org |2003-09-21| 57|Becky! ve Noel J. Bergman |noelapache.org |2003-09-21| 57|Microsoft Paul Hammant|hammantapache.org |2003-09-19| 56| Steven Noels|stevennapache.org |2003-09-21| 55| Jim Jagielski |jimapache.org |2003-09-19| 50|Apple Mai Sander Striker |strikerapache.org |2003-09-18| 48|Microsoft Aaron Bannert |aaronclove.org |2003-08-08| 46|Apple Mai Sam Ruby|rubysapache.org|2003-09-20| 44| Davanum Srinivas|dimsapache.org |2003-09-18| 41| Ted Leung |twlapache.org |2003-09-19| 36| James Strachan |jstrachanapache.org|2003-08-22| 30|Apple Mai -- (e.g. Ken.CoarGolux.Com => coarapache.org ... ) This shows absolutely nothing more than the number of Emails sent to the list (I'm guessing). So what? Or are we somehow equating quantity to quality? It may also mean (and from my experience it usually does), that the top email posters are the ones that think less before posting, thus /possibly/ decreasing the signal/noise ratio of the list. In essence, I make a lot of noise ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
Java is simply the chosen implementation platform for an RFC-compliant server, just as C/APR is the implementation platform for the HTTP server. The wire-level protocol is RFC based and language neutral. The project can host other languages when appropriate, and would certainly provide information on other language bindings for LDAP. That isn't the question I was asking. If someone else comes to Apache and says they want to start an LDAP server project using, for example, the Netscape code base (C++, I think) and another comes in wanting to establish a Python library for builtin calls to LDAP, should the ASF direct those projects to this same group or to their own projects? I have no problem with protocol-centric projects, and no problem with language-centric projects, but I do have a problem with protocol-centric projects that assume one implementation language is "best". Those types of projects create failure conditions that are very messy from the board's POV. So, if the project is going to be language-agnostic, then I want that written into the charter and growth anticipated. If not, then I want that written into the charter and a different name given to this project. Doesn't that make sense? Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
Phil Steitz wrote: > > I would humbly suggest that there is no harm in public discussion of > incubator project proposals, understanding that the voting is private, > by the PMC. Public discussion and nonbinding statements of > support/non-support by non-PMC members could provide valuable > information to the PMC in their decision-making. +1 -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
On Monday, Sep 22, 2003, at 04:37 Europe/Rome, Noel J. Bergman wrote: Berin, http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings Had a read. Great stuff :>. At a quick glance, I see some things to change. - there has not been stated a minimum community size to start - it has been explicitly stated that a project does NOT need to have its exit destination known at entry time. Clearly a project will not leave the Incubator without meeting those criteria, but they are not required entry criteria. What is the break up of responsibility between the Incubator PMC and the Sponsoring PMC in cases such as XMLBeans. In these cases, the Sponsoring PMC seems to take on much of the role that is discussed in the document. In my view, the Sponsoring PMC *should* take an active role. But the Incubator PMC is still responsible for making sure that all of criteria are met before letting it into the ASF proper. Looking over the document, the Sponsoring PMC would be in the role of Sponsor, and is invested in project and Community building, whereas the Incubator PMC is still acting as the gatekeeper, ensuring the legal protection of the ASF. Whatever tasks the Sponsor overtakes to help shephard the project, which can reduce the workload on the Incubator PMC, the Incubator PMC still has that final responsibility. I agree with the principle (otherwise we get back to complete PMC incubation independence and things blow up) but there are a few things worth asking: 1) how do people get on the incubation PMC? any committer? only members? members and officials? everybody committer that previously has a record of helping incubation? just curious of what feelings are. 2) isn't the incubation more an oversight group, a task force, then a project? 3) shouldn't the sponsor PMC provide periodical updates on the status to the incubator? I know the above sounds utterly beaurocratic, but I can't think of anything simpler than this. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
On Monday, Sep 22, 2003, at 01:26 Europe/Rome, Stephen McConnell wrote: Stefano Mazzocchi wrote: I said nothing about documentation, process, policy or accountability. LOL We certainly agree on this! :-) Agree about what? that I didn't say what you previously accused me of having said? This is getting silly. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
Nicola Ken Barozzi wrote: Steven, sorry that I probably gave the wrong impression that you were not involved, as you were. No problem. Just wanted to put things straight. No hard feelings. But you are not the Cocoon PMC, and I wanted to point out that there was not much incolvment of the PMC as a whole WRT Lenya. Ack. There is indeed little involvement, and IMHO this has two reasons: - this project has been force-fed to Apache/Cocoon prematurily, by lust of its sponsors to achieve a certain functional dream, but not taking into account the existing codebase and the company(/community) behind it - Cocoon as a TLP isn't quite ready to incubate podlings yet Lenya, IMHO (!), is an example of my lab rats thesis: http://blogs.cocoondev.org/stevenn/archives/000550.html But this is largely OT for this thread. I'm concerned about a well-defined process and exit criteria, though, since somewhere in time, we will be expected to judge the incubation state of Lenya. -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java & XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
Roy T. Fielding wrote: > > I have no problem with protocol-centric projects, and no problem with > language-centric projects, but I do have a problem with protocol-centric > projects that assume one implementation language is "best". Those types > of projects create failure conditions that are very messy from the > board's POV. So, if the project is going to be language-agnostic, then > I want that written into the charter and growth anticipated. If not, > then I want that written into the charter and a different name given > to this project. Doesn't that make sense? plus a project that is explicitly language-centric shouldn't grab a generic name. if this project *isn't* going to be the potential home for a python (for example) implementation, then it shouldn't have the generic name 'apache directory'. otherwise it isn't fair to potential newcomers with a different language bent. we're not perfect in application; i'm not sure what would happen if someone wanted to start a web server written in ada under the asf. however, the httpd server project has its name from legacy so this wasn't a consideration then. :-) -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
On Monday, Sep 22, 2003, at 09:04 Europe/Rome, Nicola Ken Barozzi wrote: The Chair of that PMC is the sponsor. Really? I thought I was the sponsor. Really? Didn's see you there much :-P Which might also show how many private emails you might have missed? Incubation is more a social operation than a beaurocratic one. It's not only about the proper CVS usage and the legal oversight, it's making sure that human friction is resolved before it shows up. Public visibility of that process is very small, but extremely important. What happened with the latest Xopus incident it was the Incubator Shepherd, not the Cocoon PMC that started cleaning stuff and addressing the issues. Sorry, can't parse the above. So don't talk to me about virtual stuff, when the recent history shows that the Cocoon PMC, of which you are an important part, has been as virtual as ever, despite being given all the liberty possible in incubating Lenya. please, Nicola, your defensiveness is useless here since I'm confronting with the 'concept' of the incubation PMC not with the people that compose it. Well, I'm talking about facts instead, not mere "concepts". Facts show us that PMCs left on their own do not overlook an incubation process correctly. This is disturbing, expecially since there is no incubation process documented and "correctness" is just a subjective measure. In the lenya case, oversight doesn't mean "error free operation". The lenya people failed to comply to the advertising clause of one of their included software. As you yourself wrote, it was merely a defect in the build script that didn't copy the appropriate file in the distribution. I wouldn't call this "virtual operation". Lack of involvment on the lenya mailing lists. I call that "virtual operation". I met the wyona people in person several times and had private communications with them. Does that account as virtual as well since it didn't happen on a mail list? As the answers to that thread showed, oversight from Cocoon PMC members is continuous and prompt... but this doesn't mean that we have to do the work for them... This wouldn't scale. I don't parse this. Let me rephrase: instead of feeding them, I want them to learn how to grow their own food. my *personal* vision of incubation is more oriented toward social engineering that infrastructure or legal oversight. why? well, because a well-behaving community will well-behave at the infrastructure level *and* at the legal level. I wrote several private emails (some copied to the cocoon pmc, some not) to the lenya people when I thought that they were doing something potentially wrong... but I did *NOT* fix their license for them. Oversight and sheparding means parenting, but should also give freedom to make mistakes, because, sometimes, making mistakes is the only way one can learn something. This last xopus legal thing showed to them many things that they wouldn't have otherwise noted. I was hoping for something like this to happen because Michael spent way too much energy and effort in trying to convince non-oss-minded people to join, instead of just focusing on his own stuff. but of course, since I didn't write many emails, I'm not following nor I'm well behaving as a sponsor. quantity vs. quality again? You want to Incubate Lenya? You are free and *encouraged* to do so, nobody has prevented you or any other person on earth from doing it. So why in hell do we need an incubator? for those projects that nobody really cares about? or just to stamp a 'yes go on with that PMC but play nicely' to all those who come with a proposal? I don't understand: what is this incubator doing anyway if all the projects are incubated somewhere else? 1 - votes the projects into Apache after check that all the nitty-gritty stuff has been taken care of 2 - serves as a central place to store incubation history and information 3 - serves as a place where to discuss incubation per se, where shepherds, sponsors and project members can confront 4 - serves as a place where to incubate TLP In essence it's a box, not a club where only the greatest can rule . hmmm, if the above is true, why are you judging the incubation operation of another PMC? on what basis? which, IMO, should be redesigned since it clearly creates more beaurocracy than any good] The problem is that it has *not* created yet any beaurocracy. Oh god, don't you realize that it could be that people don't complain to you because you can get so defensive so fast? I hear enough complaints here, thank you. Ok, great. I'll shut up then. People complain about lack of rules, not because there are too many. Really? who did? Everyone. For example Berin Lautenbach and Ted Leung, but you can put basically anyone that asked us for something. Fair enough. We have only one true rule, that we should vote for a project to be accepted fully at Apache, based on a simple checklist. If this is beaurocracy... Ok, let's change t
Re: [PROPOSAL] PMC Vote to incubate Directory Project
Stefano Mazzocchi wrote: On Monday, Sep 22, 2003, at 09:04 Europe/Rome, Nicola Ken Barozzi wrote: ... It has made issues that without it are simply ignored finally evident. As for other issues, they are usually created by people complaining here and not helping out. I'm trying to help out indicating what I dislike about the process. If this is not appreciated, tell me and I'll shut up. Which process? You seem to fight against a process that does not exist, that is only what you imagine. The process you outline is what we all strive for. There is nothing in this PMC and in the really small rules in our STATUS file that prevents you from fulfilling it. I'd be more happy if instead of ranting you would come in with us and be part of it. I vote for the second. Then add some explanation to your vote please, because I don't see how the Incubator has created issues to Lenya. Call me defensive, but I have never seen a project that has been under fire from flamers like this one in all my life. For me, the disturbing thing is the "we know what to do, you don't" attitude. You feel excluded? Well, you do not need to be. Ask to become part of this PMC, and you'll be surprised. Nobody told you that you don't know what to do. Heck, you guided me through Apache and taught me all I know; you should really not think that I feel I know more than you do, it's plain silly. Instead, you are the one that keeps questioning the components of this PMC from being able to incubate, having no proven track record. Somebody has to do it, and if others are not willing, we'll have to do. Come on, do you have to keep asking us to open a door that is open wide? Remove that and you'll see the flames disappear in seconds. I cannot remove what has never been. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Another cut at roles and responsibilities
Peoples, I have taken Stephen's page and attempted to integrate my understanding of the concept of a Sponsoring Entity (e.g. XML project in the case of XMLBeans). This is all based on what I have seen during the course of the XMLBeans incubation startup. Apologies for term *Sponsoring Entity*. I couldn't come up with anything better on the spot. I have also very much de-emphasised the role of the sponsor. From what I've seen, the key role post acceptance is the Shepherd. If the Sponsor wishes to become the shepherd, then they retain the responsibilities, otherwise they can move onto other things, having convinced an appropriate body in the ASF to take on the candidate. Peoples - I am very happy to back these changes out, but I wanted to put continue the approach of having something concrete in place to help the discussion along. Cheers, Berin Stephen McConnell wrote: I have prepared a new page based on the oringal content that Berin prepared. Here is a summary of the things I changed/added: 1. cleanup of the descriptions and terminaolgy (product/project/sub-project) etc. 2. simplification of the description of the pmc (complemented with addition process content) 3. sharpending the description of the scope of responsibility of the PMC chair 4. introduction of the notion of sponsor 5. harmonize content so that sponsor and shephard are complementary 6. introductory description of the process end-to-end 7. breakout of all roles in an equivalent format with identified responsibilities http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings I would appreciated any feedback concerning content and suggestions on how we could proceed with migrating this to a structured set of policies and procedures that could be adopted by the Incubator PMC. Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Berin Lautenbach wrote: ... I have also very much de-emphasised the role of the sponsor. From what I've seen, the key role post acceptance is the Shepherd. If the Sponsor wishes to become the shepherd, then they retain the responsibilities, otherwise they can move onto other things, having convinced an appropriate body in the ASF to take on the candidate. Hmmm, I don't like the idea that sponsors can simply walk away in incubation. It makes it easy to push for an idea and let others do the hard work. If someone doesn't want to do the work, then in my book he's not a sponsor, as a sponsor gives something to get something, and in this case he's just advocating. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
Stefano Mazzocchi wrote: > > 1) how do people get on the incubation PMC? any committer? only > members? members and officials? everybody committer that previously has > a record of helping incubation? just curious of what feelings are. another good question. i agree with roy that anyone with an official role vis-a-vis a current podling should be on the pmc. > 2) isn't the incubation more an oversight group, a task force, then a > project? you seem to be harking back to 'projects produce code'. i disagree with that perspective; 'projects produce goodness for the asf' might be closer. in this case, the incubator would be producing good asf citizens (projects and communities). > 3) shouldn't the sponsor PMC provide periodical updates on the status > to the incubator? let's make sure we're agreed on terminology here. so far, the terms 'sponsor', 'shepherd', and 'mentor' have been conflated. my view is that the latter two are the same and refer to a single individual, and that a sponsor is either that same person or the asf project that has said 'the podling has a home here when it's done.' i am very much *not* in favour of a *pmc* fulfilling any other role than that. the most significant drawback is the apathy effect and lack of clear delineation of responsibility. 'someone else' will handle doing whatever needs to be done. no, thank you. my view is that a podling will have a single individual from the asf who has committed to bringing it through incubation. this person is the one who nags the podling about filling out clas, doing the licence and copyright thing and such, and advises the podling community about how to adapt to the asf way of doing things (meritocracy, voting, et cetera). this individual also has the responsibility of keeping the incubator pmc informed of progress and issues, and likewise is the official conduit for bringing concerns and suggestions from the incubator to the podling community. what's the role of the incubator pmc in this? at the least, it's a set of passionate asf people who are essentially in agreement about what makes something a genuine 'apache'-style project, who review the reports of the mentors and make suggestions and eventually vote on whether the podling has become self-sustaining in the 'apache way' of doing things. in a more perfect world, the pmc members will involve themselve more deeply than that in at least some of the podlings, so they can observe at first hand, possibly providing guidance at first hand (though preferably through the mentor). what's the role of a 'sponsoring pmc' in this? solely as an observer until the podling graduates. what's the role of a sponsoring project in this? to help out, to whatever degree they severally desire, in educating their soon-to-be neighbours in specific details about the sponsoring project itself. and that's what my thoughts are at this point in time. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
Stefano Mazzocchi wrote: ... Noel, if you don't mind I'll also answer this. I agree with the principle (otherwise we get back to complete PMC incubation independence and things blow up) but there are a few things worth asking: 1) how do people get on the incubation PMC? any committer? only members? members and officials? everybody committer that previously has a record of helping incubation? just curious of what feelings are. After being voted in by existing Incubator members, as for every Apache Project. Basically it's about people willing to do stuff. 2) isn't the incubation more an oversight group, a task force, then a project? Conceptually, yes. It's a "project" because it gives an easy legal framework (like in the rest of the Apache projects) and is made to outlive "original contributors". I don't see the problem in the name, where I work everything that "does" something is a project. 3) shouldn't the sponsor PMC provide periodical updates on the status to the incubator? This has been proposed, and I favor it. I know the above sounds utterly beaurocratic, but I can't think of anything simpler than this. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Jochen Wiedmann wrote: > > Thanks, understood. In that case, I'd hold my argument, that the incubated > project requires the ability for Releases in order to attract external users > and build a community. i disagree. the lack of a release snapshot doesn't seem to interfere with sourceforge projects attracting people, and i don't see that it would be any different here. i think the point is that a podling is *not* part of the asf, and is therefore not entitled to distribute something with the asf's name on it. if the podling graduates, i don't see any bar to whatever packages were built during incubation being retitled as asf ones. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] PMC Vote to incubate Directory Project
> That isn't the question I was asking. If someone else comes to Apache > and says they want to start an LDAP server project using, for example, > the Netscape code base (C++, I think) and another comes in wanting to > establish a Python library for builtin calls to LDAP, should the ASF > direct those projects to this same group or to their own projects? Let's work with an example. If PerlLDAP were a candidate for incubation and joined the incubator it would probably exit into a directory subproject. So yes it would become part of the directory project. Another example would be the PADL name server switch module and pam module written in C here: http://www.padl.com They would also go under the directory project. We should be protocol centric and language-agnostic. BTW, I think the netscape stuff is C, it branched of the original UMich server written in C by Tim Howes et. al. > I have no problem with protocol-centric projects, and no problem with > language-centric projects, but I do have a problem with protocol-centric > projects that assume one implementation language is "best". Those types > of projects create failure conditions that are very messy from the > board's POV. So, if the project is going to be language-agnostic, then > I want that written into the charter and growth anticipated. If not, > then I want that written into the charter and a different name given > to this project. Doesn't that make sense? Different implementations will have different advantages. No one implementation surpasses another and I apologize if the proposal came off that way. Right now a Java based server is what we have. Plus people are excited that Java has grown up enough to handle the endeavor finally ;-). Let's go ahead and put the language-agnostic clause into the charter and work together to make the new project a one stop shop for anything solely oriented with a directory. Let me know if that clarifies some of your concerns. Sincerely, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
On Monday, Sep 22, 2003, at 14:15 Europe/Rome, Nicola Ken Barozzi wrote: You feel excluded? Well, you do not need to be. Ask to become part of this PMC, and you'll be surprised. I don't feel excluded, Nicola. I feel unable to get my points across. Admittedly, I could have used a more diplomatic tone to start with, but I thought that since I'm dealing with people that I know very well and highly respect, that wouldn't be needed. I was wrong and I'm sorry for that. But I guess that incubation practices are one of those things that you learn by going thru them and not because somebody tells you their experience and their criticism (which more and more appears unjustified, the more disconnection there is between the different visions and experiences) But since I might be all wrong, and I feel like I'm wasting time (mine and yours), I stop here. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
On Mon, 22 Sep 2003 08:39:20 -0400 (Subject: Re: roles and responsibilities) Rodent of Unusual Size <[EMAIL PROTECTED]> wrote: > > 2) isn't the incubation more an oversight group, a task force, then a > > project? > you seem to be harking back to 'projects produce code'. i disagree with > that perspective; 'projects produce goodness for the asf' might be closer. > in this case, the incubator would be producing good asf citizens (projects > and communities). Agreed with Ken. If we (ahh... you, ASF members! :-) would think of the creation of "i18n.apache.org" or "document.apache.org", (i18n TLP / Documentation TLP), 'projects produce code' principle could be an obstacle (spoiling). For example, "internationalization" project can spring a good and really healthy community, I guess. Unfortunately, I am not an ASF member, so I would not be able to "incubate" such a top level project, needless to say :) -- However, stop worrying about it. I have already lost the itch of the creation of i18n/doc projects. Life is not too long, goes like an arrow. I have many things to be done. Discussions here and in infrastructure@ in these days gave me really a great insights on the Apache Software Foundation to me. Thank you all! (And really sorry for the rant) Again, thank you all! Regards, __ Tetsuya <[EMAIL PROTECTED]> __ P.S. 1,000th anniversary posts to apache.org MLs :) .. participation style would be changed as a matter of course. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: roles and responsibilities
Nicola Ken Barozzi wrote: > Noel, if you don't mind I'll also answer this. Someone asking my permission to respond to an open comment on a public list actually makes me a bit uncomfortable. Makes me wonder why anyone they felt the need to ask. The fact that you are a member of the overseeing PMC doubly so. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Rodent of Unusual Size wrote: i disagree. the lack of a release snapshot doesn't seem to interfere with sourceforge projects attracting people, and i don't see that it would be any different here. The lack of release snapshots on sf.net is (IMO) the best indicator, that the project isn't maintained well or even not at all. At least I cannot remember a single case of a project without published files, where the CVS did contain something useful. i think the point is that a podling is *not* part of the asf, and is therefore not entitled to distribute something with the asf's name on it. if the podling graduates, i don't see any bar to whatever packages were built during incubation being retitled as asf ones. There are several things I do not understand here. First of all, IMO, by accepting a project for incubation, it is part of the ASF. For whatever other reason am I expected to sign a contribution agreement at the beginning? From your point of view, it would be suffigient to sign when the project exits incubation. Next, assuming that my point is wrong, I would assume that incubation is targetted to be a process of transition. Which means, that a project is at some point perhaps not completely ready, but with a sufficient progress. What good does it, to insist in the "final 20 percent" or whatever you are missing? Finally, you should not forget that incubated projects are frequently mature and well maintained. What good does it, to forbid them to publish, for example, a release that is "identical to the last public release, except that the package names are being updated". IMO this is the least what users can expect to guide them in their own transition as soon as possible. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] PMC Vote to incubate Directory Project
> I have no problem with protocol-centric projects, and no problem with > language-centric projects, but I do have a problem with protocol-centric > projects that assume one implementation language is "best". OK, I've seen enough language wars to understand your a priori concern. Mind you, not everyone who uses Java is a language zealot. > So, if the project is going to be language-agnostic, then > I want that written into the charter and growth anticipated. We tried to anticipate this issue when preparing the proposal, and did intentionally focus on the problem domain, rather than the platform, excepting where the platform permitted *additional* synergies with other projects (code sharing and embedding with related Java projects). Apparently we did not do it sufficiently, but the intent is there, as is the willingness to resolve the matter. > If someone else comes to Apache and says they want to start > an LDAP server project using, for example, the Netscape code > base (C++, I think) and another comes in wanting to establish > a Python library for builtin calls to LDAP, should the ASF > direct those projects to this same group or to their own projects? Aren't Xerces-[C|J] and Xalan-[J|C] under the XML banner? Not being a member of those projects, I'd appreciate hearing the experiences of those who are, and from their PMC. Yes, I can see the potential of possibly growing too big for proper oversight, and needing to split out, leaving the language-agnostic items in the language-agnostic location. But, in a sense, haven't those things already happened, as projects were refactored from Jakarta to XML to elsewhere (e.g., their own TLP or Web Services)? On the other hand, when(if) matured to TLP status, I'd imagine that there would be some infrastructure related to particular implementations, and parts related to all sorts of portable issues, such as schema, RFCs, ASN, protocol testing, etc., that are common ground. And, quite honestly, I do not see that type of collaboration happening if the semantic domain isn't given a home. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Kannel discussion invitation
> no good, alas; i'll be on the road driving to another town at that point. > i *should* be back within a couple of hours, though. :-/ Ken, please find the #kannel IRC channel log of the debate at http://www.kannel.org/irc-sessions/ from last friday and today. People have raised a couple of questions in terms how "independancy" of a project is impacted when moving to ASF. You you or other from the incubation project comment on this please. Also, we'd like to make an IRC session with a couple of you Apache guys online, so Kannel developer's can directly ask. How should we proceed in having an appointment fixed?! Stipe [EMAIL PROTECTED] --- Wapme Systems AG Vogelsanger Weg 80 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
> I have also very much de-emphasised the role of the sponsor. From what > I've seen, the key role post acceptance is the Shepherd. If the Sponsor > wishes to become the shepherd, then they retain the responsibilities I disagree. One problem is that the terms seem to be getting overloaded. But whomever is the Sponsor that brings the project to the Incubator, ought to be willing to take on the responsibilities. The Incubator isn't a daycare center to drop off your kid. And the Incubator PMC is there to help, to guide, and to assist, but also to make sure that the project doesn't leave the Incubator until it is ready to be a project of the Apache Foundation. A warning sign to the PMC ought to be lack of support from the Sponsor. If necessary, a "foster Sponsor" could be located, if there is one willing. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Berin: Have just gone thought the changes. I like the notion of the "Sponsoring Entity" at this addresses the entity into which a prodling is destined. Perhaps we could change the name to "Parent". I.e. if a cadidate aims to be top-level, its parent would be the Board. If the project aims to enter into a project such as Avalon, the parent would be the Avalon PMC. There are two areas of concern I have in the current text. 1. Entities (Board, Parent, Incubator PMC) should not assigned actional responsibilities - only decision responsibility. Actional reposibility should be assigned to roles that are represented by accountable individuals. There were a couple of places in the document that needed to be tightened up in this respect. 2. Shepherd versus Sponsor. In you text you have a sheperd assigned by the Parent (Sponsoring Entity) combined with a shift of responsibilities from Sponsor to Shepherd. I'm not keen on this. I think that the Sheperd should be assigned by the Incubator PMC irrespective of the Parent and that the Shepherd role should be maintained as monitoring, operational support, validation and assessment. The Sponsor should not be a walk-away position - instead I would propose a much strong relationship. A Sponsor should expect to stay with a project throught the incubation and if for any reasons the Sponsor cannot do this, the the Sponsor should notify the respective entities and facilitate the introduction of a replacement Sponsor. My impression is that we are actually aiming towards the same thing but that what you thinking of as Sheperd is what I'm thinking of as Sponsor. There are a few other little things but I thought it best to get these two items clarified first. Stephen. Berin Lautenbach wrote: Peoples, I have taken Stephen's page and attempted to integrate my understanding of the concept of a Sponsoring Entity (e.g. XML project in the case of XMLBeans). This is all based on what I have seen during the course of the XMLBeans incubation startup. Apologies for term *Sponsoring Entity*. I couldn't come up with anything better on the spot. I have also very much de-emphasised the role of the sponsor. From what I've seen, the key role post acceptance is the Shepherd. If the Sponsor wishes to become the shepherd, then they retain the responsibilities, otherwise they can move onto other things, having convinced an appropriate body in the ASF to take on the candidate. Peoples - I am very happy to back these changes out, but I wanted to put continue the approach of having something concrete in place to help the discussion along. Cheers, Berin Stephen McConnell wrote: I have prepared a new page based on the oringal content that Berin prepared. Here is a summary of the things I changed/added: 1. cleanup of the descriptions and terminaolgy (product/project/sub-project) etc. 2. simplification of the description of the pmc (complemented with addition process content) 3. sharpending the description of the scope of responsibility of the PMC chair 4. introduction of the notion of sponsor 5. harmonize content so that sponsor and shephard are complementary 6. introductory description of the process end-to-end 7. breakout of all roles in an equivalent format with identified responsibilities http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings I would appreciated any feedback concerning content and suggestions on how we could proceed with migrating this to a structured set of policies and procedures that could be adopted by the Incubator PMC. Cheers, Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Jochen Wiedmann wrote: > >> i think the point is that a podling is *not* part of the >> asf, and is therefore not entitled to distribute something >> with the asf's name on it. if the podling graduates, i don't >> see any bar to whatever packages were built during incubation >> being retitled as asf ones. > > There are several things I do not understand here. First of all, IMO, by > accepting a project for incubation, it is part of the ASF. no, it is a *candidate to become* part of the asf. if it fails to exit the incubator, for whatever reason, it doesn't wander off into the sunset bearing the asf name with it. :-) > For whatever > other reason am I expected to sign a contribution agreement at the > beginning? From your point of view, it would be suffigient to sign when > the project exits incubation. because the code is being stored on asf infrastructure, among other things. > Next, assuming that my point is wrong, I would assume that incubation is > targetted to be a process of transition. Which means, that a project is at > some point perhaps not completely ready, but with a sufficient progress. > What good does it, to insist in the "final 20 percent" or whatever you are > missing? i'm having trouble parsing that, so i can't respond intelligently. can you rephrase? > Finally, you should not forget that incubated projects are frequently mature > and well maintained. What good does it, to forbid them to publish, for > example, a release that is "identical to the last public release, except > that the package names are being updated". IMO this is the least what users > can expect to guide them in their own transition as soon as possible. as far as i'm concerned, they can publish whatever they want -- but they can't call it an asf release. i don't think any harm would be done if a ga release were made during incubation, labeled with the pre-incubation name (i.e., not mentioning the asf at all), but i'd have to consider it more to feel sure about that. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Getting the distribution onto a download site somewhere ...
Jochen, A project is accepted into the Incubator on the hopes that it WILL become an ASF project. However, it still needs to meet certain critera (the exit criteria). Those criteria should include having a healthy Community, which helps to ensure its long term survival; and having all legal issues resolved, which permits it to be legally released under the ASF copyright. If those criteria have not been met, I do believe that the project should not be permitted to release a package with the imprimatur (Offical Approval) of the ASF. I would sooner permit a project to release something with known (and documented) bugs than to release something with legal entanglements. I don't care how mature the code. Software has bugs. Entanglements have lawyers. Those are the issues that come to my mind. The Incubator PMC may have others. Personally, I think that snapshots marked as test builds and perhaps also carrying a file listing the project's incubation status, would be OK. Again, the Incubator PMC may share or differ on that view. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
> I like the notion of the "Sponsoring Entity" at this addresses > the entity into which a prodling is destined. Apparently, the part that "destination is an exit criteria" hasn't resonated with you. Yes, it is helpful to have an idea up front, but not in the sense where you took it, specifically: > Perhaps we could change the name to "Parent". > if a cadidate aims to be top-level, its parent would be the Board. IMO, the Board's involvement should not be required for an unproven podling. That is the purpose of the Incubator PMC. The Sponsor would be the ASF Member/Officer who has sponsored the project. Depending upon how many other co-sponsors had been lined up, the Incubator PMC might be more or less active in incubation to help fledge the new podling. On the other hand ... > If the project aims to enter into a project such as Avalon, the > parent would be the Avalon PMC. Then there should be no lack of people who ought to take an interest in welcoming the hopefully-soon-to-be member of their TLP. If that is NOT the case, I would consider that a warning sign. > 2. Shepherd versus Sponsor. The names may be interfering with the roles. One is the Incubator PMC representative, who is most likely going to focus on what criteria needs to be met to allow exit; the other is the person who is going to focus on the positive aspects of Community building and project development, although may be asked as and when necessary by the Incubator PMC to address an incubation criteria issue. > Shepherd role should be maintained as monitoring, > operational support, validation and assessment. That sounds about right, AIUI. > The Sponsor should not be a walk-away position The role seems better viewed as Sponsor/Mentor. One should not be permitted to do the former without being willing to be the latter. The person could delegate tasks, but would still be responsible, and would need to keep on top of whatever tasks were delegated. Ownership of responsibility needs to be clear, and resident in that one person, not groups. To make this concrete, if the James Project wanted to incubate something, then either an ASF Member or Serge, our PMC Chair, would have to be the responsible party. Serge could delegate tasks, but cannot delegate responsibility. Please note: other than the very first item way up top (destination), I don't believe that we are actually disagreeing. Just clarifying. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Okay guys, I get the message. I'll ask XML beans to make a "xmlbeans-is-not-part-of-the-ASF-1.0" release. On 9/22/2003 10:09 AM, Rodent of Unusual Size wrote: Jochen Wiedmann wrote: i think the point is that a podling is *not* part of the asf, and is therefore not entitled to distribute something with the asf's name on it. if the podling graduates, i don't see any bar to whatever packages were built during incubation being retitled as asf ones. There are several things I do not understand here. First of all, IMO, by accepting a project for incubation, it is part of the ASF. no, it is a *candidate to become* part of the asf. if it fails to exit the incubator, for whatever reason, it doesn't wander off into the sunset bearing the asf name with it. :-) For whatever other reason am I expected to sign a contribution agreement at the beginning? From your point of view, it would be suffigient to sign when the project exits incubation. because the code is being stored on asf infrastructure, among other things. Next, assuming that my point is wrong, I would assume that incubation is targetted to be a process of transition. Which means, that a project is at some point perhaps not completely ready, but with a sufficient progress. What good does it, to insist in the "final 20 percent" or whatever you are missing? i'm having trouble parsing that, so i can't respond intelligently. can you rephrase? Finally, you should not forget that incubated projects are frequently mature and well maintained. What good does it, to forbid them to publish, for example, a release that is "identical to the last public release, except that the package names are being updated". IMO this is the least what users can expect to guide them in their own transition as soon as possible. as far as i'm concerned, they can publish whatever they want -- but they can't call it an asf release. i don't think any harm would be done if a ga release were made during incubation, labeled with the pre-incubation name (i.e., not mentioning the asf at all), but i'd have to consider it more to feel sure about that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
On 9/21/2003 10:59 PM, Noel J. Bergman wrote: Ted Leung wrote: Minimum size is not enough here. There also needs to be a diversity requirement. For example XMLBeans must have no more than 50% of its committers from a single organization. Good exit criteria. You're right, of course -- going too fast. Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
On 9/22/2003 5:39 AM, Rodent of Unusual Size wrote: Stefano Mazzocchi wrote: 1) how do people get on the incubation PMC? any committer? only members? members and officials? everybody committer that previously has a record of helping incubation? just curious of what feelings are. another good question. i agree with roy that anyone with an official role vis-a-vis a current podling should be on the pmc. +1 3) shouldn't the sponsor PMC provide periodical updates on the status to the incubator? let's make sure we're agreed on terminology here. so far, the terms 'sponsor', 'shepherd', and 'mentor' have been conflated. my view is that the latter two are the same and refer to a single individual, and that a sponsor is either that same person or the asf project that has said 'the podling has a home here when it's done.' +1. I don't think that we need have multiple people fufill all these roles. If the sponsor/shepherd/mentor is going to be a member of the incubator PMC (see 1 above), then they ought to be trusted to follow the incubator guidlines (once they exist). Do we really need this much check and balance? i am very much *not* in favour of a *pmc* fulfilling any other role than that. the most significant drawback is the apathy effect and lack of clear delineation of responsibility. 'someone else' will handle doing whatever needs to be done. no, thank you. my view is that a podling will have a single individual from the asf who has committed to bringing it through incubation. this person is the one who nags the podling about filling out clas, doing the licence and copyright thing and such, and advises the podling community about how to adapt to the asf way of doing things (meritocracy, voting, et cetera). this individual also has the responsibility of keeping the incubator pmc informed of progress and issues, and likewise is the official conduit for bringing concerns and suggestions from the incubator to the podling community. what's the role of the incubator pmc in this? at the least, it's a set of passionate asf people who are essentially in agreement about what makes something a genuine 'apache'-style project, who review the reports of the mentors and make suggestions and eventually vote on whether the podling has become self-sustaining in the 'apache way' of doing things. in a more perfect world, the pmc members will involve themselve more deeply than that in at least some of the podlings, so they can observe at first hand, possibly providing guidance at first hand (though preferably through the mentor). what's the role of a 'sponsoring pmc' in this? solely as an observer until the podling graduates. what's the role of a sponsoring project in this? to help out, to whatever degree they severally desire, in educating their soon-to-be neighbours in specific details about the sponsoring project itself. and that's what my thoughts are at this point in tim +1 to all of this. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
On 9/22/2003 5:23 AM, Nicola Ken Barozzi wrote: Berin Lautenbach wrote: ... I have also very much de-emphasised the role of the sponsor. From what I've seen, the key role post acceptance is the Shepherd. If the Sponsor wishes to become the shepherd, then they retain the responsibilities, otherwise they can move onto other things, having convinced an appropriate body in the ASF to take on the candidate. Hmmm, I don't like the idea that sponsors can simply walk away in incubation. It makes it easy to push for an idea and let others do the hard work. +1 If someone doesn't want to do the work, then in my book he's not a sponsor, as a sponsor gives something to get something, and in this case he's just advocating. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Exit Criteria
I don't know if we want to tackle this at the same time as Steven's document on entering the incubator, but at the moment I"m more focused on how to get podlings out of the incubator rather than getting them in. A while ago I proposed some exit criteria for XML beans -- I haven't pushed them because we were waiting to get the CLA situation straightened out. Now that that's done and the code is in CVS, I want to revisit these. I've also added some items that Roy added to the XMLBeans STATUS file in the incubator CVS. There are a few XML beans specific items in this list, but I'd like to propose that we start a discussion of exit criteria based on this list. Legal (these should be done before code comes into the incubator, but I'm including them for completeness) All code ASL'ed No non ASL or ASL compatbile dependencies in the code base License grant complate CLAs on file. Check of project name for trademark issues Meritocracy / Community Demonstrate an active and diverse development community No single organization supplies more than 50% of the active committers (must be at least 3 independent committers) The above implies that new committers are admitted according to ASF practices ASF style voting has been adopted and is standard practice Demonstrate ability to tolerate and resolve conflict within the community. Release plans are developed and excuted in public by the community. (requriment on minimum number of such releases?)Engagement by the XMLbeans community with the XML PMC and other ASF sub communities, particularly infrastructure@ (this reflects my personal bias that projects should pay an infrastructure "tax"). Incubator PMC has voted for graduation XML PMC has voted for final acceptance Alignment / Synergy Replacement of LGPL Piccolo parser with Xerces. Develop synergistic relationship with JaxMe in WS-Commons, also perhaps with Axis. Use of any relevant Jakarta subprojects. Infrastructure project CVS has been created project mailing lists have been created project mailing lists are being archived project bugzilla has been created. project has a subsite of xml.apache.org project complies with ASF mirroring guidlines project is integrated with Gump XMLBeans developers tied into ASF PGP web of trust Releases are PGP signed by a member of the community Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Getting the distribution onto a download site somewhere ...
OK, based on everything I've read from this and a few of the other threads on this list, which I've just caught up to (I picked a bad weekend to attend a wedding that took me off email ;-), I am going to propose to the other XMLBeans folks that we do the following: 1. Create a build of a cvs snapshot and name the file: "incubated-xmlbeans-1.0.0.zip" (Ted's more serious suggestion than the one below, although that one made me smile more). 2. Edit the README.txt file to include a paragraph explaining that this build is a snapshot of an incubated project that is not yet officially endorsed by the ASF. 3. Add a note to the XMLBeans project web site making sure the incubation status is clear. Unless there are other suggestions, I'm going to assume this is a reasonable process to follow for an incubated project, which needs to make binaries available in order to help build a community. Cliff On Monday, September 22, 2003 11:40 AM, Ted Leung wrote: > Okay guys, I get the message. I'll ask XML beans to make a > "xmlbeans-is-not-part-of-the-ASF-1.0" release. > > On 9/22/2003 10:09 AM, Rodent of Unusual Size wrote: > >> Jochen Wiedmann wrote: >> >> i think the point is that a podling is *not* part of the asf, and is therefore not entitled to distribute something with the asf's name on it. if the podling graduates, i don't see any bar to whatever packages were built during incubation being retitled as asf ones. >>> There are several things I do not understand here. First of all, >>> IMO, by accepting a project for incubation, it is part of the ASF. >>> >>> >> >> no, it is a *candidate to become* part of the asf. if it fails to >> exit the incubator, for whatever reason, it doesn't wander off into >> the sunset bearing the asf name with it. :-) >> >> >> >>> For whatever >>> other reason am I expected to sign a contribution agreement at the >>> beginning? From your point of view, it would be suffigient to sign >>> when the project exits incubation. >>> >>> >> >> because the code is being stored on asf infrastructure, among other >> things. >> >> >> >>> Next, assuming that my point is wrong, I would assume that >>> incubation is targetted to be a process of transition. Which means, >>> that a project is at some point perhaps not completely ready, but >>> with a sufficient progress. What good does it, to insist in the >>> "final 20 percent" or whatever you are missing? >>> >>> >> >> i'm having trouble parsing that, so i can't respond intelligently. >> can you rephrase? >> >> >> >>> Finally, you should not forget that incubated projects are >>> frequently mature and well maintained. What good does it, to forbid >>> them to publish, for example, a release that is "identical to the >>> last public release, except that the package names are being >>> updated". IMO this is the least what users can expect to guide them >>> in their own transition as soon as possible. >>> >>> >> >> as far as i'm concerned, they can publish whatever they want -- but >> they can't call it an asf release. i don't think any harm would be >> done if a ga release were made during incubation, labeled with the >> pre-incubation name (i.e., not mentioning the asf at all), but i'd >> have to consider it more to feel sure about that. >> >> > > > - > 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: [PROPOSAL] PMC Vote to incubate Directory Project
See comments inline Noel J. Bergman wrote: I have no problem with protocol-centric projects, and no problem with language-centric projects, but I do have a problem with protocol-centric projects that assume one implementation language is "best". OK, I've seen enough language wars to understand your a priori concern. Mind you, not everyone who uses Java is a language zealot. So, if the project is going to be language-agnostic, then I want that written into the charter and growth anticipated. We tried to anticipate this issue when preparing the proposal, and did intentionally focus on the problem domain, rather than the platform, excepting where the platform permitted *additional* synergies with other projects (code sharing and embedding with related Java projects). Apparently we did not do it sufficiently, but the intent is there, as is the willingness to resolve the matter. The dodgy bit is defining what is core and what is not. See below. If someone else comes to Apache and says they want to start an LDAP server project using, for example, the Netscape code base (C++, I think) and another comes in wanting to establish a Python library for builtin calls to LDAP, should the ASF direct those projects to this same group or to their own projects? Aren't Xerces-[C|J] and Xalan-[J|C] under the XML banner? Not being a member of those projects, I'd appreciate hearing the experiences of those who are, and from their PMC. Yes, I can see the potential of possibly growing too big for proper oversight, and needing to split out, leaving the language-agnostic items in the language-agnostic location. But, in a sense, haven't those things already happened, as projects were refactored from Jakarta to XML to elsewhere (e.g., their own TLP or Web Services)? On the other hand, when(if) matured to TLP status, I'd imagine that there would be some infrastructure related to particular implementations, and parts related to all sorts of portable issues, such as schema, RFCs, ASN, protocol testing, etc., that are common ground. And, quite honestly, I do not see that type of collaboration happening if the semantic domain isn't given a home. I don't think that we have really answered Roy's question, but digging into what exactly we mean by the "semantic domain" is a step in the right direction. The "easy" answer is that the semantic domain equals LDAP-exposed directory services, which is fully specification-driven, platform- and language independent, etc; but the project already includes more than that. We should ask ourselves if we expect to provide a home for extended Perl, C or whatever APIs, naming services for those languages, etc. If the answer is "yes", then fine, we can all agree and move forward. If the answer is no, however, I agree with Roy that we should acknowledge the scope limitation. FWIW, my opinion is that standards-based Directory + Identity services could make up a natural "semantic domain" (actually more natural than "XML") and we should focus on defining this domain, rather than what languages or language-specific extensions will be supported (much as that diminishes the importance of JNDI and the extended Java APIs that I am personally looking forward to ;-)). Then we need to make the explicit commitment that the core solutions implemented and the eventual TLP will support *all* languages and *all* computing platforms. Can we all agree to this? Phil --- Noel - 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]
Fwd: proposal: eliminate unix group incubator
There have been no objections, so I would appreciate it if we could get rid of the incubator unix group in favor of apcvs for everything except the incubator-core repository: ssh cvs.apache.org cd /home/cvs chgrp -R apcvs incubator incubator-altrmi incubator-ftpserver \ incubator-geronimo incubator-site find incubator-site -type f -print | xargs chmod 444 cd /www/incubator.apache.org chgrp -R apcvs . find . -type f -print | xargs chmod 664 [the find is needed because people committed with wrong permissions]. The reason for doing this is to cut down on the number of people needing to wait for root group changes as they shift in and out of incubation status. Only the incubator PMC needs to be in the incubator unix group. Roy Begin forwarded message: From: Roy T. Fielding <[EMAIL PROTECTED]> Date: Fri Sep 12, 2003 5:17:20 PM America/Los_Angeles To: [EMAIL PROTECTED] Subject: proposal: eliminate unix group incubator I propose that we ask the infrastructure peeps to eliminate the incubator unix group and make our stuff accessible to everyone under apcvs (that means all committers). People will still need avail access, but it reduces by one the number of universal groups (limited to 15 on freebsd) and makes it easier for us to encourage people to update their podling STATUS. Any objections? Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
FWIW, my opinion is that standards-based Directory + Identity services could make up a natural "semantic domain" (actually more natural than "XML") and we should focus on defining this domain, rather than what languages or language-specific extensions will be supported (much as that diminishes the importance of JNDI and the extended Java APIs that I am personally looking forward to ;-)). Then we need to make the explicit commitment that the core solutions implemented and the eventual TLP will support *all* languages and *all* computing platforms. Can we all agree to this? Clarification: the project only needs to agree to welcome volunteers who wish to work on that code within the project. You don't need to support the code -- only the community, so that folks who come along wanting to support their own languages can do so. There is no need to support languages that have no volunteers. Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
Phil Steitz wrote: See comments inline Noel J. Bergman wrote: I have no problem with protocol-centric projects, and no problem with language-centric projects, but I do have a problem with protocol-centric projects that assume one implementation language is "best". OK, I've seen enough language wars to understand your a priori concern. Mind you, not everyone who uses Java is a language zealot. So, if the project is going to be language-agnostic, then I want that written into the charter and growth anticipated. We tried to anticipate this issue when preparing the proposal, and did intentionally focus on the problem domain, rather than the platform, excepting where the platform permitted *additional* synergies with other projects (code sharing and embedding with related Java projects). Apparently we did not do it sufficiently, but the intent is there, as is the willingness to resolve the matter. The dodgy bit is defining what is core and what is not. See below. If someone else comes to Apache and says they want to start an LDAP server project using, for example, the Netscape code base (C++, I think) and another comes in wanting to establish a Python library for builtin calls to LDAP, should the ASF direct those projects to this same group or to their own projects? Aren't Xerces-[C|J] and Xalan-[J|C] under the XML banner? Not being a member of those projects, I'd appreciate hearing the experiences of those who are, and from their PMC. Yes, I can see the potential of possibly growing too big for proper oversight, and needing to split out, leaving the language-agnostic items in the language-agnostic location. But, in a sense, haven't those things already happened, as projects were refactored from Jakarta to XML to elsewhere (e.g., their own TLP or Web Services)? On the other hand, when(if) matured to TLP status, I'd imagine that there would be some infrastructure related to particular implementations, and parts related to all sorts of portable issues, such as schema, RFCs, ASN, protocol testing, etc., that are common ground. And, quite honestly, I do not see that type of collaboration happening if the semantic domain isn't given a home. I don't think that we have really answered Roy's question, but digging into what exactly we mean by the "semantic domain" is a step in the right direction. The "easy" answer is that the semantic domain equals LDAP-exposed directory services, which is fully specification-driven, platform- and language independent, etc; but the project already includes more than that. We should ask ourselves if we expect to provide a home for extended Perl, C or whatever APIs, naming services for those languages, etc. If the answer is "yes", then fine, we can all agree and move forward. If the answer is no, however, I agree with Roy that we should acknowledge the scope limitation. FWIW, my opinion is that standards-based Directory + Identity services could make up a natural "semantic domain" (actually more natural than "XML") and we should focus on defining this domain, rather than what languages or language-specific extensions will be supported (much as that diminishes the importance of JNDI and the extended Java APIs that I am personally looking forward to ;-)). Then we need to make the explicit commitment that the core solutions implemented and the eventual TLP will support *all* languages and *all* computing platforms. Can we all agree to this? I would agree that the *scope* of the eventual TLP is multi-platform and multi-language. The words "will support" are a subject of inevitable community development and contributions. Stephen. Phil --- Noel - 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] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: roles and responsibilities
> > let's make sure we're agreed on terminology here. so far, the terms > > 'sponsor', 'shepherd', and 'mentor' have been conflated. my view is > > that the latter two are the same and refer to a single individual, and > > that a sponsor is either that same person or the asf project that has > >said 'the podling has a home here when it's done.' > +1. I don't think that we need have multiple people fufill all these > roles. If the sponsor/shepherd/mentor is going to be a member of the > incubator PMC (see 1 above), then they ought to be trusted to follow the > incubator guidlines (once they exist). Do we really need this much > check and balance? Seems so, but that's why in my mind I invest the "Sponsor" and "Mentor" role in the same person, and the "Shephard" is the check and balance, to use your term. How much a check and balance depends upon the Sponsor/Mentor. If that person is really doing a great job, the Shephard's job is easier. If the Sponsor/Mentor needs a bit of help, perhaps because of inexperience incubating projects, the Shephard needs to step in a bit more. Incubating the Sponsor/Mentor, if you will. But always providing oversight. That scales better. The Sponsor/Mentor is an interested party in the success of the project. The Shephard is an Incubator PMC member experienced in incubation issues. That separation also matches what I understand from Nicola Ken and others. Ken's comment about the Incubator PMC being composed of "a set of passionate asf people who are essentially in agreement about what makes something a genuine 'apache'-style project" still holds true. I agree with Ken's concern about a PMC being a "Sponsor", but I think I addressed that in earlier comments about a Member or Officer (e.g., the PMC Chair) being the Sponsor, and that one can delegate tasks, but not responsibility. My "tweak" doesn't accept the idea of an "absentee" Sponsor waiting for the podling to grow up. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: proposal: eliminate unix group incubator
> From: Roy T. Fielding [mailto:[EMAIL PROTECTED] > Sent: Monday, September 22, 2003 10:06 PM > There have been no objections, so I would appreciate it if we could > get rid of the incubator unix group in favor of apcvs for everything > except the incubator-core repository: Done. I'll cleanup the incubator unix group to contain only the pmc members shortly. Sander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] PMC Vote to incubate Directory Project
> We should ask ourselves if we expect to provide a home for extended > Perl, C or whatever APIs, naming services for those languages, etc. If > the answer is "yes", then fine, we can all agree and move forward. > my opinion is that standards-based Directory + Identity services > could make up a natural "semantic domain" (actually more natural than > "XML") and we should focus on defining this domain, rather than what > languages or language-specific extensions will be supported (much as > that diminishes the importance of JNDI and the extended Java APIs that I > am personally looking forward to ;-)). Then we need to make the explicit > commitment that the core solutions implemented and the eventual TLP will > support *all* languages and *all* computing platforms. Can we all agree > to this? Yes, with the clarification added by Roy that the project only has to be welcoming and supportive of people who want to work on such things. But I don't believe that you need to feel that it diminishes "the importance of JNDI and the extended Java APIs that I am personally looking forward to ;-))" because *you* (and others) represent such a community to be welcomed and supported within the domain. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
On 9/22/2003 1:27 PM, Noel J. Bergman wrote: +1. I don't think that we need have multiple people fufill all these roles. If the sponsor/shepherd/mentor is going to be a member of the incubator PMC (see 1 above), then they ought to be trusted to follow the incubator guidlines (once they exist). Do we really need this much check and balance? Seems so, but that's why in my mind I invest the "Sponsor" and "Mentor" role in the same person, and the "Shephard" is the check and balance, to use your term. How much a check and balance depends upon the Sponsor/Mentor. If that person is really doing a great job, the Shephard's job is easier. If the Sponsor/Mentor needs a bit of help, perhaps because of inexperience incubating projects, the Shephard needs to step in a bit more. Incubating the Sponsor/Mentor, if you will. But always providing oversight. Okay, I think I see your point -- this is necessary for a sponsoring member who hasn't incubated a project before. So who's my Shepherd? That scales better. The Sponsor/Mentor is an interested party in the success of the project. The Shephard is an Incubator PMC member experienced in incubation issues. That separation also matches what I understand from Nicola Ken and others. Ken's comment about the Incubator PMC being composed of "a set of passionate asf people who are essentially in agreement about what makes something a genuine 'apache'-style project" still holds true. I agree with Ken's concern about a PMC being a "Sponsor", but I think I addressed that in earlier comments about a Member or Officer (e.g., the PMC Chair) being the Sponsor, and that one can delegate tasks, but not responsibility. My "tweak" doesn't accept the idea of an "absentee" Sponsor waiting for the podling to grow up. If a PMC is going to be a "Sponsor", they should cough up a Member to do that work. If a Member from that PMC isn't willing to step up, then they don't have a sponsor. That's what I'm doing for XMLBeans. Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
Noel J. Bergman wrote: We should ask ourselves if we expect to provide a home for extended Perl, C or whatever APIs, naming services for those languages, etc. If the answer is "yes", then fine, we can all agree and move forward. my opinion is that standards-based Directory + Identity services could make up a natural "semantic domain" (actually more natural than "XML") and we should focus on defining this domain, rather than what languages or language-specific extensions will be supported (much as that diminishes the importance of JNDI and the extended Java APIs that I am personally looking forward to ;-)). Then we need to make the explicit commitment that the core solutions implemented and the eventual TLP will support *all* languages and *all* computing platforms. Can we all agree to this? Yes, with the clarification added by Roy that the project only has to be welcoming and supportive of people who want to work on such things. Yes, that's what I meant to say, with the additional commitment that the core server products should not be designed or implemented in such a way as to discourage or make non-Java extensions difficult. As long as we keep things standards-based, that should not be a problem. But I don't believe that you need to feel that it diminishes "the importance of JNDI and the extended Java APIs that I am personally looking forward to ;-))" because *you* (and others) represent such a community to be welcomed and supported within the domain. Thanks. Believe me, "we" feel very welcome here. I just want to make sure that in defining the domain we stay focused on the core services and define and implement them in such a way that non-Java extensions/applications also make sense, given the positive answer above. Phil --- Noel - 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: Another cut at roles and responsibilities
Steve, > From: Stephen McConnell <[EMAIL PROTECTED]> > 1. Entities (Board, Parent, Incubator PMC) should not assigned actional > responsibilities - only decision responsibility. Actional reposibility > should be assigned to roles that are represented by accountable > individuals. There were a couple of places in the document that > needed to be tightened up in this respect. Personally Not sure I fully agree with this, having seen XMLBeans. If the XML Project wants to have the Incubator take on something on its behalf, then there is a two way accountability. I fully believe that the XML Project has to take some accountability for assisting the podling. That accountability (in the case of XMLBeans) is discharged by the Shepherd, who is a member of the XML PMC, but can call on others in the XML project for assistance at any time. Otherwise this is throwing all the responsibility back on a couple of people. To me the whole Apache concept is about community, so lets demonstrate what that means to the podlings. If Ted stops doing his role as Shepherd, then I would see it as the responsibility of the XML project to step in and find someone else. > My impression is that we are actually aiming towards the same thing but > that what you thinking of as Sheperd is what I'm thinking of as > Sponsor. There are a few other little things but I thought it best to > get these two items clarified first. > I think you are correct, that we are heading to the same end, but I think it important to separate the sponsor of the original proposal away from the incubation. There are people who are visionaries. "I can see why this is a great project and why it will be a good fit for Apache". They can help a candidate "sell" a proposal to Apache. Are they necessarily the best person to help a project through Incubation? Not so sure. To me, that's what the very notion of a shepherd is - someone who guards and protects the flock. A shepherd is not necessarily a great sponsor. (Might be, but I believe it's useful to split the two apart.) Cheers, Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: roles and responsibilities
Ted, If I were you, I think that I would subscribe myself to the Incubator PMC mailing list. That way you can see how things are settling in (I would expect that they could use a bit of time to consolidate all of the discussion), and if they say that they're ready, find out whom is going to take responsibility for working with you. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
> From: Rodent of Unusual Size > > 2) isn't the incubation more an oversight group, a task force, then a > > project? > > you seem to be harking back to 'projects produce code'. i disagree with > that perspective; 'projects produce goodness for the asf' might be closer. > in this case, the incubator would be producing good asf citizens (projects > and communities). > But I believe the Incubator should be putting their stamp on something as being goodness. So there is an element of oversite. Doesn't mean it's not a project though. > > 3) shouldn't the sponsor PMC provide periodical updates on the status > > to the incubator? > > let's make sure we're agreed on terminology here. so far, the terms > 'sponsor', 'shepherd', and 'mentor' have been conflated. my view is > that the latter two are the same and refer to a single individual, and > that a sponsor is either that same person or the asf project that has > said 'the podling has a home here when it's done.' > > i am very much *not* in favour of a *pmc* fulfilling any other role than > that. the most significant drawback is the apathy effect and lack of > clear delineation of responsibility. 'someone else' will handle doing > whatever needs to be done. no, thank you. > I *think* I agree that the PMC can't be responsible for a particular action. However I do believe that a PMC/Project (not sure that it matters which) can have overall responsibility that is rested (by incubation requirement) on a single individual. I.e. the PMC/Project nominates a person who will act on their behalf. If that person fails to fulfill the duty, then the sponsoring PMC must either replace them or the Incubator shuts down the podling. Does that sound reasonable? > my view is that a podling will have a single individual from the asf > who has committed to bringing it through incubation. this person is > the one who nags the podling about filling out clas, doing the licence > and copyright thing and such, and advises the podling community about > how to adapt to the asf way of doing things (meritocracy, voting, et > cetera). this individual also has the responsibility of keeping the > incubator pmc informed of progress and issues, and likewise is the > official conduit for bringing concerns and suggestions from the incubator > to the podling community. > I think this fits with the above idea? > what's the role of the incubator pmc in this? at the least, it's a set > of passionate asf people who are essentially in agreement about what > makes something a genuine 'apache'-style project, who review the > reports of the mentors and make suggestions and eventually vote on > whether the podling has become self-sustaining in the 'apache way' of > doing things. in a more perfect world, the pmc members will involve > themselve more deeply than that in at least some of the podlings, so > they can observe at first hand, possibly providing guidance at first > hand (though preferably through the mentor). > Is it worth setting up some regular reviews of incubating projects? Once every three months or the like? If there is a requirement to review reports, then maybe that should be formalised? > what's the role of a 'sponsoring pmc' in this? solely as an observer > until the podling graduates. > Not sure I'm comfortable with this. I'm not a very good Apache project if all I do is site around and observe. If I say "I want this" then I should have some form of responsibility (and I agree this needs to be put in the form of an individual) to the outcome. Not just as an observer. > what's the role of a sponsoring project in this? to help out, to whatever > degree they severally desire, in educating their soon-to-be neighbours > in specific details about the sponsoring project itself. > As above - I don't see the need to separate sponsor PMC from Sponsor project in this context. > and that's what my thoughts are at this point in time. And mine (FWIW :>). Cheers Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
technology sucks
So, it seems that much of our collective constipation on votes over the past year has been due to the pmc mailing list being without moderators or owner, apparently due to a strange combination of options given when the list was created. A couple of people are now moderators, and I just fixed the latter config problem, but I do hope people are a little faster to complain about "missing messages" if it ever happens again on this (or any other) list. *sigh* Roy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: technology sucks
Roy, Please note that "[EMAIL PROTECTED]" list is suffering the same disease. I said this before at that mailing list. Noone responded. It (nonfeasance) really humiliated me. __ Tetsuya <[EMAIL PROTECTED]> __ On Mon, 22 Sep 2003 16:50:26 -0700 (Subject: technology sucks) "Roy T. Fielding" <[EMAIL PROTECTED]> wrote: > So, it seems that much of our collective constipation on votes > over the past year has been due to the pmc mailing list being > without moderators or owner, apparently due to a strange > combination of options given when the list was created. > > A couple of people are now moderators, and I just fixed the > latter config problem, but I do hope people are a little > faster to complain about "missing messages" if it ever > happens again on this (or any other) list. *sigh* > > Roy > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --- Tetsuya Kitahata -- Terra-International, Inc. E-mail: [EMAIL PROTECTED] http://www.terra-intl.com/ (Accredited Herrmann Brain Dominance Instrument Facilitator) http://www.hbdi.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Berin: Have just read though your email and I feel that I have very strong empathy with the position your raising - but all the same I'm going to disagree with you! I'm confident that if we were in a cafe down in the 14e we would tie this up nicely in less that a couple of hours. But that isn't the case so I'll try my best to present the issues I see in this email. Zut ... Australia really is at the end of the earth relative to France! (Zut translated into Australian is B* H***). Berin Lautenbach wrote: Steve, From: Stephen McConnell <[EMAIL PROTECTED]> 1. Entities (Board, Parent, Incubator PMC) should not assigned actional responsibilities - only decision responsibility. Actional reposibility should be assigned to roles that are represented by accountable individuals. There were a couple of places in the document that needed to be tightened up in this respect. Personally Not sure I fully agree with this, having seen XMLBeans. If the XML Project wants to have the Incubator take on something on its behalf, then there is a two way accountability. I fully believe that the XML Project has to take some accountability for assisting the podling. That accountability (in the case of XMLBeans) is discharged by the Shepherd, who is a member of the XML PMC, but can call on others in the XML project for assistance at any time. Consider the following assertion. The XML Project PMC, the Incubator PMC, the Avalon PMC, the Apache Board, ... all of these are basically dysfunctional entities when it comes down to doing something actionable. These entities are only good for taking decisions (although I must confess that the Board does break this logic from time to time). Let me get to the point - the XML Project PMC can make a decision to sponsor something. In doing so the XML Project PMC Chair has a responsibility concerning the implementation of the decision of the PMC. Now we all know that PMC chairs are gods, and as gods, they are surrounded by angels, and gods like playing golf, so gods, being responsible, delegate things to angels. Fortunately we can associate names with angels, we can hold them responsible and through them we hold the gods accountable. What this means is that the XML Project is doing what you want - but me - as a outsider, I can point a finger at an angel and I can "hey - this needs to be done - and you (angel) personally are responsible". If that doesn't get done - I can go to god and say "hey god, something is wrong - your angel isn't doing what he/she/it? should be doing and your responsible. God gets kind of annoyed - goes to the council of angels (the XML Project PMC) and says - hey guys - we have a problem (meaning hey guys I have a problem). God, using his immortal powers sends down another angel to fix the problem. Have you ever seen the movie Dogma - at the end of the day *she* is responsible. Bottom line - we are always dealing with individuals. The individual may change over time, but there is an individual that is responsible and therefore accountable. Otherwise this is throwing all the responsibility back on a couple of people. To me the whole Apache concept is about community, so lets demonstrate what that means to the podlings. If Ted stops doing his role as Shepherd, then I would see it as the responsibility of the XML project to step in and find someone else. Small change in wording. "If Ted stops doing his role as Shepherd, then I would see it as the responsibility of the XML Project PMC Chair" to step in and find someone else." My impression is that we are actually aiming towards the same thing but that what you thinking of as Sheperd is what I'm thinking of as Sponsor. There are a few other little things but I thought it best to get these two items clarified first. I think you are correct, that we are heading to the same end, but I think it important to separate the sponsor of the original proposal away from the incubation. There are people who are visionaries. "I can see why this is a great project and why it will be a good fit for Apache". They can help a candidate "sell" a proposal to Apache. Are they necessarily the best person to help a project through Incubation? Not so sure. Absolutely 100% agree. But hang in there for a moment and thing about separation of these roles. One role "A" is about responsible representation and guidance with a engagement that is implicit for the duration of incubation - for better or worse. Another role "B" is about vision, excitement, opportunity, enterprise. What the policies and procedures of incubation need is "A". What the project needs initially and on re-occurring occasions is a brilliant "B". But "B" is not the subject of concern of an incubation policy. I think "A" needs to be on the PMC and to represent the project and I think "B" needs to in the public face making sure that the value proposition is communicated. Tying "B" to a set
Re: Another cut at roles and responsibilities
Stephen McConnell wrote: Small change in wording. "If Ted stops doing his role as Shepherd, then I would see it as the responsibility of the XML Project PMC Chair" to step in and find someone else." Wooop - a compound correction to an otherwise perfect composition: "If Ted stops doing his role as Shepherd, then I would see it as the responsibility of the Incubator PMC Chair" to step in and find someone else." or, ... "If Ted stops doing his role as Sponsor, then I would see it as the responsibility of the Parent" to step in and find someone else." Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
Stephen, Actually, I think you had it right the first time. The XML Project PMC should take the first responsibility to find someone where their representative to stop doing his role. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Steve, Not actually sure we are disagreeing. Let me just add some thoughts and see where we get to... > Zut ... Australia really is at the end of the earth relative to France! > (Zut translated into Australian is B* H***). . Tell me about it. The time zones are playing havoc with me. > Bottom line - we are always dealing with individuals. The individual may > change over time, but there is an individual that is responsible and > therefore accountable. Yes I'd agree with this. (And yes I did see Dogma :>). But. (see below) > >Otherwise this is throwing all the responsibility > >back on a couple of people. To me the whole > >Apache concept is about community, so lets > >demonstrate what that means to the podlings. > > > >If Ted stops doing his role as Shepherd, then I > >would see it as the responsibility of the XML > >project to step in and find someone else. > > > > Small change in wording. "If Ted stops doing his role as Shepherd, then > I would see it as the responsibility of the XML Project PMC Chair" to > step in and find someone else." Yes - that I can live with (and even agree with :>), as it fits with the responsibility of the chair to the board. But to me, that makes the XML PMC chair ultimately accountable. If I'm the CEO of an organisation (I wish), I delegate responsibility for overall marketting to a given area. However, if that delegation fails, it is myself that is held accountable to the board. So the company as a whole looks to the marketting department to action what is necessary, but when it all fouls up the CEO holds the can. I suspect we might be violently agreeing? > > >>My impression is that we are actually aiming towards the same thing but > >>that what you thinking of as Sheperd is what I'm thinking of as > >>Sponsor. There are a few other little things but I thought it best to > >>get these two items clarified first. > >> > >> > > > >I think you are correct, that we are heading to > >the same end, but I think it important to > >separate the sponsor of the original proposal > >away from the incubation. > > > >There are people who are visionaries. "I can see > >why this is a great project and why it will be > >a good fit for Apache". They can help a > >candidate "sell" a proposal to Apache. Are they > >necessarily the best person to help a project > >through Incubation? Not so sure. > > > > Absolutely 100% agree. > > But hang in there for a moment and thing about separation of these > roles. One role "A" is about responsible representation and guidance > with a engagement that is implicit for the duration of incubation - for > better or worse. Another role "B" is about vision, excitement, > opportunity, enterprise. What the policies and procedures of incubation > need is "A". What the project needs initially and on re-occurring > occasions is a brilliant "B". But "B" is not the subject of concern of > an incubation policy. I think "A" needs to be on the PMC and to > represent the project and I think "B" needs to in the public face making > sure that the value proposition is communicated. Tying "B" to a set of > policies and procedures is the last thing you want. But it does mean > you need to establish an "A" for the long haul. > Yes - I agree with this. Particularly on not tying B to the policies and procedures. Keep this as fluid as possible. That's what I tried to do in removing responsibility on Sponsor in the document, but with the actual intent of your paragraph below where you substitue sponsor with shepherd. > "A" == Respected and Recognized Sponsor > "B" == Director of Marketing > > > >To me, that's what the very notion of a shepherd is - someone > >who guards and protects the flock. > > > > DIR="LTR"> > > Substitute you idea of Shepard for Sponsor. Assume you have a Marketing > Director in the wings and that you Sponsor and Marketing Directory are > secretly working together on a plan titled "72 hour Incubator Exit > Strategy". Also assume that the Shepherd is the one to overcome (kind > of like a VC Investor). He has final say - do you get the green light > or not - so everything your Sponsor and your Marking Director do is to > move the Shepherd along the path you would like. If you do this right - > you have the ingredients backing you (a good project with a clean > profile) then getting passed the Shepherd should not be a problem. Keep > in mind that Shepherds are simple minded people that know a lot about > sheep but don't know anything about what sheep actually think. Also keep > in mind that the Shepherd can kill the sheep with reasonable cause. But > if you have a Marketing Manager in the wings - and if the project is OK > - you exit, the Shepherd gets sent home with a pat on the back and a > round of cheese - and the sheep run around looking happy and content - > the Marketing Manager drives off looking or a new challenge, and you > lean back in you chair, look at
RE: Another cut at roles and responsibilities
> From: "Noel J. Bergman" <[EMAIL PROTECTED]> > Subject: RE: Another cut at roles and responsibilities > Date: 23/09/2003 11:20:12 > To: <[EMAIL PROTECTED]> > > Stephen, > > Actually, I think you had it right the first time. The XML Project PMC > should take the first responsibility to find someone where their > representative to stop doing his role. Likewise. Cheers, Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
Stephen, If we ever sit down in some hypothetical cafe, remind me to have a talk with you about how to present an argument for best effect. :-) Once I got past some of your phrasing, which I consider somewhat injudiciously selected considering your likely audience, it occurred to me that although you say that you disagree with Berin, you end up saying largely the same thing that Berin did. As Berin just said to you, it seemed to him that you "might be violently agreeing", despite your starting your argument with "I'm going to disagree with you!" Berin has already adopted the idea that when a PMC is involved, responsibility is vested in one person. Actions can be delegated, but that one agent is responsible. Tom Sawyer took responsibility for getting the fence painted. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Noel J. Bergman wrote: Stephen, Actually, I think you had it right the first time. The XML Project PMC should take the first responsibility to find someone where their representative to stop doing his role. Actually - I disagree. If I say that the Board is responsible. What I am saying is that there is a shared responsibility on each and every member of the Board. Now in reality, that means that responsibility is diluted because if a go to a Board Member and say - "hey - you are responsible" - the board member can say to me - "what!, no - I am a member of a group and it is the group that makes decisions - not I". I then say - "so who is responsible for the group" and the member says to me -"go talk to the Chair". So I go talk to the Chair - and I say to the Chair - "hey Chair, your responsible, here is the issue" - and the Chair doesn't reply to me for 14 days - but then I get a message - "Sorry Steve I can't do anything about this". So who is responsible and who is accountable? In this scenario - the Chair is responsible and accountable (sorry Greg) ;-) It is the prerogative of the chair to return a decision directly, or, to reflect to me a decision of the members of the forum he/she represents. Either way - the Chair reflects the Board responsibility and Greg carries the ultimate individual accountability. Individual accountability is the subject here because we are talking about the engagement of Apache Members or Officers to positions of responsibility. And I, as a member of this community want to *assure* a complete line of accountability for said responsibility - cradle to grave. Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: technology sucks
> Please note that "[EMAIL PROTECTED]" > list is suffering the same disease. It looks to me that projects@ has both an owner and a moderator (although it could use more moderators). Your comment (http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] he.org&msgNo=41) was about a Reply-To header. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
> >Actually, I think you had it right the first time. The XML Project PMC > >should take the first responsibility to find someone where their > >representative to stop doing his role. > Actually - I disagree. Actually, you didn't. What you did was engage in a discussion of individual vs group responsibility, without realizing that the issue I had raised was that your earlier posted reversed the roles of the XML PMC and the Incubator PMC, which is what Berin had noticed, too. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
A home for internationalization
> If [we] would think of the creation of "i18n.apache.org" or > "document.apache.org", (i18n TLP / Documentation TLP), > 'projects produce code' principle could be an obstacle As I recall, there is was discussed at length on [EMAIL PROTECTED] The proposal at the time was to give it a mailing list if there was sufficient interest. Having given it more thought, I think that Apache Commons (http://commons.apache.org/) might be a suitable home. The project could use a CVS to maintain its own educational documents, and would have a mailing list. I suggest that you pursue that matter in that direction, and see what they have to say. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Noel J. Bergman wrote: Actually, I think you had it right the first time. The XML Project PMC should take the first responsibility to find someone where their representative to stop doing his role. Actually - I disagree. Actually, you didn't. What you did was engage in a discussion of individual vs group responsibility, without realizing that the issue I had raised was that your earlier posted reversed the roles of the XML PMC and the Incubator PMC, which is what Berin had noticed, too. * If this relates to an actionable issue - could you be a touch more specific as to the action. * Steve. (who is terribly slow and dull witted in these matters) Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Noel J. Bergman wrote: Stephen, If we ever sit down in some hypothetical cafe, remind me to have a talk with you about how to present an argument for best effect. :-) Once I got past some of your phrasing, which I consider somewhat injudiciously selected considering your likely audience, Hang on a tick - I have to look this one up! http://www.hyperdictionary.com/dictionary/injudiciously WorldNet Dictionary: Definition: [adv] in an injudicious manner; "these intelligence tests were used injudiciously for many years" Antonyms: judiciously Zut .. we are looking for the inverse defintion! Webster's 1913 Dictionary Definition: \Ju*di"cious*ly\, adv. In a judicious manner; with good judgment; wisely. Oh no - without good judjement or wisdom. Finally it all falls into place! it occurred to me that although you say that you disagree with Berin, you end up saying largely the same thing that Berin did. As Berin just said to you, it seemed to him that you "might be violently agreeing", despite your starting your argument with "I'm going to disagree with you!" I think that Berin and I are aiming at the same objective and have very similar motives. I happen to think that we can leverage and utilize the contribution of Berin's process by analysing his concers and underlying interests and drawing from that the essence that is intrinsically important to policy, while preserving, and maintain the liberty he is persuing. I remain confident that Berin will be more than happy to share a , Fosters, Southark (?), Redback, or (that other one that I cannot remember) should the opportunity arise. Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
Cliff Schmidt wrote: > OK, based on everything I've read from this and a few of the > other threads on this list, which I've just caught up to (I > picked a bad weekend to attend a wedding that took me off email > ;-), I am going to propose to the other XMLBeans folks that we > do the following: > > 1. Create a build of a cvs snapshot and name the file: > "incubated-xmlbeans-1.0.0.zip" (Ted's more serious suggestion > than the one below, although that one made me smile more). > > 2. Edit the README.txt file to include a paragraph explaining > that this build is a snapshot of an incubated project that is > not yet officially endorsed by the ASF. > > 3. Add a note to the XMLBeans project web site making sure the > incubation status is clear. > > Unless there are other suggestions, I'm going to assume this is > a reasonable process to follow for an incubated project, which > needs to make binaries available in order to help build a > community. this sounds to me like a very good plan. thank you! -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Berin Lautenbach wrote: Steve, Not actually sure we are disagreeing. Let me just add some thoughts and see where we get to... Zut ... Australia really is at the end of the earth relative to France! (Zut translated into Australian is B* H***). . Tell me about it. The time zones are playing havoc with me. Bottom line - we are always dealing with individuals. The individual may change over time, but there is an individual that is responsible and therefore accountable. Yes I'd agree with this. (And yes I did see Dogma :>). But. (see below) Otherwise this is throwing all the responsibility back on a couple of people. To me the whole Apache concept is about community, so lets demonstrate what that means to the podlings. If Ted stops doing his role as Shepherd, then I would see it as the responsibility of the XML project to step in and find someone else. Small change in wording. "If Ted stops doing his role as Shepherd, then I would see it as the responsibility of the XML Project PMC Chair" to step in and find someone else." Yes - that I can live with (and even agree with :>), as it fits with the responsibility of the chair to the board. But to me, that makes the XML PMC chair ultimately accountable. If I'm the CEO of an organisation (I wish), I delegate responsibility for overall marketting to a given area. However, if that delegation fails, it is myself that is held accountable to the board. So the company as a whole looks to the marketting department to action what is necessary, but when it all fouls up the CEO holds the can. I suspect we might be violently agreeing? So far ... yes! My impression is that we are actually aiming towards the same thing but that what you thinking of as Sheperd is what I'm thinking of as Sponsor. There are a few other little things but I thought it best to get these two items clarified first. I think you are correct, that we are heading to the same end, but I think it important to separate the sponsor of the original proposal away from the incubation. There are people who are visionaries. "I can see why this is a great project and why it will be a good fit for Apache". They can help a candidate "sell" a proposal to Apache. Are they necessarily the best person to help a project through Incubation? Not so sure. Absolutely 100% agree. But hang in there for a moment and thing about separation of these roles. One role "A" is about responsible representation and guidance with a engagement that is implicit for the duration of incubation - for better or worse. Another role "B" is about vision, excitement, opportunity, enterprise. What the policies and procedures of incubation need is "A". What the project needs initially and on re-occurring occasions is a brilliant "B". But "B" is not the subject of concern of an incubation policy. I think "A" needs to be on the PMC and to represent the project and I think "B" needs to in the public face making sure that the value proposition is communicated. Tying "B" to a set of policies and procedures is the last thing you want. But it does mean you need to establish an "A" for the long haul. Yes - I agree with this. Particularly on not tying B to the policies and procedures. Keep this as fluid as possible. We are on sync on this! :-) That's what I tried to do in removing responsibility on Sponsor in the document, but with the actual intent of your paragraph below where you substitue sponsor with shepherd. "A" == Respected and Recognized Sponsor "B" == Director of Marketing To me, that's what the very notion of a shepherd is - someone who guards and protects the flock. Substitute you idea of Shepard for Sponsor. Assume you have a Marketing Director in the wings and that you[r] Sponsor and Marketing Directory are secretly working together on a plan titled "72 hour Incubator Exit Strategy". Also assume that the Shepherd is the one to overcome (kind of like a VC Investor). He has final say - do you get the green light or not - so everything your Sponsor and your Marking Director do is to move the Shepherd along the path you would like. If you do this right - you have the ingredients backing you (a good project with a clean profile) then getting passed the Shepherd should not be a problem. Keep in mind that Shepherds are simple minded people that know a lot about sheep but don't know anything about what sheep actually think. Also keep in mind that the Shepherd can kill the sheep with reasonable cause. But if you have a Marketing Manager in the wings - and if the project is OK - you exit, the Shepherd gets sent home with a pat on the back and a round of cheese - and the sheep run around looking happy and content - the Marketing Manager drives off looking or a new challenge, and you lean back in you chair, look at the screen, smile, and say to yourself "it works". I *think* this is w
RE: Another cut at roles and responsibilities
> if this relates to an actionable issue - could you be a touch more > specific as to the action. Actually, at this point I think that discussion has converged, a consensus appears to have emerged, and since Berin has taken a lead on coalescing this material, I think it makes sense to give him (and the Incubator PMC) time to pull it together. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
>>Once I got past some of your phrasing, which I consider somewhat >>injudiciously selected considering your likely audience, > Hang on a tick - I have to look this one up! LOL Well, for a start, referring to every decision making body as dysfunctional wasn't the wisest course of action in my view. :-) Your point that things work better if after a consensus is reached, responsibility is vested in individuals is valid, but too easily lost in the response that people have to the expression. And yes, I realize that you didn't quite say it that way, but when people react reflexively, it is a difference without a distinction. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
> Think of this entire process as the establishment of a set of imutable > procedures that will protect us from the breakdown of their system. Things don't work that way, Stephen. People don't. Especially the kind of people who participate here. This is not a community of bureaucrats. As underspecified as the process may have been, you are engaging in vast overengineering. We will do far, far better with a clear set of guidelines that people can understand and are willing to implement, than a legal tome. We have multiple parties to provide oversight, and means to correct problems. The Incubator PMC, Sponsor, other members, the podling itself, the Community at large ... any one of them is capable of noticing and raising an issue to be addressed. That is the nice thing about a community of intelligent life forms. You don't have to program them. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Noel J. Bergman wrote: Think of this entire process as the establishment of a set of imutable procedures that will protect us from the breakdown of their system. Things don't work that way, Stephen. People don't. Especially the kind of people who participate here. This is not a community of bureaucrats. As underspecified as the process may have been, you are engaging in vast overengineering. We will do far, far better with a clear set of guidelines that people can understand and are willing to implement, than a legal tome. If there is overengineering I need specific in order to address the concern. We have multiple parties to provide oversight, and means to correct problems. The Incubator PMC, Sponsor, other members, the podling itself, the Community at large ... any one of them is capable of noticing and raising an issue to be addressed. And aach capable of assuming that the other is undertaking the responsibility. Each negligent in assuring oversight, each justified in claiming non-culpability. You and I have very different views here (which is ok). I view the incubator as an emergent entity within Apache - an entity that is clearly in need of a framework, a framework that: (a) protect itself from itself (b) establishes concrete rules (c) establish accountability (d) is robust Such a framework has to be embedded in policies and procedures. Please consider me as the anti-christ. If I jump in on this list and within a few posts manage to change proposed structural policy - all it means is that the policy does not exist. I am simply manipulating the status quo. Make the assumption that I am here to corrupt, to circumvent, to manipulate - then ask yourself the question ... "what framework do you have in place today to protect youself and the community you represent"? Today the incubator is for all purposes is defenseless. Hopefully this will change with the establishment and adoption of concrete set of policies and procedures. Now make another assumption .. "Steve is about to enter into an incubation, and Steve does not have the spare-time to to deal with indecision, lack of accountability, nor political ineptitude, and as such Steve will go out of his way to close every gap and loophole to ensure that a rapid and successful exit from this process is all but assured". Was that sufficiently politically correct or should I be more subtle and rephrase something? Cheers, Steve. -- mailto:[EMAIL PROTECTED] Stephen J. McConnell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
> > As underspecified as the process may have been, you are engaging > > in vast overengineering. > If there is overengineering I need specific in order to address the concern. I hope you can see the humor in that juxtaposition. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: technology sucks
On Mon, 22 Sep 2003 21:44:05 -0400 (Subject: RE: technology sucks) "Noel J. Bergman" <[EMAIL PROTECTED]> wrote: > Your comment > (http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=41) > was about a Reply-To header. Oh, yes. yes. *** NOTE *** Lists without "Reply-To" Header would be sure to become "inactive" lists soon ... E-mail cultures/histories had shown, proven. Quite, "technology sucks". I can easily imagine that many (especially, Paul Hammant) participants in that mailing list would have received *personal* mails which should go to the lists directly. The current config of infrastructure@ must be reasonable because that list is to become "HELP DESK", not "LIST FOR DISCUSSION". However, "[EMAIL PROTECTED]" must be "LIST FOR DISCUSSION" and strengthen the [AltRMI], [FTPServer] communities. The apparent difference there might be. Again and again, Lists without "Reply-To" Header would be sure to become "inactive" lists soon. Regards, __ Tetsuya <[EMAIL PROTECTED]> __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: technology sucks
> Lists without "Reply-To" Header ... If the PMC wants the list properties changed, perhaps because of requests from the list users, they can submit a request to have the list reconfigured. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Noel J. Bergman wrote: Once I got past some of your phrasing, which I consider somewhat injudiciously selected considering your likely audience, Hang on a tick - I have to look this one up! LOL Well, for a start, referring to every decision making body as dysfunctional wasn't the wisest course of action in my view. :-) Well, I thought about this. I could have gone for the Presidency, but I decided that at the end of the day there are more than a couple of pots to be stirred here in Apache for the benefit of Apache. So,.. irrespective of my political agenda, please take in a account the evidence of my diplomatic nature - namely the qualification of dysfunctional relative to "actionable criteria". Your point that things work better if after a consensus is reached, responsibility is vested in individuals is valid, but too easily lost in the response that people have to the expression. And yes, I realize that you didn't quite say it that way, but when people react reflexively, it is a difference without a distinction. There is a value to be gained in the assessment of what is a reflexive as distinct from a consider response. That assessment is something that rests with the recipient and will be judged in the fullness of time. In the meantime (i.e. today), and with full respect for everyone involved (with the exception of any Japaneses individuals carrying umbrellas), and with full consideration for the implication of the actions currently in place, I hope that the policies, procedures, responsibilities, and ultimate accountabilities, will have a tangible and net-positive impact on the overall development of the Apache Community. Cheers Steve. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
On 9/22/2003 6:28 PM, Berin Lautenbach wrote: From: "Noel J. Bergman" <[EMAIL PROTECTED]> Subject: RE: Another cut at roles and responsibilities Date: 23/09/2003 11:20:12 To: <[EMAIL PROTECTED]> Stephen, Actually, I think you had it right the first time. The XML Project PMC should take the first responsibility to find someone where their representative to stop doing his role. Likewise. Cheers, Berin +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
On 9/22/2003 4:50 PM, Berin Lautenbach wrote: From: Rodent of Unusual Size what's the role of the incubator pmc in this? at the least, it's a set of passionate asf people who are essentially in agreement about what makes something a genuine 'apache'-style project, who review the reports of the mentors and make suggestions and eventually vote on whether the podling has become self-sustaining in the 'apache way' of doing things. in a more perfect world, the pmc members will involve themselve more deeply than that in at least some of the podlings, so they can observe at first hand, possibly providing guidance at first hand (though preferably through the mentor). Is it worth setting up some regular reviews of incubating projects? Once every three months or the like? If there is a requirement to review reports, then maybe that should be formalised? From the podlings point of view, I think that this would be good. Actually from any point of view. what's the role of a 'sponsoring pmc' in this? solely as an observer until the podling graduates. Not sure I'm comfortable with this. I'm not a very good Apache project if all I do is site around and observe. If I say "I want this" then I should have some form of responsibility (and I agree this needs to be put in the form of an individual) to the outcome. Not just as an observer. I must have missed this the first time around. I agree with Berin here. Before the incubator, all the responsibility would have been on the sponsoring PMC. I think that sponsoring PMCs need to take an active role in helping projects move through the incubator. Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
> I hope that the policies, procedures, responsibilities, and > ultimate accountabilities, will have a tangible and net- > positive impact on the overall development of the Apache Community. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Noel J. Bergman wrote: I hope that the policies, procedures, responsibilities, and ultimate accountabilities, will have a tangible and net- positive impact on the overall development of the Apache Community. :-) That's it - no umbrella questions? This is so dissapointing! Steve! -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
On 9/22/2003 4:52 PM, Noel J. Bergman wrote: Ted, If I were you, I think that I would subscribe myself to the Incubator PMC mailing list. That way you can see how things are settling in (I would expect that they could use a bit of time to consolidate all of the discussion), and if they say that they're ready, find out whom is going to take responsibility for working with you. Done. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exit Criteria
Ted, > There are a few XML beans specific items in this list, but I'd like to > propose that we start a discussion of exit criteria based on this list. Seems a reasonable starting point. I took the liberty of putting a generic version of it on the Wiki: http://nagoya.apache.org/wiki/apachewiki.cgi?ExitingIncubator. I don't agree with each item, or at least give them equal weight, but I tried to preserve them pending discussion. - Legal I didn't see any that struck me as optional. One thing not present was vetting the code to make sure that there are no IP issues. I suspect that the Incubator PMC is accummulating experience on legal issues to expand the checklist. - Meritocracy / Community Some are more subjective area, but I largely agree with your points. Not sure, though, what you have in mind with respect to [EMAIL PROTECTED] And there would be more items in the event that the podling is to be a TLP. - Alignment / Synergy I am a big fan of eating one's own dogfood where possible. It helps to improve the taste and quality. And builds stronger communities. - Infrastructure Looked right, but subject to change as the infrastructure evolves. Also, not everyone is easily tied into the web of trust. I haven't physically seen an ASF participant in close to a year. I suppose that Dion Gillard and I can sign each other's keys when we see each other in another month. I don't know whom else will be there. But that's a minor point. Reading some of the incubator STATUS files was instructive to see what problems have occurred. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Kannel discussion invitation
Stipe Tolj wrote: no good, alas; i'll be on the road driving to another town at that point. i *should* be back within a couple of hours, though. :-/ Ken, please find the #kannel IRC channel log of the debate at http://www.kannel.org/irc-sessions/ from last friday and today. People have raised a couple of questions in terms how "independancy" of a project is impacted when moving to ASF. You you or other from the incubation project comment on this please. I read both sessions (I'm not used to reading IRC logs, and not knowing you guys it's difficult to understand). IIUC there is a point where you question wether technical decisions are taken by someone other than the developers. Well, it is not the case. Technical decisions on a project are solely taken by the project committers, using the Apache voting guidelines. http://incubator.apache.org/drafts/voting.html Some extra info about Apache: http://incubator.apache.org/drafts/theapacheway.html How to have new developers join: http://incubator.apache.org/drafts/newcommitters.html Also, we'd like to make an IRC session with a couple of you Apache guys online, so Kannel developer's can directly ask. How should we proceed in having an appointment fixed?! Email is better IMO for such a type of discussions. Many of us are not in the US or in any case in your same time-zone, so email makes it possible for all to partecipate. This is why all project decisions and most if not all discussions are taken in email. If you send us here your concerns and questions we'll be happy to answer :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
