Re: Getting the distribution onto a download site somewhere ...
Rodent of Unusual Size wrote: Cliff Schmidt wrote: this sounds to me like a very good plan. thank you! +1 :-) -- 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
Ted Leung wrote: 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. +1 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. I agree. If a PMC wants a project, he cannot simply have it attached as a "prize". It's the same issue with a walk-away sponsors. Sponsors must give something, else they don't "sponsor". -- 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: Exit Criteria
Ted Leung wrote: 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) How do you assess that? Are we sure 50% is not too much? Will it take too much time? 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. Yup, this is important. We now have Apache projects that do not follow this rule sometimes and have to be reminded every time, so it's a good idea. (requriment on minimum number of such releases?) two? 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 Not needed. XML PMC already accepted it, we cannot have the case in which the Incubator says ok, and then the XML one does not. As a sponsor that has voted for incubation there is no reason why they have to vote again. Alignment / Synergy Replacement of LGPL Piccolo parser with Xerces. Develop synergistic relationship with JaxMe in WS-Commons, also perhaps with Axis. Not necessary. Use of any relevant Jakarta subprojects. Not necessary. 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 Great :-) -- 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: technology sucks
Tetsuya Kitahata wrote: 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. I'm the moderator there, and I didn't see your mail. I apologise for missing it, it was not intentional. Sorry. -- 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: Another cut at roles and responsibilities
> From: Stephen McConnell <[EMAIL PROTECTED]> > 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. Absolutely agree with all of the above. I think :>. > 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. . Absolutely. And probably more than 1. 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 McConnell wrote: Thus you have the shepherd appointed by the sponsor PMC, but being bound by the Incubator PMC rules and regs. (And I would imagine the incubator would need to agree the choice.) Which does not work in practice (with respect to current policy). The Icubator PMC has been charged with the responsiblity of incubation. We have to give them the opportunity to do this. Your PMC, my PMC, neither are charged with this responsibility. All we can do it is establish a framework that ensures the integrity of the transition. Thought I would just pick up on this one. This is what we did for XMLBeans. Ted (as a member of the XML PMC) volunteered to take on the shepherd role and the Incubator agreed. Personally I like this approach. Ted keeps using the term "infrastructure tax". I see this as similar. We want something - we do the work to make it happen. In other cases, the Incubator PMC (or the board) might be the sponsoring entity (parent?). In these cases, the shepherd might be nominated from the Incubator PMC or from elsewhere. The key oversite from the Incubator is (to my mind) and independant review of what is happening. If the incubator also has to find people willing to shepherd each candidate as it comes along, we risk never finding willing shepherds. Does that sound fair? Yes - providing we give the Incuabtor PMC due responsibility and ... we ensure that the policies and procedures protect us from potential absuse or neglect of said responsibilites by said PMC. I think we are - in the form of oversite and directions of actions taken by shepherds. Cheers, Berin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exit Criteria
Nicola Ken Barozzi wrote: 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 Not needed. XML PMC already accepted it, we cannot have the case in which the Incubator says ok, and then the XML one does not. As a sponsor that has voted for incubation there is no reason why they have to vote again. (nothing to do with the infrastructure tax:) Do I read you correct in saying that the receiving PMC has no chance anymore to declare an incubation failed, if the Incubator PMC says the contrary? In that case (and I hope I'm wrong), why is the receiving PMC involved then? -- 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: Exit Criteria
Steven Noels wrote: Nicola Ken Barozzi wrote: 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 Not needed. XML PMC already accepted it, we cannot have the case in which the Incubator says ok, and then the XML one does not. As a sponsor that has voted for incubation there is no reason why they have to vote again. (nothing to do with the infrastructure tax:) Do I read you correct in saying that the receiving PMC has no chance anymore to declare an incubation failed, if the Incubator PMC says the contrary? Exactly. The sponsoring PMC asks to have that project. This means that it *wants* that project and that community. Why would it change its mind? In that case (and I hope I'm wrong), why is the receiving PMC involved then? Eh? In the same way the shepherd is, the sponsor is, etc. They are involved in helping out and seeing that the incubated project becomes *part* of the community. I don't understand you... how do you se the role of the sponsoring PMC instead? -- 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: Exit Criteria
Steven Noels wrote: Do I read you correct in saying that the receiving PMC has no chance anymore to declare an incubation failed, if the Incubator PMC says the contrary? In that case (and I hope I'm wrong), why is the receiving PMC involved then? I've put something slightly different into the IncubatorMussings document. I've said that the Incubator PMC *recommends* to the Sponsoring Entity (the receiving PMC) that something has completed, needs to continue or fails. So it would then be up to the Sponsoring Entity to make a determination on its own exit criteria (i.e. does it need to re-vote). In the case of something like Geronimo the Sponsoring Entity *has* to vote. A new TLP can only be created by a vote of the board. Cheers, Berin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exit Criteria
Nicola Ken Barozzi wrote: The sponsoring PMC asks to have that project. This means that it *wants* that project and that community. Why would it change its mind? Maybe there were reservations that the PMC wanted to have covered off during incubation. The best way to ensure that everyone is comfortable *may* be to have another vote. Might be best to leave to the Sponsoring Entity? (Hate that name, and have got stuck Talking In Capitals from writing this Horrible Document :>.) Cheers, Berin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exit Criteria
Nicola Ken Barozzi wrote: Exactly. The sponsoring PMC asks to have that project. This means that it *wants* that project and that community. Why would it change its mind? Because of things happening during incubation. What if a podling becomes a mutant during incubation, in the best case changing directions, and requiring a change of receiving PMC, in the worst case because the podling becoming a Hulk creature? Will the podling linger in incubation forever, if the Incubation PMC and the receiving PMC differ in their judgment about failure? In that case (and I hope I'm wrong), why is the receiving PMC involved then? Eh? In the same way the shepherd is, the sponsor is, etc. They are involved in helping out and seeing that the incubated project becomes *part* of the community. Exactly. But failure *is* an option, I hope? OT: a lesson I'm learning these days is that candidate podlings should carefully consider whether they are an infrastructural/technological framework, or a functional/user-use-case application. I believe the ASF has better nurturing grounds for the former, rather than the latter. -- 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: Another cut at roles and responsibilities
Berin Lautenbach wrote: Stephen McConnell wrote: Thus you have the shepherd appointed by the sponsor PMC, but being bound by the Incubator PMC rules and regs. (And I would imagine the incubator would need to agree the choice.) Which does not work in practice (with respect to current policy). The Icubator PMC has been charged with the responsiblity of incubation. We have to give them the opportunity to do this. Your PMC, my PMC, neither are charged with this responsibility. All we can do it is establish a framework that ensures the integrity of the transition. Thought I would just pick up on this one. This is what we did for XMLBeans. Ted (as a member of the XML PMC) volunteered to take on the shepherd role and the Incubator agreed. Personally I like this approach. Ted keeps using the term "infrastructure tax". I see this as similar. We want something - we do the work to make it happen. In other cases, the Incubator PMC (or the board) might be the sponsoring entity (parent?). In these cases, the shepherd might be nominated from the Incubator PMC or from elsewhere. The key oversite from the Incubator is (to my mind) and independant review of what is happening. If the incubator also has to find people willing to shepherd each candidate as it comes along, we risk never finding willing shepherds. Let me put this straight, as with this terminology we are getting confused. I'll define the things with the terminology I use ATM. An incubation needs someone that actively nutrures the community, pushes the agenda and reports to the PMC of which he is part. I call him the sponsor. We also need someone that is knowlegable of how the Incubator works and that reports to the Incubator PMC. I call him the shepherd. Probably the best thing would be to call: sponsor ->shepherd shepherd->mentor but I'll leave this exercise to others. This means that we need two people, one that *at least* wants to help out and one that *at least* knows how to do incubation. "at least" means that both can be in the Incubator PMC for example, the clear cut is not there. What we need thought is that the two functions are performed. Would it be possible to have a single person doing it? Theorically yes, as someone that is already part of this PMC can decide to shepherd a project, but I have seen that to make it easier and smoother at least two people are required. The fact that there are two people also helps in making both learn from each other, and make sponsors learn to be shepherds. Does that sound fair? Yes - providing we give the Incuabtor PMC due responsibility and ... we ensure that the policies and procedures protect us from potential absuse or neglect of said responsibilites by said PMC. I think we are - in the form of oversite and directions of actions taken by shepherds. Another thing. I have read about private mails that help heal things before they happen. That is good, but the PMC should always be informed of what is happening so that they can act collectively if needed. This is quite important IMO to keep the loop closed and have information come back to the PMC. -- 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: Exit Criteria
Berin Lautenbach wrote: Nicola Ken Barozzi wrote: The sponsoring PMC asks to have that project. This means that it *wants* that project and that community. Why would it change its mind? Maybe there were reservations that the PMC wanted to have covered off during incubation. Practical example? Reality shows me that *any* project at *any* time can want to change things. So a project can decide to switch PMCs and maybe go top level. But I cannot see why a PMC that asked for a project would reject it after the Incubation is succesful. The best way to ensure that everyone is comfortable *may* be to have another vote. Might be best to leave to the Sponsoring Entity? (Hate that name, and have got stuck Talking In Capitals from writing this Horrible Document :>.) Call it Sponsor. -- 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]
3rd update to roles and responsibilities
Peoples, Have done another update and tried to represent the results of the various comments during the day. Have mainly tried to : 1) Re-emphaise the role of a Sponsor as an ongoing role. No particular requirements in the process (other than initial recommendation), but have stated that there is an expectation of continued involvement and assistance, and that anything else may actually negatively impact the incubation process (doesn't say anything good if the Sponsor looses interest). 2) Left the Sponsoring Entity responsibilities, but have clearly stated that these are discharged by the Shepherd, who is representing the Sponsoring Entity. Again thoughts are welcome (and expected :>). Cheers, Berin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Nicola Ken Barozzi wrote: An incubation needs someone that actively nutrures the community, pushes the agenda and reports to the PMC of which he is part. I call him the sponsor. We also need someone that is knowlegable of how the Incubator works and that reports to the Incubator PMC. I call him the shepherd. Would be great if you could have a read through the new version of http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings I'm hoping that it is something that will work. I've actually got it such that the Shepherd reports to both. The Sponsor is someone who helps out everywhere, but has no *formal* responsibility. Otherwise there are a whole lot of people formally responsibly for a whole lot of things and it could get messy. Cheers, Berin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exit Criteria
Steven Noels wrote: Nicola Ken Barozzi wrote: Exactly. The sponsoring PMC asks to have that project. This means that it *wants* that project and that community. Why would it change its mind? Because of things happening during incubation. What if a podling becomes a mutant during incubation, in the best case changing directions, and requiring a change of receiving PMC, in the worst case because the podling becoming a Hulk creature? Will the podling linger in incubation forever, if the Incubation PMC and the receiving PMC differ in their judgment about failure? I really think that this is a wild example. I really think that the Incubator PMC would not declare success of a Hulk (TM) Project, unless we're all nuts ;-) As for changing PMC that's another point, that happens with other projects too, and can be treated in the same way. In that case (and I hope I'm wrong), why is the receiving PMC involved then? Eh? In the same way the shepherd is, the sponsor is, etc. They are involved in helping out and seeing that the incubated project becomes *part* of the community. Exactly. But failure *is* an option, I hope? Failure of Incubation, yes. If a project cannot work well with the Sponsor PMC it's a failure, the Incubator will not agree to make it go. It may decide to swith targets, but imposing a project on non-willing PMC is simply out of question. It's part of judging if the Incubation is succesfull. For example, for Lenya I'm wondering if Cocoon is the right place for them, as I've not seen much involvment. I'll wait and see, but for now I would not vote for exit as there is not much integration. -- 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: Exit Criteria
Nicola Ken Barozzi wrote: If a project cannot work well with the Sponsor PMC it's a failure, the Incubator will not agree to make it go. It may decide to swith targets, but imposing a project on non-willing PMC is simply out of question. Which may require a vote of the PMC in question to determine? Isn't it best to leave this part of it to the PMC in question - if we don't need to specify then should we? Cheers, Berin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exit Criteria
Nicola Ken Barozzi wrote: If a project cannot work well with the Sponsor PMC it's a failure, the Incubator will not agree to make it go. It may decide to swith targets, but imposing a project on non-willing PMC is simply out of question. OK - good. Mind you that I don't intend this to be a critique to the podling, I'm rather trying to prevent what happened to Jakarta in the past: many disconnected subprojects under an umbrella PMC with little community glue in-between them. It's part of judging if the Incubation is succesfull. For example, for Lenya I'm wondering if Cocoon is the right place for them, as I've not seen much involvment. I'll wait and see, but for now I would not vote for exit as there is not much integration. As a member of the Cocoon, or Incubator PMC? -- 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: Exit Criteria
Berin Lautenbach wrote: Nicola Ken Barozzi wrote: If a project cannot work well with the Sponsor PMC it's a failure, the Incubator will not agree to make it go. It may decide to swith targets, but imposing a project on non-willing PMC is simply out of question. Which may require a vote of the PMC in question to determine? I don't think so. Not clear situations are failures themselves. Isn't it best to leave this part of it to the PMC in question - if we don't need to specify then should we? We need to give someone, and this someone is a *single* entity, the burden of declaring succes or failure. Since the final responsibility is on the Incubator PMC... I have done cross-votes for accepting projects and it has been quite a mess. So now we just accept any project that is voted in by a PMC. The same thing is about incubation. If a PMC does not want a project it can technically still vote and ask the incubator to not have it, there is no rule that can prevent that. But it would be a case of a very dysfunctional Incubator and thus should not have to be part of the standard process. I think it will/*should* never occur, as the two PMCs should be kept in contact by the shepherd, and basically have a converging view over what is happening. -- 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: Another cut at roles and responsibilities
Berin Lautenbach wrote: Nicola Ken Barozzi wrote: An incubation needs someone that actively nutrures the community, pushes the agenda and reports to the PMC of which he is part. I call him the sponsor. We also need someone that is knowlegable of how the Incubator works and that reports to the Incubator PMC. I call him the shepherd. Would be great if you could have a read through the new version of http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings Done. It's *very* well writtem :-) Oh, if I were able to write formal documents in such a clear way! I'm hoping that it is something that will work. I've actually got it such that the Shepherd reports to both. The Sponsor is someone who helps out everywhere, but has no *formal* responsibility. Yes, this part is IMO correct and well described. Otherwise there are a whole lot of people formally responsibly for a whole lot of things and it could get messy. Yup. There is only one point that I have different in my mind and that is IIUC addressed there. It's about having an "elder" shepherd mentoring the main shepherd, and possibly requiring at least two people helping in Incubation. What do others think about 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: Exit Criteria
Steven Noels wrote: Nicola Ken Barozzi wrote: If a project cannot work well with the Sponsor PMC it's a failure, the Incubator will not agree to make it go. It may decide to swith targets, but imposing a project on non-willing PMC is simply out of question. OK - good. Mind you that I don't intend this to be a critique to the podling, I'm rather trying to prevent what happened to Jakarta in the past: many disconnected subprojects under an umbrella PMC with little community glue in-between them. This is not an issue for the Incubator IMO, but if ever of the board and how it manages the PMCs with the chairs and how it pushes project policies. Project PMCs are self-governing, and the Incubator is here only to incubate for them only under their request. It's part of judging if the Incubation is succesfull. For example, for Lenya I'm wondering if Cocoon is the right place for them, as I've not seen much involvment. I'll wait and see, but for now I would not vote for exit as there is not much integration. As a member of the Cocoon, or Incubator PMC? Is there a difference? -- 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: Another cut at roles and responsibilities
Nicola Ken Barozzi wrote: It's about having an "elder" shepherd mentoring the main shepherd, and possibly requiring at least two people helping in Incubation. What do others think about this? Over-regulation. -- 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: Another cut at roles and responsibilities
Berin Lautenbach wrote: Would be great if you could have a read through the new version of http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings I'm hoping that it is something that will work. I've actually got it such that the Shepherd reports to both. The Sponsor is someone who helps out everywhere, but has no *formal* responsibility. It's a read well-worth it. Congratulations, Stephen and Berin. I'm slowly starting to believe in this concept. -- 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: Exit Criteria
Berin Lautenbach wrote: > > I've put something slightly different into the IncubatorMussings > document. I've said that the Incubator PMC *recommends* to the > Sponsoring Entity (the receiving PMC) that something has completed, > needs to continue or fails. no, i don't think so. the incubator is the sole arbiter of whether the podling has met the criteria of being a viable asf entity. if the original requesting project no longer wants it, that doesn't mean the podling has failed in its test of asf-ness; it just means the project doesn't want it any more. and at that point, i think it would be up to the podling to say what they'd like to do, and to the other projects to say whether they would accept it. if none do, and the podling wants to sytay at asf, then i think it should go to the board to consider creating a new tlp for it. -- #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
On 9/23/2003 5:31 AM, Nicola Ken Barozzi wrote: There is only one point that I have different in my mind and that is IIUC addressed there. It's about having an "elder" shepherd mentoring the main shepherd, and possibly requiring at least two people helping in Incubation. I think that there are situations where having an "elder" shepherd may be useful, but I would make it optional rather than mandatory. Remember that shepherds are ASF Officers or ASF Members here. These folks are supposed to have a clue about the ethos of the ASF. Once we have a clear checklist of entry and exit criteria, I think that people will be able to find their way. JMHO. Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
On 9/23/2003 5:29 AM, Berin Lautenbach wrote: Would be great if you could have a read through the new version of http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings I'm hoping that it is something that will work. I've actually got it such that the Shepherd reports to both. The Sponsor is someone who helps out everywhere, but has no *formal* responsibility. Berin, Excellent job here! Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
Nicola, > > Would be great if you could have a read through the new version of > > http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings > Done. It's *very* well writtem :-) > There is only one point that I have different in my mind and that is > IIUC addressed there. > It's about having an "elder" shepherd mentoring the main shepherd, and > possibly requiring at least two people helping in Incubation. Berin's document reflects his perspective as a Sponsoring Entity. As written by Berin, the Incubator PMC is responsible for "acceptance and oversight", "guidance and ensuring [application of ASF practices]", and "regularly evaluating" the podling. However, the only individual identified in the document as responsible is the Shephard chosen by the Sponsoring Entity, and accepted by the Incubator PMC. There is a check and balance there. As someone who has seen multiple incubations, you feel that there is an expertise related to incubation held by people who have devoted time to going through this process previously, and you would like to see that expertise leveraged for the benefit of the podling and the ASF. If the Incubator PMC feels, in the course of exercising its duties, that more than oversight is necessary in a given instance, e.g., that the Shephard could use some help, there is nothing that prevents the Incubator PMC from taking that, or other, action to help out. It is just less formal. Berin, does that reflect your intent? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Berin Lautenbach wrote: Would be great if you could have a read through the new version of http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings Its looking good. One point concerning the description of the Sponsoring Entity. I currently includes a sub-heading "Responsibilities of the Sponsoring Entity". The content is basically describing responsibilities of the Shepherd. It would read better if this section were removed and the respective responsibilities integrated with the definition of Shepherd. Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XMLBeans on Apache Wiki home page
Question. Is there any issue with a link to XMLBeansProjectPages being on the Apache Wiki home page? If so, would it go under the XMLProjectPages or under some new IncubatorProjectPages? thx, rem
RE: XMLBeans on Apache Wiki home page
> Is there any issue with a link to XMLBeansProjectPages being > on the Apache Wiki home page? Go ahead and at it here: http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheIncubatorProjectPages. That is linked off of the Wiki home page. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exit Criteria
On 9/23/2003 12:10 AM, Nicola Ken Barozzi wrote: Ted Leung wrote: 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) How do you assess that? Are we sure 50% is not too much? Will it take too much time? For demonstrate an active and diverse development community - its one of those that has an "I'll know it when I see it test". As far as the 50% figure, I have my reservations about the amount of time that it will take, particularly in the case of something like XMLBeans, but some people were vocal about this figure in the past. You can call it the "anti-big-company" rule. 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. Yup, this is important. We now have Apache projects that do not follow this rule sometimes and have to be reminded every time, so it's a good idea. Part of the goal with incubation should be to raise the level of new projects, so that they benefit from the experience of all. That's all I was trying to do there (requriment on minimum number of such releases?) two? That's two "Not official ASF releases" ;-) Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exit Criteria
Nicola Ken Barozzi wrote: For example, for Lenya I'm wondering if Cocoon is the right place for them, as I've not seen much involvment. I'll wait and see, but for now I would not vote for exit as there is not much integration. As a member of the Cocoon, or Incubator PMC? Is there a difference? Naah - it was just a rhetorical question. ;-) I agree with you on Lenya's situation. See my remark on functional vs technological projects. I guess the same would happen if we start incubating a PetShop, WikiEngine, EAI tool and whatnot. The problem is that functional use-cases and business customer requirements are hard to fit into a design that appeals to framework and tools geeks, since they are bound to have a different view on the design of such apps, partly due to the NIH-syndrome, but also because business customer-facing design decisions are largely arbitrary. -- 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: Software License grant - where can I find the form?
Rodent of Unusual Size wrote: Noel J. Bergman wrote: Sam, AFAIK, software-grant.txt is it. The license-grant appears related to the original license grant for the ASF. Seems to me that the software grant ought to be PDF'd nicely like the others, and put along side the CLA, so that outside projects have it ready to use when submitting to the Incubator. there was a reason identified for *not* doing this. if you can wait until i come back from lunch and some errands (a couple of hours) i'll see if i can dig it up. i, too, would like it to be publicly available, but i think we need to make sure this concern, whatever it is, has been addressed first. Ping? - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
On Monday, September 22, 2003, at 07:48 AM, Nicola Ken Barozzi wrote: robert burrell donkin wrote: i (for one) would not feel able to support any vote to push any sub-project out of jakarta (though i do think that this would be a good thing for more than one sub-project.) i think that any push needs to come from a higher level with more moral authority. Naaa, a post with "why don't you... the reason is that... you decide" can be sent by anyone. that's not exactly going to push anyone is it? as you well know, a single post like that from a nobody is unlikely to achieve anything. the move towards top level projects is driven just by the ASF membership - there appears to be no appreciable level of demand from jakarta developers. they need to be convinced. what i find unfair is that some well respective ASF members criticize the jakarta pmc for failing to be sufficiently persuasive when they are not willing to act to help the situation themselves. IMHO positive messages from well respected members who have helped communities to move from sub-project to project status will have far more impact than anything that the jakarta pmc could do (short of threatening closure of the project unless it finds a top level project willing to accept it). There is a "trick" though in making the projects ask for it: make committers in Jakarta have all blanket CVS access. This way projects that want to keep their "own" community must ask to go top level for it. Dunno how the thing is going now though, I got tired of waiting for some action and left the PMC. if no one else has the spare energy (and the flame proof boots ;) required to encourage sub-projects to move to tlp status and you aren't willing to volunteer yourself then no action will be taken. Listen dude, I asked the Ant project myself to move, and got flamed for that. I lobbied some James guys to do the same. I brought the discussion forward on the community mailing list. I took part in the Cocoon project going TL. If there is someone here that has pushed projects top-level, that's me. you've persuaded projects of the advantage of going top level. cool. ok, you've now decided that you're fed up of persuading people. i can understand that. it's a thankless task. but IMHO this isn't what pushing projects means. pushing projects means threatening them with an ultimatum - either find some top level project that's willing to accept you or we close your repository and remove your commit rights. IMHO it's unfair to expect the jakarta pmc to put this kind of pressure on sub-projects. this can only come from the membership through the board. i'm sad that you decided to leave rather than take on (at least some of) this task. I'm sad that my last proposal for pushing projects top-level did not find approval. I don't know you, but I would not take on a task that others do not agree with. it's a pity that you didn't stay around to talk about your proposal or put it to the vote. maybe we misunderstood your proposal: if you had said "i'll volunteer to help every jakarta sub-project to realize that they want their own top level project" then i think the response would have been different. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exit Criteria
Ted Leung wrote: >On 9/23/2003 12:10 AM, Nicola Ken Barozzi wrote: >> Ted Leung wrote: >>> 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) >> How do you assess that? Are we sure 50% is not too much? Will it take >> too much time? > For demonstrate an active and diverse development community - its one of > those that has an "I'll know it when I see it test". > As far as the 50% figure, I have my reservations > You can call it the "anti-big-company" rule. Diversity is good on the grounds that (a) no one company can control the direction of an ASF project, and (b) the fate of one company doesn't dictate the fate of the project. I see it as a Catch-22 in some cases, and I don't know of any ready-made solutions, but hopefully others have good ideas. The more widespread the project's appeal, the better it reaches out to other communities, the more likely it is to attract a more diverse Committer base. I have two interim suggestions that don't fix the lack of diversity, but do address two potential concerns. First, the project must have at least N independent committers, as you have already put on your list. Second, limit the influence of the corporate committers on the PMC. That could be controversial. Lastly, an observation: if there are technical disputes, any one committer, independent or otherwise, can veto changes that he or she doesn't feel are in the best interests of the project. >>> Release plans are developed and excuted in public by the community. >> Yup, this is important. We now have Apache projects that do not follow >> this rule sometimes and have to be reminded every time, so it's a good >>idea. >>> (requriment on minimum number of such releases?) >> two? >That's two "Not official ASF releases" ;-) LOL Call them "Dress Rehearsals" :-) I agree that they should learn the process until it becomes a habit. I don't believe that an project in the incubator should be allowed to make an official release because they have not cleared whatever issues are keeping them in the incubator, and not a part of the Foundation proper. Upon further reflection, it does occur to me that it is possible for the podling to go to the Incubator PMC under appropriate circumstances, and request that the Incubator PMC vote to make a Release. I do not believe that it should be a common practice, but processes should allow for exceptions and human judgment. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Sub-project -> TLP
Robert, I renamed the thread, which has nothing to do with the Directory project, and really no longer belongs here, but here it is. Perhaps community@ would be better? > if you had said "i'll volunteer to help every jakarta sub-project > to realize that they want their own top level project" then i think > the response would have been different. Why? What do you think it would be different? What do you see as the actual and/or psychological barriers that prevent mature projects from becoming TLPs? --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exit Criteria
On Tuesday, September 23, 2003 2:01 PM, Noel J. Bergman wrote: (requriment on minimum number of such releases?) >>> two? >> That's two "Not official ASF releases" ;-) > > LOL Call them "Dress Rehearsals" :-) I agree that they should learn > the process until it becomes a habit. > > I don't believe that an project in the incubator should be allowed to > make an official release because they have not cleared whatever > issues are keeping them in the incubator, and not a part of the > Foundation proper. Upon further reflection, it does occur to me that > it is possible for the podling to go to the Incubator PMC under > appropriate circumstances, and request that the Incubator PMC vote to > make a Release. I do not believe that it should be a common > practice, but processes should allow for exceptions and human > judgment. I've suggested [1] to the XMLBeans community that they should release both minor and major releases as often as they like (as appropriate given the state of the code and community consensus); however, while they are in the Incubator, they must ensure these releases are clearly labeled as being incubator releases, which are not fully endorsed by the ASF (see what I have in mind in [2]). Does this fit with what you had in mind? Cliff [1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=145 [2] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=2000 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sub-project -> TLP
Noel J. Bergman wrote: Robert, I renamed the thread, which has nothing to do with the Directory project, and really no longer belongs here, but here it is. Perhaps community@ would be better? if you had said "i'll volunteer to help every jakarta sub-project to realize that they want their own top level project" then i think the response would have been different. Why? What do you think it would be different? What do you see as the actual and/or psychological barriers that prevent mature projects from becoming TLPs? As a committer on a (hopefully :-) mature Jakarta subproject (Struts), I think there's another dimension here. Can we articulate the advantages of becoming a TLP in such a way that the idea sells itself? Marketing is about creating demand, not browbeating or threatening people into acceptance. Off the top of my head ... advantages include: * Your own apache.org website, mailing lists, etc. (although this is more a marketing/perception issue than a real technical one -- a bookmark doesn't care if its "foo.apache.org" or "jakarta.apache.org/foo"). * Your own representation to the ASF board. This is probably the most important single factor, to the extent that you can influence overall ASF policies more directly. * Within the scope of the board resolution that authorized your TLP, you can create your own sub-projects, to better scale to a larger population of involved developers. There are also potential negatives, not the least of which is the amount of process related work being asked of people who just want to use their available open source time on code. Overall, I suspect the lack of a stampede towards TLP-hood has more to do with lack of knowledge of the advantages, or indifference towards them, and possibly fear that even mature subprojects that want to graduate will have to undergo the incubation process :-), than it does anything else. --- Noel Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sub-project -> TLP
On Tuesday, September 23, 2003, at 10:16 PM, Noel J. Bergman wrote: Robert, I renamed the thread, which has nothing to do with the Directory project, and really no longer belongs here, but here it is. Perhaps community@ would be better? i'm a bit fed up with this the whole thread. i now seem to spend my spare time writing emails rather than code :( if you had said "i'll volunteer to help every jakarta sub-project to realize that they want their own top level project" then i think the response would have been different. Why? What do you think it would be different? i think that the response would have been different had nicola volunteered to persuade all the jakarta sub-projects that they would benefit from moving out of jakarta. he did not. nicola's proposal was that jakarta pmc politely ask almost all sub-projects (except jakarta-commons) to leave jakarta. (he didn't realize that the board seem to be strongly in favour of moving jakarta-commons out of jakarta as soon as possible.) so if nicola's proposal had been accepted, jakarta would have been left with just a web site. but it was more of a eulogy or vision for the future rather than a serious proposal. it didn't even have a VOTE prefix. i'm not surprised that it was largely ignored - especially since nicola resigned from the pmc soon after posting rather than fighting for his vision. What do you see as the actual and/or psychological barriers that prevent mature projects from becoming TLPs? i'm not sure there is a single reason. jakarta is very large and very diverse. i have some theories: some sub-projects are just taking their time. sub-projects have their own goals and priorities. jakarta is a club that is *very* hard to get into. sub-projects which have shed blood and tears to gain admittance are likely to take a lot of persuading that they should leave. some sub-projects are viable only as part of a large community. unless the board supplies a suitable environment for them they will not volunteer to leave jakarta. other sub-projects are thriving in the environment that jakarta provides. in this case, it seems like a big risk to be asked to leave all the hard work behind and start again from scratch in a top level project. other sub-projects are unlikely to want to leave whilst similar sub-projects remain at jakarta. being a jakarta product is worth quite a lot. being a jakarta product means quality. this impression has been repeated many times by users, journalists and publishers. jakarta has been an early adopter ways of java development (test driven development, continuous integration thanks to gump, extensive code review) that are now gaining wide spread acceptance. there also seems to be a new generation for whom jakarta is a bigger name than apache. (this seems a little ironic to me since in the early days, jakarta was often criticized for relying on the reputation of apache.) why should sub-projects dream of leaving? of course, stefano's answer was that there's no reason why users should care how the ASF happens to manage it's projects - you can still be part of jakarta without being managed by the jakarta pmc. but this is hard to explain to people... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Getting the distribution onto a download site somewhere ...
On Monday, September 22, 2003, at 07:54 AM, Jochen Wiedmann wrote: Noel J. Bergman wrote: See http://httpd.apache.org/dev/release.html for the httpd project's guidelines. They use the term "release" the way that Jakarta projects will use the term "build", but the overall effect is the same. See http://jakarta.apache.org/site/binindex.cgi for a description of the guidelines used by Jakarta and related projects. 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. FWIW my experience at jakarta has been that momentum is much more important than Releases. in fact, some of the most talked about new java products here at apache (maven, jelly, geronimo) have never had a Release. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Sub-project -> TLP
"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote on 24/09/2003 08:39:08 AM: [snip] > As a committer on a (hopefully :-) mature Jakarta subproject (Struts), I As a committer on top level and not top level projects: > think there's another dimension here. Can we articulate the advantages > of becoming a TLP in such a way that the idea sells itself? Marketing > is about creating demand, not browbeating or threatening people into > acceptance. Off the top of my head ... advantages include: > > * Your own apache.org website, mailing lists, etc. (although this is more > a marketing/perception issue than a real technical one -- a bookmark > doesn't care if its "foo.apache.org" or "jakarta.apache.org/foo"). This is a vanity/ego issue from what I can tell. I think maven had as many users inside jakarta as out. > * Your own representation to the ASF board. This is probably the > most important single factor, to the extent that you can influence overall > ASF policies more directly. As a member of a top level project, I don't see that I can influence ASF policies any more than if the project was inside Jakarta. This seems to be the realm of ASF members, rather than committers. > * Within the scope of the board resolution that authorized your TLP, > you can create your own sub-projects, to better scale to a larger > population of involved developers. I'm not sure how this is a benefit to the project committers who are interested in writing code. > There are also potential negatives, not the least of which is the amount > of process related work being asked of people who just want to use their > available open source time on code. I really haven't seen this as part of being a TLP. There has been very little 'overhead'. > Overall, I suspect the lack of a stampede towards TLP-hood has more to > do with lack of knowledge of the advantages, or indifference towards > them, and possibly fear that even mature subprojects that want to > graduate will have to undergo the incubation process :-), than it does > anything else. I also feel there's a "don't fix what isn't broken" attitude most of us have. If it works ok now, why change. The issue of Jakarta's lack of oversight doesn't impact on the individual projects. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exit Criteria
On Tue, 23 Sep 2003, Noel J. Bergman wrote: > > You can call it the "anti-big-company" rule. > > Diversity is good on the grounds that (a) no one company can control the > direction of an ASF project, and (b) the fate of one company doesn't dictate > the fate of the project. But also that the fate of the company doesn't depend on the fate of the project. I can envision a company using this mechanism to get free labor for their project, and then going under when the project doesn't do so great. This would be a great shame, and would reflect rather badly on everyone. -- Rich Bowen - [EMAIL PROTECTED] There's more than one way to eat a rhesus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Exit Criteria
> while they are in the Incubator, they must ensure these releases are > clearly labeled as being incubator releases, which are not fully > endorsed by the ASF > Does this fit with what you had in mind? Works for me. But you should make sure that it works for the Incubator PMC. As I understand from Nicola Ken's and Ken's responses, they thought it looked good. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Sub-project -> TLP
Craig, All good points. Another is that some projects have a natural synergy, and fit well together. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
Hi, Berin. All, On Mon, 22 Sep 2003 11:18:44 +1000 (Subject: Re: ASF member role - accountable to whom) Berin Lautenbach <[EMAIL PROTECTED]> wrote: > > I'd like to say, "Those who would write articles in the newsletter > > draft, are worthy to become members, because they really care > > for the foundation as a whole". Also, I'll give an announcement > > (=call) at members@ not community@ in the next time. > > The above argument starts to get dangerously close > to the old umbrella argument. "I carry my > umbrella when it's raining, therefore if I am > carrying my umbrella it must be raining". So I > might agree that people who put a lot of effort > into a newsletter are good ASF people. But the > fact that others are not is completely meaningless. Well, of course, I do not intend such kind of things. To tell the truth, I talked about the participation into the OSS communities from my country, with one of the ASF members , the other day (in private mail). This could be absolutely related to the things mentioned above. I wrote: " Plus: Japanese companies use the method of scoring by deducting points not by adding points, when judging the successors and measuring the employees' wages. This is a big problem that the Japan-Society has. (Probably this is one of the problems which can be spotlighted when talking about the japanese developers in opensource projects)" Mr. X wrote with an astonishment: " Fuuuck! You are touching a nerve here! The opensource world works *exactly* the opposite: you *earn* points when you make mistakes and you publicly apologize. (because we know you will make mistakes, otherwise how do you learn?) This *covering my ass to show I don't make mistakes* attitude is strongly disliked in healthy communities. if the japanese society works the other way around, it will be impossible for them to earn points because they will do everything to prevent them to show the mistakes they make. Which will result in being ignored, another thing that would scare them away because they don't know that the values are reversed! Wow, I have to take notes on this. This is really important." -- I wanted to mention that the "Apache Newsletter" could become one of the "adding points" measurements, Not "deducting points" measurements. In fact, those who can write articles for XX (sub)project can overview the XX (sub)project. This would really help the board members (and PMCs) to overlook a large number of projects within the Apache.Org, I am sure. -- I *DO* sympathize with the vision mentioned above (from Mr. X) and want to keep such minds. Really *Open* mind. "An ounce of practice is worth a pound of theory.", they say. ... I want to put his/her teachings into practice, here in apache.org. On the other hand, Japan itself is now suffering from the "bureaucratism" disease of society, because anyone do want to hide their mistakes and do not raise their hands. However, I'd been really afraid of the *abuse* of the word "meritocracy" because it could be interpret as "eliticism" in japanese, furthermore "eliticism" can easily be associated with the "bureaucratism". * NOTE: "bureaucratism" hates the "NEW" / "MODERN" ideas. Always *people say "NO". ... Lack of "nobless oblige" Yeah, of course I am one of the Japanese fellows and I do want to hide my mistakes. Yes, now the time has come. I have many other things to be done. Also, to be honest, I am still struggling with and wandering off how I should behave in this society. > Cheers, > Berin Thank you :) I hope to hear from you in the next newsletter. Sincerely, --- 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]
Getting more newsletter content
Tetsuya, Most people just want to write code or discuss code. If you want articles, I hate to say it, but you would generally lucky to get someone to send you an e-mail about the latest interesting thing with their project, and you'd have to edit it into something resembling an blurb. Occasionally, you'll get lucky. And you may find some projects that are particularly happy to provide copy. I suspect that the Geromino project would be one of those. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
> From: "Noel J. Bergman" <[EMAIL PROTECTED]> > > It's about having an "elder" shepherd mentoring the main shepherd, and > > possibly requiring at least two people helping in Incubation. > As someone who has seen multiple incubations, you feel that there is an > expertise related to incubation held by people who have devoted time to > going through this process previously, and you would like to see that > expertise leveraged for the benefit of the podling and the ASF. If the > Incubator PMC feels, in the course of exercising its duties, that more than > oversight is necessary in a given instance, e.g., that the Shephard could > use some help, there is nothing that prevents the Incubator PMC from taking > that, or other, action to help out. It is just less formal. > > Berin, does that reflect your intent? Yes it does indeed reflect my original intent. You are reading my mind :>. So, having read the other e-mails, it seems to me that we can take the same approach as with the sponsor. This is an important potential role, but one that is not "formally" locked into the processes and procedures. So under the Incubator PMC section, I can (and will) add some text around "for particularly complex incubations, or in cases where the Shepherd needs assistance, the Incubator PMC may choose to provide assistance, possibly through assigning another experienced Shepherd to assist in the process" - or something similar and better worded. Let me know if there are any objections, but I believe that this is a good way forward. 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: Re: Another cut at roles and responsibilities
> From: Stephen McConnell <[EMAIL PROTECTED]> > One point concerning the description of the Sponsoring Entity. I > currently includes a sub-heading "Responsibilities of the Sponsoring > Entity". The content is basically describing responsibilities of the > Shepherd. It would read better if this section were removed and the > respective responsibilities integrated with the definition of Shepherd. Ahh yes. Fair call :>. I will do so. 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
Berin Lautenbach wrote: From: "Noel J. Bergman" <[EMAIL PROTECTED]> It's about having an "elder" shepherd mentoring the main shepherd, and possibly requiring at least two people helping in Incubation. As someone who has seen multiple incubations, you feel that there is an expertise related to incubation held by people who have devoted time to going through this process previously, and you would like to see that expertise leveraged for the benefit of the podling and the ASF. If the Incubator PMC feels, in the course of exercising its duties, that more than oversight is necessary in a given instance, e.g., that the Shephard could use some help, there is nothing that prevents the Incubator PMC from taking that, or other, action to help out. It is just less formal. Berin, does that reflect your intent? Yes it does indeed reflect my original intent. You are reading my mind :>. I get it too now ;-) So, having read the other e-mails, it seems to me that we can take the same approach as with the sponsor. This is an important potential role, but one that is not "formally" locked into the processes and procedures. So under the Incubator PMC section, I can (and will) add some text around "for particularly complex incubations, or in cases where the Shepherd needs assistance, the Incubator PMC may choose to provide assistance, possibly through assigning another experienced Shepherd to assist in the process" - or something similar and better worded. Let me know if there are any objections, but I believe that this is a good way forward. +1 Thanks guys, this thing is finally moving big time! :-D -- 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
robert burrell donkin wrote: On Monday, September 22, 2003, at 07:48 AM, Nicola Ken Barozzi wrote: robert burrell donkin wrote: ... Listen dude, I asked the Ant project myself to move, and got flamed for that. I lobbied some James guys to do the same. I brought the discussion forward on the community mailing list. I took part in the Cocoon project going TL. If there is someone here that has pushed projects top-level, that's me. you've persuaded projects of the advantage of going top level. cool. ok, you've now decided that you're fed up of persuading people. I was not fed up of persuaing. I am fed up of persuading the PMC that I want to persuade... bah! i can understand that. it's a thankless task. but IMHO this isn't what pushing projects means. pushing projects means threatening them with an ultimatum - either find some top level project that's willing to accept you or we close your repository and remove your commit rights. IMHO it's unfair to expect the jakarta pmc to put this kind of pressure on sub-projects. this can only come from the membership through the board. Hey, this is your view, and I have *never* said that. I call that *kick* out, not push. i'm sad that you decided to leave rather than take on (at least some of) this task. I'm sad that my last proposal for pushing projects top-level did not find approval. I don't know you, but I would not take on a task that others do not agree with. it's a pity that you didn't stay around to talk about your proposal or put it to the vote. How much time do I need to wait for it. It was not the first time it was said, and how could I discuss a proposal that basically got no comment (one negative actually)? Besides, I don't usually put to vote a proposal that recieves no positive replies. maybe we misunderstood your proposal: if you had said "i'll volunteer to help every jakarta sub-project to realize that they want their own top level project" then i think the response would have been different. We don't all have the same way of expressing ourselves, and given the Jakarta projects I had already helped our you would have known. As I said in my farewell note, I went away from Jakarta only marginally for this. The real reason is that having helped the projects I follow go top-level, almost nothing remained at Jakarta. -- 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: Exit Criteria
Noel J. Bergman wrote: >Cliff Schmidt wrote: > while they are in the Incubator, they must ensure these releases are clearly labeled as being incubator releases, which are not fully endorsed by the ASF Does this fit with what you had in mind? Works for me. But you should make sure that it works for the Incubator PMC. As I understand from Nicola Ken's and Ken's responses, they thought it looked good. I put up a Wiki page for it here: http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorReleaseManagement -- 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: Exit Criteria
Ted Leung wrote: On 9/23/2003 12:10 AM, Nicola Ken Barozzi wrote: Ted Leung wrote: 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) How do you assess that? Are we sure 50% is not too much? Will it take too much time? For demonstrate an active and diverse development community - its one of those that has an "I'll know it when I see it test". It's probably easier to define as not inactive. As far as the 50% figure, I have my reservations about the amount of time that it will take, particularly in the case of something like XMLBeans, but some people were vocal about this figure in the past. You can call it the "anti-big-company" rule. Exactly my thoughts. Reservations about the time but agree in principle. ... (requriment on minimum number of such releases?) two? That's two "Not official ASF releases" ;-) ;-) -- 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 ...
On 9/23/2003 3:51 PM, robert burrell donkin wrote: FWIW my experience at jakarta has been that momentum is much more important than Releases. in fact, some of the most talked about new java products here at apache (maven, jelly, geronimo) have never had a Release. My experience talking to non-ASF's is that there's a certain degree of frustration because there hasn't been a release. Some people just wait for them. It's irrational, in some ways, I know... FWIW Ted - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
