Re: Posting and tracking project tasks
Noel J. Bergman wrote: To a certain extent, the incubator is evolving, too. If evolving procedures that are not being disseminated, that's one problem. I propose that a good way to address this situation will be to make active use of the new JIRA install, Serge and I have scheduled for next Thursday. +1 This is a really excellent idea. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disclaimer text for incubated projects
Tetsuya Kitahata wrote: From my point of view, "disclaimer" page would be enough and the best "alternative". +1 -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Disclaimer text for incubated projects
Berin Lautenbach wrote: is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the . Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF. Berin: I have a problem with the last sentence in the above paragraph as it implies a association between the incubator and project code completness and/or stability. Here is a suggested replacement that eliminates the concern: is an effort undergoing incubation at the Apache Software Foundation (ASF), sponsored by the . Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. As such, the project has not been formally endorsed by the ASF. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: incubation disclaimer and infrastructural reshuffle
Leo Simons wrote: Sam Ruby wrote: I would go further. Essentially, a release by a podling would require a vote by the incubator PMC to do so. a release by *any* project requires its supervising PMC to vote it through. Since for podlings, the supervising PMC is by definition the incubator PMC, you're not going anywhere spectacular :D - LSD Roy wrote recently: Ok - going with Apache tradition - its not the PMC that makes the decision of a *release*. BZZZT. According to the bylaws, the only people authorized to make decisions on behalf of the ASF (including the decision to release code to the general public) are officers or the PMC responsible for the project. All other votes are to be ignored or considered advisory only, and no I don't care how long some of our umbrella projects have been ignoring that fact. Roy BZZZT, BZZZT, the above statement presumes that "release" and "publication" are one and the same. The distinction between a vote to "release" and a vote to "publish" is in my option an import aspect of active community based decision making. Communities vote to release, and PMCs demonstrate responsible oversite through control of “publication. The people who care about the subject make a collective decision to release something. That decision is not binding on Apache. All it does is establish a recommendation to a PMC to publish. A PMC can then endorce (or not) a release recommendation by the community. This approach reflects a respect for the *decisions* of the community while delivering the appropriate due-diligence by the responsible PMC. Stephen. - 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: Disclaimer text for incubated projects
David Jencks wrote: On Saturday, October 4, 2003, at 03:20 AM, Berin Lautenbach wrote: == Releases == As podlings are not yet fully accepted as part of the Apache Software Foundation, any software releases (including code held in publically available CVS) made by Podlings will not be endorsed by the ASF. Podlings in Incubation SHALL NOT perform any releases of software without the explicit approval of the Incubator PMC. To me, one possible reading of these two statements is that explicit approval of the Incubator PMC is required for any change to code held in publicly available CVS. I doubt that is what anyone intends. What is intended and what happens are two very different things. Apache is publishing incubator code via CVS. Restrictions above and beyond that are accademic and simply unnecessary overheads on projects under incubation. I would suggest the the incubator PMC address due-diligence at the appropriate level. In this context the appropriate level is the license. (a) if a new project is importing code it should import it under an Incubator variant of ASL 1.1 with appropriate disclaimers (b) if (a) is not satisfied - then the repository is not available to the public - period - simple (c) let the project publish what it wants providing it is consitent with the license Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal: Sponsor becomes Mentor
Nicola Ken Barozzi wrote: The name "Sponsoring Entity" is wierd, and the more I think of it, the more it seems artificial. What we need is something that sponsors the project, and will accept it, and someone that mentors the project, which are 2 concepts, not 3 as now. Nicolas: I'm +1 on the terminology and defintions below - but I'm just a little confussed on the above comment - 2 versus 3 as now. What is the third role that is implicity dropped? Steve. Hence I propose that we have: - Sponsor: the Apache entity (PMC) that sponsors the project and that will recieve it upon succesfull incuabtion. - Mentor: the Apache member or Sponsor PMC member that will assist in incubation. He will become part of the Incubator PMC. In this way we ensure that the currently defined Sponsor follows the project and that the Mentor is always pre-proposed by the candidate (so we don't need go hinting for it). What do you think? -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: projects "in" versus "entering" versus "affiliated with" the incubator
Rodney Waldhoff wrote: * I'd suggest the term "candidate" (as is used in Roles_and_Responsibilities) or "project" (as in "incubating [sub]project"), or even the term "pod", rather than the diminutive "podlet" in describing the "entity being incubated" +1 -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal: Sponsor becomes Mentor
Berin Lautenbach wrote: From: Nicola Ken Barozzi <[EMAIL PROTECTED]> The name "Sponsoring Entity" is wierd, and the more I think of it, the more it seems artificial. Yup. It was the best I could think of at the time :<. What we need is something that sponsors the project, and will accept it, and someone that mentors the project, which are 2 concepts, not 3 as now. Hence I propose that we have: - Sponsor: the Apache entity (PMC) that sponsors the project and that will recieve it upon succesfull incuabtion. - Mentor: the Apache member or Sponsor PMC member that will assist in incubation. He will become part of the Incubator PMC. The only issue then is that we loose the original concept of the sponsor. While the distinction between sponsor and sponsoring entity was artificial, I think it was useful. So the sponsor was the individual Apache member who would champion the cause of the candidate project with the relevant sponsoring entity, help the candidate through those initial stages and be a champion for the podling once it was accepted. We still need this role (at least prior to acceptance by a "sponsoring entity" or whatever we want to call it now) I think. However I like the idea of calling the "sponsoring entity" the sponsor, as it's more natural. For the purposes of documentation why not something like the candidate "champion" for the original sponsor idea? ++1 Cheers, Steve. 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] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proposal: Sponsor becomes Mentor
Noel J. Bergman wrote: Just wondering who the mentor is for the Directory Project? I would suspect that Noel is the official Sponsor however I have not seen any discussions concerning the projects mentor. AFAIK, Nicola Ken and I are doing that duty. Also wanted to check and see if there are any things (loose ends) still expected of the Directory Project such as documentation etcetera? I just posted a "new project" form for people to review. And it seems from other messages that Nicola Ken wants to postpone new project adoption until he finishes the web site renovation, since that includes the new STATUS form. There are a bunch of things that the directory project could be doing to things established under Apache. Is the web-site really a prereq for this? As far as I can see the adminstrative stuff is well in hand and the operational are now subject in focus - cvs, lists, etc. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common naming accross policy/process/roles
Berin Lautenbach wrote: Leo Simons wrote: Hi gang, Okay, okay, I'm exaggerating. Its real cool there's people volunteering to write all this stuff, and the drafts are not *that* formal. I'm just suggesting we make it easy for ourselves and don't try to write "perfect" and "waterproof" docs. We just need "good enough". back to my corner! :>. But I'll bite. It's because you might be clear, the PMC might be clear and the board might be clear on what incubation is, but it is still truly astounding how much argument can be generated *every time* a project comes into incubation over items that should be simple and easy, and that everyone has agreed on in the past! I've also been involved in standard review processes in other lives, and it also amazing (but understandable) how much bitterness and heat can be generated by different projects/products following different review paths. If we document the requirements as we create them then firstly it's easier for those on the PMC down the track, and secondly there is something that everyone can point to and say "this is what was done in the past". It's almost due-diligence on behalf of the incubator. It has been given a task by the board. How can it show it is performing that task adequately in each case if it cannot go back to a normative reference? Well said! Steve. Cheers, Berin - 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: Common naming accross policy/process/roles
Nicola Ken Barozzi wrote: Berin Lautenbach wrote: Nicola Ken Barozzi wrote: I also want to make sure that we well know where things stand in every incubation moment, as there has been enough confusion withdouble-triple PMC concurrent votes. +1 That said, I also think that we need *one* document to guide us, and all the rest should be simply docs that complement it as HOWTOs. +1 - although whether they are HOWTOs or some other format would I think depend on appropriateness of content. Any objections to my changing the "Incubation" heading on the main side bar down into "Incubator Policy" and "Incubator Guideance". The first has an intro page discussing what the policy is for and a single document (the policy) and the second has the other documents with an intro page discussing what they are for? Hmmm... policy... guidance... really, I may seem paranoid, but they don't spark a clear distinction in my head. Policy == rules of the game. Guidence == suggestions on how to play the game I want to see a single document, not more. Just one. Call it Process, call it Policy, call it Rules, but just one. Proposal: - add a HOWTO section - rename Process_Description to Incubation_HOWTO - make a HOWTO doc from each paragraph of ROLES_AND_RESPONSIBILITIES Why an I so keen on "HOWTO"? Because HOWTOS are well known to be non-normative. I disagree. A general guidance document is talking about a typical incubation process and is targeted towards someone who is thinking about involvement in such a process. Policies are the set of rules that provide the framework for consistency - its the rules that PMC and incubator project participants are working under between comencement and exit. Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common naming accross policy/process/roles
Berin Lautenbach wrote: If we want to make sure something is non-normative, it's very simple (and appropriate) to put a rider paragraph in it stating that where it conflicts with the policy, the policy over-rides. That's a common approach and gets over having to worry too much about what names we use. +1 In particular, I like calling the process description a "Process Description" because that is exactly what it is. +1 Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: status of FTP Server project
[EMAIL PROTECTED] wrote: Thanks. I need to be able to use the FTPServer within my process (for junit-based testing purposes). Is there a way I can do that ? Here is an example [1] of a junit-based test that includes an embedded container. The test code that pulls in named services and does what it wants. Working examples are available for the test cases, and if you post a note over on Avalon - someone there has a working ftp server block descriptor. Cheers, Steve. [1] junit test-case using embedded container http://avalon.apache.org/merlin/starting/advanced/unit/index.html From reading the Phoenix docs, I would have start up the Phoenix server with FTPServer deployed (as a block). This would be an impediment. Any pointers would help. thanks, raghu ps: I need to be able to ftp files (in junit tests) and do some verification. So, am exploring if I can use FTP Server as an in-memory service. Rana Bhattacharyya <[EMAIL PROTECTED]> 10/28/2003 11:35 PM Please respond to general T To: [EMAIL PROTECTED] cc: bcc: Subject:Re: status of FTP Server project Hi, The FTP server project is very much active. The code base is very much stable and the doc is also available (may not be very exhaustive). You can check the site http://incubator.apache.org/projects/ftpserver/ Thanks, Rana --- [EMAIL PROTECTED] wrote: Hello, I would like to know the status of the FTP Server project in terms of releases, timeline, usage docs etc. Also, are there any other alternative open-source Java-based FTP Servers out there ? thanks, raghu __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ - 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: [Possible Incubation] Apache Repo
Jason van Zyl wrote: On Sat, 2003-11-08 at 16:57, Roy T. Fielding wrote: I think that producing a single repository, or at least a set of mechanisms that allow a single storage facility to look like a repository with multiple interfaces, is a task for infrastructure and commons to work out (meaning that the people who have interest in such a thing will work together to minimize the cost to the ASF, both in terms of bandwidth and volunteer time, under the auspices of the people responsible for keeping us on the net). We don't need a separate group for that because it is an internal task, and there are no IP issues that require a trip through incubator. If there are additional software tools that might make useful Apache products and people to stoke the engines, then we should incubate those here as new projects. We just need a clear proposal. So if I understand this correctly the discussions on [EMAIL PROTECTED] should now be conducted on infrastructure where we are talking about the physical layout of the repository in a file system that is accessible via http. Small note - some of the participants on the [EMAIL PROTECTED] are discussing the actual requirements - which from my (and other) point(s) of view go beyond a file-system http protocol cut-and-dried implementation solution. Some consider this area to be much more than an HTTP download handler. In fact - if the scope of a repository model were limited to that then would would be missing a really big opportunity to do this in a way is of real value to multiple projects. Yes - you can assume some simplistic models down low - but hopefully this is not just about plumbing but also about addressing the requirements across different abstractions that will ultimately ensure that semantic assumptions are consistent across multiple repository-enabled applications. Just trying to clarify, is this correct? I hope not - it would not meet Avalon project requirements relative to repository-aware applications. I much prefer Roy's terminology "a single storage facility to look like a repository with multiple interfaces". Roy's statement *does* encompass the scope of requirements that I see as relevant. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Possible Incubation] Apache Repo
Roy T. Fielding wrote: Small note - some of the participants on the [EMAIL PROTECTED] are discussing the actual requirements - which from my (and other) point(s) of view go beyond a file-system http protocol cut-and-dried implementation solution. Some consider this area to be much more than an HTTP download handler. In fact - if the scope of a repository model were limited to that then would would be missing a really big opportunity to do this in a way is of real value to multiple projects. Yes - you can assume some simplistic models down low - but hopefully this is not just about plumbing but also about addressing the requirements across different abstractions that will ultimately ensure that semantic assumptions are consistent across multiple repository-enabled applications. The requirement is that ASF-owned software be distributed in an efficient (for our costs), reliable (for our maintainers), and user-friendly way. I would add one more requirement to above statement - namely "machine-friendly". There is an emerging requirement for application driven downloading that has the potential to significantly exceed the classic browser driven requirements that the ASF is addressing today. This has a direct impact on ASF costs, reliability, and utility. Feel free to consider any number of designs that may accomplish that requirement, but don't mistake a design opinion for a requirement. In particular, do not under any circumstances hold up implementation of the repository in pursuit of perfection -- a current implementation can be replaced at any time we see fit. Just trying to clarify, is this correct? I hope not - it would not meet Avalon project requirements relative to repository-aware applications. I much prefer Roy's terminology "a single storage facility to look like a repository with multiple interfaces". Roy's statement *does* encompass the scope of requirements that I see as relevant. Hello? Avalon project requirements do not encompass repository needs, and certainly do not define them. I don't think that I have suggested this. Avalon requirements deal with at least three layers of abstraction with respect to server side facilities. At the lowest level these requirements are rather close to the requirements you have outlined above. As far as second and third level requirements are concerned - these place functional requirements on the respective underlying facilities. My objective are rather simple - the basic facility should be a platform on which higher level facilities can be established without resorting to inefficiencies or workarounds. I should also point out that Avalon is not alone is this respect. Other projects are evolving towards repository-awareness. Identifying and collecting those requirements (many of which are project/application specific) are central to the delivery of a basic repository that is extendible to meet the needs of a significant usage model (in terms of ASF near-term impact). Avalon users might prefer a given interface to the repository, which I assume the Avalon community is more than capable of defining and developing on their own. Clearly yes. The work within Avalon has *done* exactly this and as a result - issues with current approaches have discovered and near term requirements have been identified. These aspects are the things that Avalon has to contribute to general model. I'll restate my earlier comment - the simplistic http + file layout assumptions "do not meet Avalon project requirements relative to repository-aware applications". In fact this is probably the key point - is this initiative about dealing with ASF download requirements, or, does this initiative address the emerging and potentially much larger repository aware application scenario? If this is simply about safe downloading then my assertions are clearly inappropriate. The commonality that is required by repository is determining the easiest way for all of our projects to provide artifacts and their authenticity-proving signatures such that the general public can get what they want, when they want, at a minimum cost to us. The tools that retrieve from the repository are not within its scope. Just to clarify - I completely agree that the development of tools *using* a repository are out of scope. However - these very same tools (at least those that exist today) are in my opinion *totally within scope* in terms of establishing near term requirements on the ASF and the repository solutions the ASF provides. Anything (and I do mean anything) beyond that is a software project that the ASF has not authorized, and certainly won't be developed here unless it is within a PMC. People are certainly welcome to propose such a project on incubator, but that is not the repository project. Repository is a task to be accomplished! Relative to present or short-term needs? Please note that this is not an argumentative question. It is a ques
Re: [Possible Incubation] Apache Repo
Jason van Zyl wrote: On Sat, 2003-11-08 at 21:47, Stephen McConnell wrote: Roy T. Fielding wrote: Small note - some of the participants on the [EMAIL PROTECTED] are discussing the actual requirements - which from my (and other) point(s) of view go beyond a file-system http protocol cut-and-dried implementation solution. Some consider this area to be much more than an HTTP download handler. In fact - if the scope of a repository model were limited to that then would would be missing a really big opportunity to do this in a way is of real value to multiple projects. Yes - you can assume some simplistic models down low - but hopefully this is not just about plumbing but also about addressing the requirements across different abstractions that will ultimately ensure that semantic assumptions are consistent across multiple repository-enabled applications. The requirement is that ASF-owned software be distributed in an efficient (for our costs), reliable (for our maintainers), and user-friendly way. I would add one more requirement to above statement - namely "machine-friendly". There is an emerging requirement for application driven downloading that has the potential to significantly exceed the classic browser driven requirements that the ASF is addressing today. This has a direct impact on ASF costs, reliability, and utility. I have challenged you to give me a scenerio that I can't satisfy with something like the current Maven repository. Instead you drone on ad nauseum about the theoretical. Let's have a concrete example. Jason: Look around you - take a look at things you involved with. I've already provided you with examples where the simplistic http over a maven style file system layout breaks. You have already provided me with the details of workarounds that the Maven platform incorporates to address these inefficiencies. There is a bigger picture. That picture is based on the collection of the requirements from repository-enabled applications - a set of requirements that you seem determined to reject. We can address those concerns with an open mind (a.k.a. a process of collaboration and mutual respect) or we could follow your approach to consensus building. While I'm very confident that you believe that your conclusions meet the present and near-term ASF requirement, I and others have different opinions. Should you wish to explore that area more constructively - I am very confident that a sustained effort by you towards the consideration and appreciation of the opinions and experience of others will go a long way in justifying your potential contribution to this subject. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Possible Incubation] Apache Repo
Jason van Zyl wrote: On Sat, 2003-11-08 at 23:18, Stephen McConnell wrote: Jason van Zyl wrote: I have challenged you to give me a scenerio that I can't satisfy with something like the current Maven repository. Instead you drone on ad nauseum about the theoretical. Let's have a concrete example. Jason: Look around you - take a look at things you involved with. I've already provided you with examples where the simplistic http over a maven style file system layout breaks. Which one's were those so we can record them here? Jason: I must confess that I am intrigued by your approach to collaboration! Following your assertion that I am droning on ad nauseum about the theoretical - combined with your follow-up with a request for specifics, I am obliged to conlude that your post concerning nauseum was simply an incorrect assertion on you part, or, your post is intended to establish an entry in a drone catalogue for the benefit of other like minded persons. While I appreciate that you are very busy working on initiative outside the scope and control of the ASF - I would *really* appreciate your guidance on this subject. Did you simply make a mistake, or are you intentions to propergate that mistake? Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Possible Incubation] Apache Repo
Jason van Zyl wrote: On Sun, 2003-11-09 at 00:35, Stephen McConnell wrote: Jason: I must confess that I am intrigued by your approach to collaboration! That's because you're at least as deficient as I am in the realm of collaboration. Neither you or I are any great shining examples of an ideal collaborator. You'll have to bear with me while I try to make ammends. I will try to bear with you. Oh really - take a break Jason! You idea of collaboration is very clear: http://lists.codehaus.org/pipermail/plexus-dev/2003q3/03.html My idea of collaboration is something *totally* different. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Possible Incubation] Apache Repo
Geir Magnusson Jr. wrote: On Sunday, November 9, 2003, at 02:50 AM, Stephen McConnell wrote: Jason van Zyl wrote: On Sun, 2003-11-09 at 01:08, Stephen McConnell wrote: Jason van Zyl wrote: On Sun, 2003-11-09 at 00:35, Stephen McConnell wrote: Jason: I must confess that I am intrigued by your approach to collaboration! That's because you're at least as deficient as I am in the realm of collaboration. Neither you or I are any great shining examples of an ideal collaborator. You'll have to bear with me while I try to make ammends. I will try to bear with you. Oh really - take a break Jason! You idea of collaboration is very clear: http://lists.codehaus.org/pipermail/plexus-dev/2003q3/03.html How does Plexus staying at Codehaus have any bearing on the notion of my collaboration? ROTFL - and you can't figure this out for yourself? I can't. Can you explain? Geir: I could - but to be honest I'm flat out on some really important stuff that I have to close. Can we come back to this in maybe at the end of this week? I'm sorry - but to answer your question properly and completely, I have to take into consideration several non-trivial aspect. I would simple prefer to do this properly and with due care. There are certainly some interesting social aspects that are worth documenting. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Multiple Mentors
Nicola Ken Barozzi wrote: Berin Lautenbach wrote: Nicola, I suppose the only slight reservation would be who is accountable? The old "Fred Bloggs is looking after that" can kick in. I think the Incubator PMC also wants to be able to hold people accountable for inubation activities. Gets harder with multiple people. If the accountable person fails, what can we do? Nothing. I think the accountable individual is an important criteria! If the accountable person fails - then the individual that represents the responsible PMC is accountable for ensuring that an accountable person is established (e.g. the individual is the Chair and the problem is locating a new Mentor). Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Multiple Mentors
Nicola Ken Barozzi wrote: Berin Lautenbach wrote: Nicola Ken Barozzi wrote: Berin Lautenbach wrote: Nicola, I suppose the only slight reservation would be who is accountable? The old "Fred Bloggs is looking after that" can kick in. I think the Incubator PMC also wants to be able to hold people accountable for inubation activities. Gets harder with multiple people. If the accountable person fails, what can we do? Nothing. Replace them! Too late, the bad is done. I want to minimize the possibility of it happening. I understand you point - but I think you focussing on the wrong place. The single point of accountability is IMO an important criteria - instead - I think what you should be looking at is the framework within which that reposibility becomes drop dead easy based on a framework of support. As a simple example - the process description establishes a sequence of events with responsibilities on a project to move itself out of incubation. The process will involve actions by the Mentors and the PMC and we don't these actions to be slowing down the works. An important aspect here is visibility of status and pending actions. This takes me back to the discussion about using JIRA - that's the sort of example where I could checkout open-actions on any incubator project - and based on that information I could jump in and help out. That results is greater community contribution to the process - less overhead oper Mentor - etc. etc. I.e. think more about facilities to enable members of the community to facilitate the exit of project under incubation. Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RT] Multiple Mentors
Nicola Ken Barozzi wrote: Stephen McConnell wrote: ... > An important aspect here is visibility of status and pending actions. This takes me back to the discussion about using JIRA - that's the sort of example where I could checkout open-actions on any incubator project - and based on that information I could jump in and help out. Click on the project you want to help out: http://incubator.apache.org/projects/index.html Are these files not so nice? Sure, if someone crafts up nicer status files I'll be happy to switch to them. As for using an issue tracker for this, single projects are free to do so, but it's their decision; what I have linked to is the baseline. Keep in mind that I can see the use of JIRA for an incubation iniative as something seperate for a projects own use of JIRA for bug tracking. An incubator view is all about actions facilitating exit (exit bugs). I bet that if incubator projects could push up and maintain their top three open actions - then more people could help out simply because they can see what a project is asserting at the topics it needs incubation help on. Ask the following question: * what are the top three things for FTP or Directory or Xxxx to move it towards exit I could spend an afternoon trying to put the answer together - and I'd be guessing alot along the way. Irrespective of the mechanisms used - providing a way for incubating projects to push actions up to the incubation community is going address the concern you raised about sharing the load. Cheers, Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Incubate Apache Repo
Noel J. Bergman wrote: +1 if you mean to incubate a particular project, since it seems that you have a set of codebases and a community to start. However, unless it is willing to be more inclusive of other related projects, I don't think that it should be permitted to refer to itself as the Apache Repository project. It is a single instance of such a client tool. Mind you, I would like to see collaboration between these projects, Avalon and Maven. There are a couple (or more) people from Avalon who would be keen to get invoked with a collaborative initiative of kind assuming that we can get a good broad spectrum of support across Apache projects. My own interest is coming from the point of view of the Avalon Repository facility. Avalon's Repository initiative is concerned with linking together components and repositories to support aggressive deployment strategies. I've just posted some *very* initial information up on Apache at the following address: http://avalon.apache.org/repository/about In addition to what is written there - there is also work on-going within Avalon in the development of IDE tools/plugins linked to this facilities, repository management in general, and broader development interests that tie into the Apache Directory Project's Eve product and all of that component and service management stuff in Avalon. If the initial community is agreeable I would be interested in contributing and I'm sure there are a couple of other Avalon committers that would want get involved as well. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Incubate Apache Repo
Geir Magnusson Jr wrote: "Depot" +1 -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New Incubator rules and scope definition (long)
Jason van Zyl wrote: On Fri, 2003-12-12 at 12:20, Nicola Ken Barozzi wrote: The "Incubator Reorg" threads have brought the Incubator to the definition of a new set of rules, that aim to simplify, streamline and generally make the process of incubation more effective. It's time to wrap it up. Hence I ask to vote on the acceptance of this scope definition, which is the start of our charter, and on the proposed line of action, specifically on the project spinoffs and on the creation of PPMCs. My Vote: +1 What's the time frame for the vote? My response to the proposal is lengthy so would a span of a week from now be reasonable? +1 .. its a reasonable proposition Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exiting Incubation - Status Check
Jochen Wiedmann wrote: Hi, I have a couple of questions concerning http://wiki.apache.org/incubator/ExitingIncubator Some of them have already been asked (with no reply), some haven't. * No non ASL or ASL compatbile dependencies in the code base In the case of JaxMe, there are several unit tests, which depend on hsqldb. hsqldb is not in the CVS repository, but the developer is expected to download it from the hsqldb site (hsqldb.sf.net) and put it into a certain subdirectory. Likewise, Gump is configured to load hsqldb from another location. hsqldb is required to build the sources. The binary distribution contains no references to hsqldb. Does that match the above terms or does it not? Sounds to me like it does. * Check of project name for trademark issues How do I do that? In particular, how do I record that I have checked and found no issues? No idea. * Demonstrate an active and diverse development community I know what I consider an "active and diverse" development community. But I am not the one to decide. Who can give me a clue whether the community is supposed to be sufficiently "active and diverse"? Can you provide some indicators of the community engagement, independence, and empathy? * engagement - meaning is there at least three committers active in the process? * independence - are developers aligned to a particular corporate entity or are they independent? * empathy - the extent to which the community has adapted to the apache way (process, policy, etc.)? * Demonstrate ability to tolerate and resolve conflict within the community. I understand and approve the desire. However, to fulfill the words, I would possibly have to force a conflict. :-) Setup a secret PPMC mailing list, plot a staged dispute, resolve it professionally and with respect for everyone involved, then tick the issue off the list. It's a stupid requirement. Ignore it. * Developers tied into ASF PGP web of trust I do not know what is required to conform to this part. Me neither. Ignore it - but maybe get someone in the community to hock up with the incubator group to track what is happening in that area. For the record, I would like to note, that IMO the other requirements are fulfilled by JaxMe. Then rerquest an exit. Remeber that things happen in open source because you make them happen. Don't wait for the PMC to make a decision. Push for exit - make it happen - get on with the prime objective. Cheers, Stephen. Jochen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exiting Incubation - Status Check
Jochen Wiedmann wrote: Forgot something: Jochen Wiedmann wrote: * Check of project name for trademark issues How do I do that? In particular, how do I record that I have checked and found no issues? *When* do I check? At the time the project wishes to exit incubation status? Or as soon as possible, in order to avoid conflicts with trademarks that are upcoming later? Do whatever you can to clear the item off the agenda. It's an obsticle to incubator exit - clear the obsticle using whatever means that are available to you. Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs and oversight
Berin Lautenbach wrote: Noel, No - I agree :>. My comments about a mentor is nothing to do with Status files or the like. It's all about having one formal link between the current ASF and the particular project in incubation. In fact that person doing all the status reports etc. I would see as counterproductive, for all the reasons you detail below. But they should be the person who kicks these things off and helps the PPMC ensure they start occuring. The "formal mentor" is not even necessarily a development person, just someone who is assigned to assist the project get underway, and who is seen by the INcubator PMC as the person who should be ensuring everything is happening the way it should. That is *not* the PPMC. The purpose of the PPMC is to get a group in place that will become the PMC on maturation. The mentor is the person guiding the PPMC in its role at the start and playing less of a role as time goes on. But (IMO) you need someone to formally bootstrap the PPMC and ensure everything is going properly. +1 Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs and oversight
+1 on everything below (including the tinker's cuss). Stephen. Berin Lautenbach wrote: Aaron Bannert wrote: On Sun, Dec 28, 2003 at 03:43:56PM +1100, Berin Lautenbach wrote: I'm confused by what you are saying. Do you believe there should be one person in an authoritative position for each PPMC or not? I am strongly against having "roles" within the ASF. Roles go against the way volunteer organizations work. Volunteers at the ASF will contribute when they can. It is difficult for most people to commit to certain responsibilities when they must keep real life at a higher priority (work, family, etc). By keeping things simple and allowing people to contribute when they are best able to, we all benefit. One of the reasons I like the ASF is that it is a formal structure around volunteer work. If you look at volunteer organisations, they don't just take people and let them do whatever they want. They channel and put some formality in place to ensure the right things are being done in the right way in the right place. That requires formalised roles. They exist in volunteer organisations everywhere. Similarly here. It's not enough to just have enthusiastic volunteers. There needs to be some focus around those areas that the organisation (in this case the ASF) sees as important from a governance perspective. I will absolutely agree that we want to keep them to a minimum. But that minimum must exist for the ASF (as an organisation) to work. PMC Chairs, board members etc. Without that structure, the ASF would simply be another Sourceforge - which is not a bad thing, but it is very different to the ASF. I also don't understand what kind of "accountability" you expect someone to step up and accept? What magic feats do you see mentors performing for which the Incubator PMC would not be better? I fail to see any benefit to this sort of artificial bottleneck. Besides, if there are serious issues to be taken care of (which I would hope would be rare) would not a mentor be doing the Incubator PMC a disservice by hiding those issues from the PMC? Exactly my point! As an Incubator PMC member who is not actually a mentor on any project, I don't personally give a tinker's cuss whether any of the projects (with one or two exceptions :>) succeed in the Incubator or not. However, I *do* care that, as a member of the PMC, I am discharging my role in ensuring the ASF is being protected, and that projects entering the foundation do so in a manner that will not bring harm on the foundation. To be comfortable, I want to know that there is an ASF member who is tracking what the incubating project is doing. If any issues arise, I want to know about them soonest! My best chance of doing that is by knowing that the ASF member has taken responsibility for protecting the ASF. I think it's important that there are at least a couple Incubator PMC people subscribed to the PPMC mailing lists, but those people *are* the "Mentors". If a PPMC has an issue they should send an email and also cc: the [EMAIL PROTECTED] mailing list. No - IMO these people are *not* the mentors (or at least this alone does not make them so). As a PMC member, I subscribe to PPMC lists to make sure I understand what is going on, and so that when a question comes up that needs input/oversite from the Incubator PMC then I can adequately do my part. That sounds like mentoring to me. Or sheparding. Or incubating. It's all the same. You are on the PMC because you are interested in incubating new ASF projects, right? Yes - but not in the sense that I am interested in seeing them successfully incubate (again with one or two exceptions :>). I am interested in seeing that the role of the Incubator is being discharged as required by the board. If you are involved in the Incubator project (not just on the PMC) then you already have shown that you are interested in helping new projects incubate. If you go so far as to actually join the PPMC list then it's obvious that you are interested in that particular community. In my mind once you get that far you are a "mentor". No. For example, I have joined the Geronimo PPMC. That's not because I am particularly interested in the J2EE project (although it's interesting stuff!). It's also not because I feel I can assist (my background is mainly C/C++ and security). It is because there have been lots of concerns around licensing and use of non ASF code. As an Incubator PMC member I feel I should be fully accross this issue, so I have joined the PPMC. I make a distinction between teaching and doing. The way I see it, veteran ASFers who are interested in incubating new ASF project communities should join the Incubator PMC and any PPMCs that they find interesting. By participating in those discussions, they can teach these new projects how to behave like ASF projects. Now that is what I see as a Mentor! It seems to me that we have inadvertently invented the role of Mentor
Re: PPMCs and oversight
Noel J. Bergman wrote: Berin Lautenbach wrote: I will absolutely agree that we want to keep [rules] to a minimum. But that minimum must exist for the ASF (as an organisation) to work. Agreed. Some of which I think are for the Incubator PMC to impose on itself as necessary, but don't effect the structure of the PPMC. I *do* care that, as a member of the PMC, I am discharging my role in ensuring the ASF is being protected, and that projects entering the foundation do so in a manner that will not bring harm on the foundation. I agree. Plus I would add that successfully incubated projects enhance the Foundation. However there should be one person (the single mentor that we originally had) who is tracking the project, the PPMC etc., holding them to task and making the Incubator PMC aware of any issues. That to me is a critical task, and one that requires a level of accountability. I disagree. I believe that with the PPMC structure in place, we should hold the PPMC accountable, just as every PMC is accountable. We need to ensure that the PPMC members are well aware of the responsibility of the PPMC, and that it is accountable. I think that instilling that sense of accountability there from the beginning is important, and that installing a designated taskmaster as I feel you describe it would be counter-productive. Noel: Look at things from the other way round. For all practical purposes you are the defacto point-man with respect to the Directory project. From the point-of-view of people on the directory project you are the man they can turn to privaetly, ask questions, seek advice, and within which you can provide info based on experince, conections, contacts, etc. Your also someone that members of the PMC can turn to and say "hey Noel - how are things going on over on the directory project?". That's possible because your defacto accountable. What the role means is that members of the incubating project can count on you to do you stuff, just as members of the PMC can count on you to do your stuff - but lets imagine that conflicts in availble time arise and for some reason your out of commission for three months - well, heck - I can jump in do your that stuff - the point is that there is a liason, a go-between, a recognized "Apache" contact point for all parties - someone identified as the point-man. Someone from Apache ready to say "yes" - I'm available and committed on both sides of the equation. Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs and oversight
Berin Lautenbach wrote: Leo Simons wrote: IMHO, as long as a project still requires a "point man" (or as long as the PMC still requires such a person in order to be kept up to date of what is happening in the directory project), the project is not ready for graduation. Absolutely! A good test of maturity. If the mentor is doing absolutely nothing and things are going well, then there is no need for a mentor and quite possibly no need for the project to be in incubation anymore. Exactly! Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs and oversight
Leo Simons wrote: Berin Lautenbach wrote: Leo Simons wrote: Absolutely! A good test of maturity. If the mentor is doing absolutely nothing and things are going well, then there is no need for a mentor and quite possibly no need for the project to be in incubation anymore. Exactly! So you are saying there should be a single liason for a project, and at the same time an important goal for the project would be to stop talking to/through this liason? When did liason come into this? Steve introduced it a few messages back. Umm - I talked about a "point-man"! I am confused as to what on earth oversite and assistance has to do with liason? Steve indicated that Noel was filling all three those roles. Slow down Leo! You putting words into my mouth that were not there to start with. Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/ | || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PPMCs and oversight
Leo Simons wrote: Stephen McConnell wrote: Leo Simons wrote: Berin Lautenbach wrote: Leo Simons wrote: Absolutely! A good test of maturity. If the mentor is doing absolutely nothing and things are going well, then there is no need for a mentor and quite possibly no need for the project to be in incubation anymore. Exactly! So you are saying there should be a single liason for a project, and at the same time an important goal for the project would be to stop talking to/through this liason? When did liason come into this? Steve introduced it a few messages back. Umm - I talked about a "point-man"! Look at things from the other way round. For all practical purposes you are the defacto point-man with respect to the Directory project. From the point-of-view of people on the directory project you are the man they can turn to privaetly, ask questions, seek advice, and within which you can provide info based on experince, conections, contacts, etc. Your also someone that members of the PMC can turn to and say "hey Noel - how are things going on over on the directory project?". That's possible because your defacto accountable. What the role means is that members of the incubating project can count on you to do you stuff, just as members of the PMC can count on you to do your stuff - but lets imagine that conflicts in availble time arise and for some reason your out of commission for three months - well, heck - I can jump in do your that stuff - the point is that there is a liason, a go-between, a recognized "Apache" contact point for all parties - someone identified as the point-man. Someone from Apache ready to say "yes" - I'm available and committed on both sides of the equation. you called that point-man a liason. But let us not split hairs. I am confused as to what on earth oversite and assistance has to do with liason? Steve indicated that Noel was filling all three those roles. Slow down Leo! You putting words into my mouth that were not there to start with. sorry for that; not my intention. I took the quote above to mean that there's a person who handles oversight, assistance and communication, and that Noel was filling that role for Directory. My response was related to the on-going debate about invididuals versus group reponsibilities. What I described is role of an individual lined to both an incubating project and to Apache at large. I descibed the benefit that such a "real-person" can bring to a new group of people comming into Apache. I noted a certain level of responsibility that exists in this scenario - reposibility towards the new project and reposibilities towards the PMC. As others have pointed out - this isn't saying this role is responsible for doing this or that - instead - its someone to ask questions "what is the [EMAIL PROTECTED] list" - "do I need to worry about X or Y" - "where can I go to do this or that" - someone that going the extra step beyond just subscribing to a list. For new project members that person is undertaking to work with the new team, to assist when needed. On the other side the equation member of the Incubator PMC can place some level of confidence that every new new project has "people" connected with both Apache, the Incubator PMC, and the project. Yes - as people invoked in an incubated project learn about what is Apache then the roles of guidance, assistance, help, etc. drop away. In the just the same way people within the Incubator PMC will observe that the members of the project are acting as a community, making their own decisions, setting their own agenda, getting ready to leave. Now what this is all about is the notion of "responsibility". Nicola is arguing the the PMC is responsible - I argure that groups cannot be reponsible because groups don't do that - groups enable emergent characteristics - things like concensus, decisions, policy, gueidlines, and in the case of Incubator - transient infrastructure. On the other hand, individuals can say "I'll take that extra step" and in doing so make a commitment to both the PMC and a new team to facilitiate a process. Now, I know Nicolas going to jump on this as say all of that stuff about "one person cannot do it alone" - and I think Nicolas is missing the point - sure than can be lots of people doing lots of things - instead - it is about one person accepting a level of responsibility - saying - "yes, I'm going to the extra step on this project" and that means "I'm taking a risk and it also means that I'm partially accountable for the result (sucessful or otherwise)". Cheers, Stephen. Not meaning to offend anyone. But perhaps you can help clear up my misunderstanding? - LSD ---
Re: [VOTE] graduate MerlinDeveloper from incubation
Leo Simons wrote: I propose we release MerlinDeveloper from incubation and allow avalon to import the code. Please place your votes: [X] +1 -- yes -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE:RESULT] graduate MerlinDeveloper from incubation
Leo Simons wrote: I proposed we release MerlinDeveloper from incubation and allow avalon to import the code. The Incubator PMC has voted. The results of the vote are as follows: +1 - 13 (of which 3 non-binding) +0 - 0 -1 - 0 there's consensus; the vote passes. This concludes the incubation for MerlinDeveloper. I've updated the statusfile. Avalon PMC, "the baby is all yours"! Thanks Leo! Please do pay consideration to these reports: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=3145 http://cvs.apache.org/viewcvs.cgi/*checkout*/incubator/site/projects/success/merlin-developer.cwiki and double check to make sure all items mentioned are correct and any mentioned action items have been properly executed before commencing import. I can personally confirm that all of the items mentioned have been taken care of. Cheers, Steve. thanks to everyone who helped make the incubation process go as smooth as possible. -- || | Magic by Merlin| | Production by Avalon | || | http://avalon.apache.org/merlin| | http://dpml.net/merlin/distributions/latest| || - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Graduate Geronimo from Incubator and recommend as top-level project
[X] +1 - The Geronimo project has met the requirements for incubation and will be recommended to the board for TLP status [ ] -1 - The Geronimo project as not met the requirements for incubation -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
deescalation
Nicola - apparently you have the moral high ground on the subject of "deescalation" . care to justify this or shall we let it drop? Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Personal attacks and respect
Nicola: If you have a problem with my annoyance at your presumption to preach - then present it here away from any particular project. Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Personal attacks and respect
Brian McCallister wrote:
As an innocent bystander of the flamewar that spawned this email:
Nicola commented on some technical changes, it started deteriorating
into shed painting, Nicola posted an email on de-escalating conflict in
technical discussions, then Stephen attacked Nicola directly for some
as-yet-unspecified ("you know why, Nicola") historical reason that
Nicola is not allowed to suggest ways to de-escalate conflict.
Actually - what I said was that
"Nicola is 100% familiar with the reasons why he is
the last person on the planet to assume any authority
on [the subject of deescalation]"
I would call that more of an "observation" rather than an "attack". I'm
confident Nicola understands and appreciates that distinction.
Cheers, Steve.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Personal attacks and respect
Noel J. Bergman wrote: I'm quite confident that a good portion of the inhabitants of this list doesn't care much about who is going to "win" this flamefest. +1 There is a sense in which a general discussion on community building techniques and communication skills is worthwhile. I've suggested to Nicola Ken that he start work on a web page to cover ideals, techniques and scenarios. -1 Sorry but Nicola Ken is not qualified. I'm sorry Nicola but you instigated this and only you can fix it. Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Personal attacks and respect
Noel J. Bergman wrote: I've suggested to Nicola Ken that he start work on a web page to cover ideals, techniques and scenarios [related to community building and conversation skills] -1 Sorry but Nicola Ken is not qualified. Your opinion is noted, but that is not your call to make. I asked him if he would volunteer to start that content, and he has agreed. No one's writing is sacrosanct. Process documentation is part of the Incubator's "work product", and managed in source control just like code. We have plenty of people with experience and insight to contribute, and it will be easier, in my view, to contribute to something that exists rather than to an empty page. If you wish to contribute constructive suggestions, your contributions will be as treated the same as anyone else's. Thank you for the offer - but no - I won't be contributing to something which blatantly contradicts opinion with action. Cheers, Steve. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Personal attacks and respect
Sander Striker wrote: From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: Thursday, July 08, 2004 8:58 PM Noel J. Bergman wrote: I'm quite confident that a good portion of the inhabitants of this list doesn't care much about who is going to "win" this flamefest. +1 There is a sense in which a general discussion on community building techniques and communication skills is worthwhile. I've suggested to Nicola Ken that he start work on a web page to cover ideals, techniques and scenarios. -1 Sorry but Nicola Ken is not qualified. I'm sorry Nicola but you instigated this and only you can fix it. Stephen, saying that someone is not qualified to do X isn't constructive. Furthermore, it doesn't give me warm fuzzies reading a statement like that on a list like this one. Or any list for that matter. Sander: I know where your coming from - but I'm kind of left without an option. If you want to suggest a mechanisms for resolution I'm listening. Cheers, Steve. Sander - 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: [VOTE] Accept MyFaces for Incubation
[X] Accept MyFaces into the Incubator [ ] Reject MyFaces -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Personal attacks and respect
Brian Behlendorf wrote: On Fri, 9 Jul 2004, Rodent of Unusual Size wrote: Steven Noels wrote: Please, not here. I'm quite confident that a good portion of the inhabitants of this list doesn't care much about who is going to "win" this flamefest. At least I am not, and I can imagine that neither general@ nor [EMAIL PROTECTED] are to be bothered with thread fallout debris like this. It ain't fun nor educating to watch. well, sometimes you have to deal with unpleasant things. that's life. I think most of us are still perplexed as to why Stephen chose this list ([EMAIL PROTECTED]) to "rumble" with Nicola. Could someone clarify this? Does it have to do with a project currently in the incubator? I'm not on any sublists of the incubator... I chose this list for two reasons: 1. unnecessary and unwarranted disruption of an incubator project was occurring - something I did not want to see continue in light of the fact the the issues had nothing to do with the project in question 2. that underlying this disruption - incubator policies related to the nomination of named mentors is IMO potential the root issue here I think that the first issue can be resolved (possible through arbitration or directly by the initiating party). Even so, the second issue remains and is a subject that could be reviewed within this forum and potential resolved for the benefit of subsequent incubator projects. For now I aiming to resolve the first item, following which I (or possibly someone else with interested in improving policy here at Apache) can provide a more complete summation. My apologies to everyone for what I hope will be a temporary disruption and earnestly hope that a rapid resolution can be achieved. Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Personal attacks and respect
Noel J. Bergman wrote: unnecessary and unwarranted disruption of an incubator project Let it go. No one other than you is characterizing it that way. Just let it go. I let it go for three months and now I'm seeing the consequences on not speaking up earlier. If people here think it is appropriate I can move the discussion to [EMAIL PROTECTED] - but frankly, I think it is more appropriate that this issue is dealt with here. Either way, the question of "mentor" responsibility and accountability will be raised. Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Personal attacks and respect
Stephen McConnell wrote: Noel J. Bergman wrote: unnecessary and unwarranted disruption of an incubator project Let it go. No one other than you is characterizing it that way. Just let it go. I let it go for three months and now I'm seeing the consequences on not speaking up earlier. If people here think it is appropriate I can move the discussion to [EMAIL PROTECTED] - but frankly, I think it is more appropriate that this issue is dealt with here. Either way, the question of "mentor" responsibility and accountability will be raised. I would like to retract my comments above. Basically I'm digging a hole for myself and dragging Nicola in with me. Nicola - I want to apologize to you for that. You and I still need to talk because knowingly or not your causing me grief and making life difficult for an entire project. As for the above - I'm not interested in raising discussion on [EMAIL PROTECTED] - I'm not even keen on the discussion here. All I really want to do is to get you to recognize that your public call for the death of a particular Apache project has caused damage and unnecessary time from a number of different people who care about the project in question. On the other-hand I can't stand here are say that you don't have the right to say what you think. To everyone else - at the end of the day I know I'm simply using the question of mentor as leverage. Bottom line - that makes me not a very good Apache citizen and that's creating a situation in which I feel very uncomfortable. Maybe Ken's right and all I need is a good smack around the head. Even so - I want to say sorry to everyone here - in particular - Noel - you don't need this more than anyone. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] How to prevent abusing Apache priviliges
> -Original Message- > From: Steven Noels [mailto:[EMAIL PROTECTED] > Sent: 18 October 2004 10:43 > To: [EMAIL PROTECTED] > Subject: Re: [OT] How to prevent abusing Apache priviliges > > On 18 Oct 2004, at 02:19, thorsten wrote: > > > Steven Noels wrote: > >> Nope. What Thorsten describes looks pretty bad IMO, so I want to know > >> what is going on. Otherwise, this shouldn't have been posted at all. > >> No need to keep the dust under the carpet. And if Thorsten doesn't > >> want to go public with it - he should post on [EMAIL PROTECTED] Talking > >> about the issue doesn't have anything to do with forwarding private > >> mails to public/private lists. > > > > I did not want to do that because I thought we could make rules > > against thus abuse in the future without reviewing the past. I believe > > in the "second change". Like Roy said "Keep in mind that mentors are > > human > > too and they sometimes make mistakes." > > > >> I will not vote on policy which makes no sense or is based on > >> unproven facts from the past. > > > > I really do not see your point that this policy do not make sense! > > Sure. Do you really think that establishing such a rule will refrain > people from being human, and making mistakes? You just want a stick to > beat them if they make a mistake? If mistakes are to be expected, and > based on factual stuff (such as licensing, release guidelines, etc), > I'm all +1 on establishing rules. If you want a rule that "allows" you > to deface someone by talking to his management, I'm pretty sure you're > looking in the wrong place. What would need to be in that rule? Public > punishment? Having a postbox for dropping unfounded claims into? Sorry > but I really don't understand what you want to establish with this > discussion, other than substantiating FUD. FUD? Seems to me that he's talking about a very real dark-side of the ASF. You know - the side of Apache where certain individuals enjoy playing with private lists, protected themselves while at same time spreading lies, slander, and real fear. Mix this with the incubator and you have a recipe for abuse. Yes - there should be a code of conduct. Yes - everyone should be accountable - including each and every member of the board. Will it happen? It seems to me a highly unlikely scenario. Just my 0.02c. Cheers, Stephen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Directory exiting Incubator
> -Original Message- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED] > Sent: Sunday, 13 February 2005 3:55 AM > To: general@incubator.apache.org > Cc: Apache Directory Developers List; Directory PPMC > Subject: RE: [VOTE] Directory exiting Incubator > > Alex, > > Continue on your path, but I want to see further involvement > from the Incubator PMC in this vote. I am very plesed to see > all of the others who have expressed support for the project > to graduate, but so far, we have only Nicola Ken and myself > from the PMC voting +1. We should be able to get at least 3 > +1 votes from the two dozen members of the PMC. Here is vote no. 3. +1 Steve. Directory PPMC Member. > --- Noel > > -Original Message- > From: Alex Karasulu [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 10, 2005 19:08 > To: general@incubator.apache.org > Cc: Apache Directory Developers List; Directory PPMC > Subject: Re: [VOTE] Directory exiting Incubator > > > Hello, > > First off let me apologize for the multi list email. > > We can now close this vote. It's been open for approximately > 3-4 days now. After our initial survey it is no surprise the > vote was unanimous with those who voted. Here's a list of > all the +1 voters: > > Enrique Rodriguez > Alex Karasulu > Mark Swanson > Trygve Laugstøl > Phil Steitz > Brett Porter > Alan D. Cabrera > Emmanuel Lecharny > Trustin Lee > Brennan Stehling > David Blevins > Adison Wongkar > Vince Tence > Niclas Hedman > Nicola Ken Barozzi > Berin Loritsch > Jeff Machols > Endi Dewata > Dain Sundstrom > > Again there were no +0, -0, or -1 votes. > > Thank you all for participating, > The Directory Project Team > > Alex Karasulu wrote: > > > Hello, > > > > On behalf of the Apache Directory Project Team, this is a VOTE for > > Directory to exit the Incubator. For more information on > the project > > and its status see the following status page and the Directory > > Project's website here: > > > > http://incubator.apache.org/projects/directory.html > > > > http://incubator.apache.org/directory/ > > > > The Directory Project has been undergoing incubation since October > > 2003 in an effort to gel community around a directory > server and what > > was once naming commons. While under incubation, we have been very > > successful. There server and naming code have matured nicely. We > > recently released the server, ApacheDS, and Apache Naming. > There is a > > considerable active community around the code base. The > intellectual > > property and trademark issues have all been resolved. > Members of the > > community work well and amicably with one another. More people are > > joining the community every day. > > > > We feel that at this point we can continue to sustain growth and > > operate as a TLP outside of the incubator. > > > > -The Directory Project Team > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE:PMC] Release Tapestry to Jakarta
Sam Ruby wrote: Andrew C. Oliver wrote: Sam Ruby wrote: Andrew C. Oliver wrote: You can integrate with Gump regardless of Maven. Its just configuring gump is a royal pain in the butt. Pppbbbttt. Apparently creating the following is beyond Andy's abilities: http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-gump/project/jakarta-tapestry.xml?rev=1.1&content-type=text/plain In any case, this is just a *starter* definition. What needs to be added is lines for each dependency and for each property that needs to be overridden. The way I generally approach this is to start with a minimal set and then add only what is absolutely necessary until I get to a failure that I can't get past. In this case, I didn't get very far. The build aborts quickly unless jboss is present. Sam.. With all due respect... I do not see this as a complete Gump configuration.. In the end this might prove to be a problem with tapestry's build but I suspect you'll hit a few more Gumpisms first. Prove me wrong. It was done once or twice before.. ;-) I'm quite willing to help flush out a full project definition once I get past the roadblocks. The question is: what should be done about the apparent jboss prereq? Migrate to Avalon Phoenix oir Merlin? :-) Cheers, Steve. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Incubator DOA (Re: [STATUS] Tapestry [LACK-OF] Progress)
Roy T. Fielding wrote: 1. The border of incubator reponsibilities are ambigious with regards to the boards Nope. 2. The incubator is not responsive to new requests Yep. Somebody needs to own each request. I would rephrase this as: "someone has to *champion* new requests" Cheers Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
Sam Ruby wrote: James is the only project that I recall that did it of their own initiative. Correction - Avalon was of its own iniative. Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] PMC Vote to incubate Directory Project
Sam Ruby wrote: Stephen McConnell wrote: Sam Ruby wrote: James is the only project that I recall that did it of their own initiative. Correction - Avalon was of its own iniative. Hearing that statement makes me feel VERY good. ;-) Zutt - thinking back to the days of the reorg discussions. I still have a complete set of archive of that on my hard disk. It was the most valuable insite to the notion of "what is Apache". Lots of things have grown up and matured as a result (although I think that ASF Member status continues to maintain a certain club quality within which privaliges ebb-and-flow toi sute the moment). Cheers, Steve. Note: Stephen is not a subscriber to the [EMAIL PROTECTED] mailing list. I have to ask myself the question "why would I want such a subscription" ;-) 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]
ASF member role - accountable to whom
Noel J. Bergman wrote: ASF Member status continues to maintain a certain club quality within which privaliges ebb-and-flow toi sute the moment). Huh? I want you to think of two societies (a) a small society that establishes a board which creates the notion of membership by invitation which influences the evolution of Apache via the incubator, as opposed to (b) a broader and more open society the elects members that are charged with and accountable to its electorate community for the evolution of Apache via the incubator. Which of these two views do you subscribe to? ... and, to whom is the ASF Member accountable? Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
... and, to whom is the ASF Member accountable? In all contexts, to himself/herself, but if you mean in terms of ASF related behavior, that would be governed by our Bylaws and policies. To imply that ASF Members are not accountable would be a horrid stretch. I am specific asking this in the context of the incubator policies. If I understand correctly, the policies require project sponsorship by a member and from what member only sheparding. While parhaps with best intent - it is excluding non-members from sponsorship and sheparding of new projects. Given a policy that equates to an exclusion of Apache contributors - they needs to be some form of accountability by members towards non-members on matters concerning incubation. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
Rodent of Unusual Size wrote: Stephen McConnell wrote: I am specific asking this in the context of the incubator policies. If I understand correctly, the policies require project sponsorship by a member and from what member only sheparding. While parhaps with best intent - it is excluding non-members from sponsorship and sheparding of new projects. correct and by design. part of the purpose of the incubator is to make sure new projects fit into our technical and cultural framework. assigning the mentoring process to a member, who has become a member by virtue of demonstrating knowledge of the framework, makes sense. But also excludes non-Members irrespective of their technical/culteral affiliation with the subject and Apache. allowing j random contributor who may or may not have a clear picture to mentor does *not* make sense, at least not to me. Nobody is talking about j random. This is a question as to why Membership is a prerequisite. So long as membership is a prerequisite the policies exclude other members of the Apache community from sponsorship or sheperding. They may be strongly associated with a project, perhaps on an existing PMC, maybe a member of the board, and well integrated into the Apache Way, and yet - for some reason, that individial is barred from sponsoring and sheparding a project. Given a policy that equates to an exclusion of Apache contributors - they needs to be some form of accountability by members towards non-members on matters concerning incubation. why? the foundation is and is owned by the members, not by the non-members. the members have a perfectly legitimate right to determine what will and will not become part of the foundation. There are seperate questions here. What will and will not become a part of the foundation should be a decision on the Board (either directly or via a existing PMC). That subject is distinclty different from the subject of discrimination between Members and non-Members relating to sponsoring and sheparding. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
Noel J. Bergman wrote: What is the Incubator's purpose? What I am told from multiple sources (I have asked about this out of interest), is that the Incubator is to be used whenever a substantial codebase (a sub-project) is brought in from outside the ASF, regardless of whether it is going to be a sub-project or a new TLP. As I understand it, the Incubator PMC is charged with ensuring not just successful community building, but the legal protection of the Foundation. In my view, the sponsor should take responsibility, and not leave it up to the Incubator, but the Incubator PMC is going to act as a gatekeeper making *sure* that it happens. The words "the sponsor should take responsibility" is something I agree with and is the first tangible link to a rationale between sponsor and Member that I have seen so far. Can I ask you to fill this out in a little more detail. For example, if a Member undertakes such a resonsibility, to whom is the member responsible and what would be the scope of such a responsibility? The answers to these questions will go a long way to addressing the subject of this thread. Stephen. p.s. Please keep in mind that I looking at this in terms of documeted incubation procedures - not in terms of a specific projects, Members, or non-Members. SJM -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
Rodent of Unusual Size wrote: For example, if a Member undertakes such a resonsibility, to whom is the member responsible and what would be the scope of such a responsibility? to the podling and the incubator pmc, to see that everything gets done and done properly. similarly to the foundation, with the additional responsibility of only sponsoring a podling which, in the member's judgement, will be an asset to the asf. From this I can draw the following conclusion: A Member, acting in the capacity of a sponsor of a podling, has certain responsibilities towards the podling and the Incubator PMC. Here is an initial attempt to detail said "certain responsibilities": Responsibilities of a Members towards the podling - * to liase between Apache Administration and podling on matters concerning CLA submission and aknowledgement * to liase between Apache Administration and podling on matters concerning infrastructre suport (mailing lists, CVS, account establishment, etc.) * to assist the podling on matters concerning the resolution of license transfers, copyright assignments, and/or software grants where applicable * to provide where as as appropriate, guidance on matters concerning Apache policies and practices, including the establishment of its internal steering committee Responsibilities of a Members towards the Incubator PMC --- * to notify the PMC of the completion of CLA submissions * to provide updates to the PMC on the status of license grants (where and as appropriate) * to provide on request the PMC a summary of the progress and status of a podling (including recommendations for continuation, termination, or exit of a podling from the incubation process) Are there any Sponsor reponsibilities that I am missing here? What I am aiming at is a summary of everything a Member should be aware of when accepting the role of Sponsor, the set of responsibilitiues that a podling can expect to be provided by the Sponsor, and the expectations from the PMC towards the Sponsor. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
Noel J. Bergman wrote: Stephen, I haven't read through your material, but unless I am wrong about what I wrote last night, an ASF Officer also qualifies. Berin Lautenbach suggested gathering and collating material from this discussion on the Wiki. Some related pages are: http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorRolesAndResponsibilities Thanks - this is useful material. One thing immediately apparent is the absence of information about the existance/role/responsibilities of a Sponsor as distinct from the role of Shepard. Looking at the material I put together relative to the material already detailed with respect to the role of shepard I see several overlaps. If there is interest, I could try and re-word the content I put together on the Sponsor responsibilities such that the role of Sponsor is more oriented towards evangalist/champion, complementing the role of Shepard. http://nagoya.apache.org/wiki/apachewiki.cgi?Incubator It would be really helpful if this page were included in the Home menu on the Incuabator web site. Also helpful would be the inclusion of the first link (roles and responsibilities) on the page concerning the incubation process. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
Henri Yandell wrote: On Sat, 20 Sep 2003, Steven Noels wrote: I just want to say that this requirement of sponsors which should be members was totally unclear to me when I started talking and working with the BEA peeps (Cliff Schmidt). So even if this was meant to be by design, it wasn't very obvious from the information available at the time. I'm a bit confused, so my apologies if this question is answered somewhere. Am I reading it right that to be a sponsor for a project in the incubator one has to be an ASF member? Based on the aggregation of information of the last few days - it appears that this is *not* official policy. However, it does appear that this is assumed policy in some quarters. Stephen. Hen - 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: [PROPOSAL] PMC Vote to incubate Directory Project
Phil: 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. Stephen. Phil Steitz wrote: I have been following this thread with interest and have found the discussion very informative. Thanks to all who have provided insight for those of us with less knowledge and experience with the Apache way. I have been a bit surprised by the lack of discussion about the merits of the proposal per se. Does this mean that all are agreed that a directory services implementation as described in the proposal would make a good asset for Apache? As an Apache committer (not an ASF member or even PMC member) who is committed to supporting the project, I would at least like to express my strong opinion that this would be a good thing for Apache. Here are just a few reasons (mostly covered in the Proposal): * Several Apache projects (Geronimo, James, Tomcat) either have direct immediate need or could be nicely extended by a robust, embeddable directory serices implementation for JNDI, configuration management, or identity management/authentication. * In addition to the basic JNDI and LDAP functionality described in the proposal, platform independent identity management/SSO solutions could be built on top of/natually extend this, providing benefits/extension possibilities for WS, HTTP Server and other projects. An ASF-licensed, "Apache-grade" directory implementation could form the basis for Apache XACML, Liberty, WSS and/or other emerging identity/auth related spec implementations. The embeddability and extended APIs being planned by this project may open up some exciting opportunities for efficient and scalable implementations of these and other specs. * This project has already attracted significant interest and is likely to attract a strong community (just my HO, of course :-) So, non-binding as my humble +1 may be, I think that this project has the makings of a very good asset for Apache, and I hope that we can sort out the organizational issues necessary to bring it in to the incubator. Phil - 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: ASF member role - accountable to whom
Berin Lautenbach wrote: Stephen McConnell wrote: If there is interest, I could try and re-word the content I put together on the Sponsor responsibilities such that the role of Sponsor is more oriented towards evangalist/champion, complementing the role of Shepard. Absolutely! The document was put there as a seed to get people adding content and changing it until it meets reality. All additions welcome! Berin: I'll jump into this this afternoon and post a summary of what I have done back to this list later this evening. Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
Stefano Mazzocchi wrote: Ah, at the end, if a committer considers this unfair, maybe he/she should question him/herself before questioning hundreds of his/her peers. Umm, ... and the "standard member line" gets rolled out once again to justify the absence of incubator documentation, process, policy, and accountability. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
Rodent of Unusual Size wrote: Stephen McConnell wrote: Stefano Mazzocchi wrote: Ah, at the end, if a committer considers this unfair, maybe he/she should question him/herself before questioning hundreds of his/her peers. Umm, ... and the "standard member line" gets rolled out once again to justify the absence of incubator documentation, process, policy, and accountability. stephen, this carp of yours is really starting to get up my nose. stefano did nothing of the sort; here's the *whole* part of his message which you conveniently snipped: There is no policy yet, but if the incubator was to make a policy, I would be against having an ASF committer which is not a member or officer being an incubating sponsor. Why? simple enough. If that person was believed good for the job by his/her peers, he would have been already a member or an officer. Or, his/her action would make him/her visible for the next election, if deserved. Ah, at the end, if a committer considers this unfair, maybe he/she should question him/herself before questioning hundreds of his/her peers. there's nothing in there making the least attempt to justify anything about the incubator. it's a statement of stefano's opinion of how he'd feel *if* a particular policy were developed, and why he feels that way. so, please: knock it off. Ken: I'll "knock it off" when there are a sufficiently complete set of policies and procedures in place (i.e. documented and adopted) such that the need for Member status is clearly identified as the legal aspect of representation of the Foundation (and/or any other quantifiable and accountable attribute this forum sees fit to attribute). This is distinctly different from the justification based of differentiation between members and non-members that Stefano describes above. By addressing the *real* issue (policies and procedures) that establish these roles and responsibilities we have a framework for accountability. With such a framework in place the necessity for particular "Members" to discriminate between Member versus non-Member as a justification for the decision on policy simply disappears. So lets "knock it off" with the "knock it off" and focus instead on getting roles, responsibilities and ultimate accountability of the Incubator in place. I should have a first draft ready in a couple of hours. How about you? Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
roles and responsibilities
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. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
Rodent of Unusual Size wrote: i refuse to be sucked any further into one of your confusions. It's good to see we agree! Clearly "confusion" is a central topic that underlines that issues addressed in this thread. Obviously I'm in good company as my confusion pales into insignificance when viewed in the context of broader matrix of incubator confusion. Hense this thread and related actions to peel away some of the fog and get to down to stubstance. With that substance established, the potential value and contributions of Apache Members "as a suppliment" to a structural framework becomes a rational and pagmatic concept that reflects, embrasses what I belive it means to be "an Apache Member". Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ASF member role - accountable to whom
Stefano Mazzocchi wrote: I said nothing about documentation, process, policy or accountability. LOL We certainly agree on this! :-) -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
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 The document does state the a candidate *shall* [have] a community of at least three persons (refer section concerning definition of a Candidate). - it has been explicitly stated that a project does NOT need to have its exit destination known at entry time. If that correect its a mistake. Under the cadidate defintion it states that a Candidate shall document a stated exit objective and sites TLP or sub-project options. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
Noel J. Bergman wrote: 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 The document does state the a candidate *shall* [have] a community of at least three persons (refer section concerning definition of a Candidate). What documment? Your Wiki page or something else? The wiki. - it has been explicitly stated that a project does NOT need to have its exit destination known at entry time. If that correect its a mistake. Under the cadidate defintion it states that a Candidate shall document a stated exit objective and sites TLP or sub-project options. Fine, I'll "correct" it (in quotes because none of this is official; the Incubator PMC finalize its own version, hopefully soon), but I was just responding back to Berin, who had already indicated that he'd be making changes. Go for it! I'm still thinking about Berin's questions but I think your response makes sence - (I'm thinking about actual scenarios and how this may pan-out with an eye for the potential pitfalls that may exist for podlings). But that's for tommorow. Stephen. -- 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
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: [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: 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
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
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: 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: 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
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
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
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: 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]
Re: Suggestions for Next Steps
Berin: Other commens on the email later - just need to jump in on this one point. Berin Lautenbach wrote: 2. Create a table of contents for the policy reference document. This can be started on Wiki (and I will do a first cut over the next few days), but I think we are getting to a point where this stuff should be going into CVS somewhere so we can start tracking more formally. Probably the first thing in the policy reference should be rules for modifying the policy. :>. Please, please, don't do that! Your describing meta policy (the rules modifying policy) - that is another subject with a different set of concerns and should be distinctly seperate from the policies and procedures of incubation. 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
Berin: Total agree with your comments and suggestions you provided in response to Cliff. Berin Lautenbach wrote: Cliff, Firstly - thanks for all the thoughts. Great stuff! Totally !! Feedback is really helpfull. The detail and obviouse attention to content is exactly the sort of thing we need. Cheers, Steve. (I think. Grumble grumble, more work, mutter mutter :>) LOL :-P -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gump for incubating projects?
robert burrell donkin wrote: is there anything to prevent gump builds being set up for incubating projects? (other than actually doing the work, of course ;) Only the idea of using of getting JIRA settup here at Apache and using it instead. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: gump for incubating projects?
Stephen McConnell wrote: robert burrell donkin wrote: is there anything to prevent gump builds being set up for incubating projects? (other than actually doing the work, of course ;) Only the idea of using of getting JIRA settup here at Apache and using it instead. Retruaction retraction - sustituute gump (which I do not mean to refer to for the bug tracking system we are currently using). Zut - twice in one day I've screwedup - I'm going to stop the product release stuff - its destroying my mind! Steve. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STATUS] (incubator) Wed Sep 24 23:46:04 EDT 2003
Rodent of Unusual Size wrote: APACHE INCUBATOR PROJECT STATUS: -*-indented-text-*- Last modified at [$Date: 2003/09/17 13:22:24 $] Web site: http://Incubator.Apache.Org/ Wiki page: http://Nagoya.Apache.Org/wiki/apachewiki.cgi?ApacheIncubatorProjectPages [note: the Web site is the 'official' documentation; the wiki pages are for collaborative development, including stuf destined for the Web site.] Any reason why the IncubatorMussings document should not be referended from ApacheIncubatorProjectPages ? Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: roles and responsibilities
[EMAIL PROTECTED] wrote: Everybody's a comedian, but not everybody is funny. Zut - I thought it was funny! Steve. "Andrew C. Oliver" <[EMAIL PROTECTED]> wrote on 26/09/2003 05:48:30 AM: Please ignore this post. I saw that Nicola Ken was starting to pull up against my tail and didn't want that rat bastard to have contributed more than me statistically to the discussion. Thus I have posted this mail to keep Nicola Ken from beating me. I think Just in case lines of mails are counted I'll paste this several times. I am the #1 contributor! Whoohoo! Nicola Ken is nothing! Now I need to be on every CVS module like Jon is... :-) I win -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ - 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]
incubator, exit and publication
I'm been following the messages concerning exit criteria and releases and I see a conflict. If a project is under incubation, then it is not accepted into Apache and therfore the content that is generating is simply content under observation - not Apache content. As such, how can a such a project release any content under an Apache license and presume the endorcement and protection of the ASF? My personal conclusion is that anything under incubation cannot do anything in relationship to Apache concerning publication, and that the Incubator PMC would be at fault if it were to endorce the publication of any artifact related to an incubated project. Can anyone explain to me the error implied by these assumptions? Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exit Criteria
Berin Lautenbach wrote: So what's the final verdict on releases? I'm wondering about this myself. My own theory is that this entire discussion is exceeding the bounds of duristiction of the Incubator PMC. I.e. IMVVHO if the incubated project wants to publish an artifact it needs to do one of two things: (a) publish under a non-ASF license, or (b) exit the incubator one way or another, and if arriving in Apache, then initiate publishing under an appropriate (non-Incubator) PMC directive, or, its not in Apache and its not our problem Does the Incubator PMC have an formal opinion on this subject? Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: incubator, exit and publication
Roy T. Fielding wrote: A release requires 3 +1 and a majority of those voting, wherein the only people allowed to vote are the PMC responsible for that code. In other words, the usual rules apply -- it is simply harder to get the votes. I am kind of surprised that folks think it would be any different. :-) Ok - going with Apache tradition - its not the PMC that makes the decision of a *release*. Its the committers in the incubator (who basically represent a bunch of rather non-incubator interest groups). Now assuming (folling classic Apache tradition), at least 3 +1 votres by incubator committers are pulled together (not hard thing to riog if you have an agenda), then according to Apache tradition the PMC is responsible for endorcing publication. Not the endorcement of publication presumably implices that the Incubator PMC is endorcing the engagement of legal liability for the artifacts that are published, prior to the acceptance of the podling into the Apache communty. Perhaps you can explain to me how the action of the Incuator PMC with respect to publication of an artifact and its reciprical impications towards the liability of the ASF is something that can be held up with *integrity* while at the same time, the Incubator PMC has not facilitated the exit of said podling. If a podling has not exited - then it clearly has not met Incuabtor exit criteria - then equally clearly, the Board has not established due-diligence, therfore - on what grounds can a release be published? You cannot have one without the other. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: incubator, exit and publication
a artifact. Cheers, Steve. Everything else could almost be case by case. Cheers, Berin From: Stephen McConnell <[EMAIL PROTECTED]> Subject: incubator, exit and publication Date: 26/09/2003 16:54:29 To: [EMAIL PROTECTED] I'm been following the messages concerning exit criteria and releases and I see a conflict. If a project is under incubation, then it is not accepted into Apache and therfore the content that is generating is simply content under observation - not Apache content. As such, how can a such a project release any content under an Apache license and presume the endorcement and protection of the ASF? My personal conclusion is that anything under incubation cannot do anything in relationship to Apache concerning publication, and that the Incubator PMC would be at fault if it were to endorce the publication of any artifact related to an incubated project. Can anyone explain to me the error implied by these assumptions? Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message was sent through MyMail http://www.mymail.com.au - 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: incubator, exit and publication
Roy T. Fielding wrote: Ok - going with Apache tradition - its not the PMC that makes the decision of a *release*. BZZZT. According to the bylaws, the only people authorized to make decisions on behalf of the ASF (including the decision to release code to the general public) are officers or the PMC responsible for the project. All other votes are to be ignored or considered advisory only, and no I don't care how long some of our umbrella projects have been ignoring that fact. :-) so what we have is * committers voting on releases * PMCs endorcing that decision by a vote to publish At the end of the day we need to address the issue of wht rights the Incubator PMC has to endorce the publication of an artifact generated by a project prior to the exit of said project from the incubator. Publication by a Sponoring Entiry is a different subject - but publication by the Incubator is a loaded question. Stephen. Roy - 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: Exit Criteria
Rodent of Unusual Size wrote: Stephen McConnell wrote: My own theory is that this entire discussion is exceeding the bounds of duristiction of the Incubator PMC. why? The incubator has a scope concerning "incubation". I hope the incubator aims to to provide the role of gatekeeper together with a support infrasture the accelerate the sucessful exit of incubated projects. Within the objective and scope, opinions have been put forward concerning the process of incubation focussed rightly on the subject of incubation. However - the discussion concerning the publication of artifacts moves us out of the domain of incubation and into the domain of managing a incubated project. This is in my opinion a fault - it is a subject that is the concern of the incubated project - not the incubator. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STATUS] (incubator) Wed Sep 24 23:46:04 EDT 2003
Berin Lautenbach wrote: Stephen McConnell wrote: Any reason why the IncubatorMussings document should not be referended from ApacheIncubatorProjectPages ? It is now. Good work Berin! -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: incubator, exit and publication
robert burrell donkin wrote: On Friday, September 26, 2003, at 08:13 AM, Roy T. Fielding wrote: A release requires 3 +1 and a majority of those voting, wherein the only people allowed to vote are the PMC responsible for that code. In other words, the usual rules apply -- it is simply harder to get the votes. just to make sure that i understand the general ASF policy correctly (hopefully people will correct any misunderstandings): 1. does this mean a vote of the pmc which is responsible for the code (rather than a vote of committers for that code where only pmc members have binding votes)? or can the actual mechanics of the vote vary (per project) provided that the pmc the ultimate authority approving the release? The Board typically creates a PMC under a particular scope and charters that PMC with a set of actions - one of these it to establish the rules (policies and procedures) that it will operate under. As such a PMC is for all intensive purposes is free to establish any rules it sees fit. However, as you imply - there are general ASF policies - in fact there are multiple "general ASF Policies". My understanding is that the committers to project vote on a release plan (the voice of the community) - a release manager, identified in the release plan undertakes the work of release preparation. On completion, it is the PMC that endorces publication of release artifacts under a majority vote with a quorum of 3. Its a process I like because it rooted in a community decision. 2. does this apply to all releases (alphas, beta, and so on) or just to full (stable) releases? My understanding is that this is applicable to all. For reference - I make a distinction between snapshot releases - typically incorporating some important new feature as distinct from offical Apache releases. I will normally publish a snapshot release on non-Apache hardware - whereas with PMC published content I try to follow Apache distribution rules/guidelines as best as possible. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Exit Criteria
Rodent of Unusual Size wrote: Stephen McConnell wrote: The incubator has a scope concerning "incubation". I hope the incubator aims to to provide the role of gatekeeper together with a support infrasture the accelerate the sucessful exit of incubated projects. so far so good. Within the objective and scope, opinions have been put forward concerning the process of incubation focussed rightly on the subject of incubation. However - the discussion concerning the publication of artifacts moves us out of the domain of incubation and into the domain of managing a incubated project. This is in my opinion a fault - it is a subject that is the concern of the incubated project - not the incubator. i really don't understand why this is so difficult to understand. perhaps it's because you're coming from the jakarta subproject culture? I don't think that's the reason. I think the real reason is that I have a lot of scepticism about the successful functioning of the Incubator. I imaging future scenarios where candidates are keep waiting with little or no feedback while the Incubator PMC debates some highly important and engaging topic, ignoring operational responsibilities. I imagine a future where a project is left to its own devices because a Shepherd has wondered off into the mountains and the Sponsor is preoccupied with greater things. I also imagine a future where irrespective of the failure of the system - an individual subject to the overhead of incubation can reach out and make things happen simply by holding the PMC and Chair responsible relative to a set of policies and procedures. The "holding the PMC responsible" is coming together - however, the distinction between Incubator responsibility, Sponsoring Entity responsibility, and Podling responsibility is blurred with respect to this notion of publication. It is blurred because there are valid reasons for each party to claim a sense of jurisdiction: * the podling has the right to claim jurisdiction because it is the domain expert * the Sponsoring Entity has the right to claim jurisdiction as they are the entity that has implicit responsibility * the Incubator has a claim on jurisdiction only in that the podling is implementing Apache practices (e.g. infrastructure release guidelines could be an example) However, there is already is implicit release simply via publication of code under CVS as a result of acceptance of a candidate into incubation. So how does one correlate these different claims to jurisdiction? Here is a suggestion: * the incubator establishes a specific incubation license template that includes relevant statements concerning incubation status * every incubated project uses the incubator template * an incubated project should be allowed to demonstrate its ability to form a quasi PMC and vote on a release/publication * such a decision should be ratified by the Sponsoring Entity * but the Incubator PMC should be able to veto a publication recommendation This places the incubated project in a position where is has to act like a PMC - get it structure in place - and go though the motions of a release/publication cycles. The appropriate due-diligence is assured by the decisions of the Sponsoring Entity while maintaining an effective oversite is a role maintained by the Incubator PMC. everything the podling does is most especially the concern of the incubator. until the podling graduates, it is *not* an independent part of the asf or even of another tlp. the incubator has the responsibility of getting the podling to the point at which is can be such -- but until that happens, it is in a grey area. Agreed. and until it's an approved asf entity, it can't release anything with the asf stamp of 'this is 100% apache software' on it. releases yes, afaic, of course -- but 'this is asf software' releases, no. Which is I think addressed in the division of responsibilities I have outlined above. Strephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: incubator, exit and publication
robert burrell donkin wrote: (sorry stephen i should have probably been clearer.) i was looking for an official(ish) statement from roy or one of the other senior (board level) ASF folks. (i'm happy to take active steps to ensure that ASF policy is enforced by the jakarta pmc - and any other project's i'm involved with - but only if i'm confident that i understand completely the policy and know that the policy comes from the ASF.) It has been probaly more than a year since I read the board minutes concerning the chartering of the Jakarta PMC. From memory is much that same content as recent PMC charters in that the Jakarta PMC is charged with responsibility for setting its own policies and procedures. As such, the starting point in understanding the applicable procedures is the qualification of which policies and procedures have been formally (or informally) established by the Jakarta PMC. From that point you have an idea what it is that you aim to enforce. Stephen. - robert On Saturday, September 27, 2003, at 01:15 PM, Stephen McConnell wrote: robert burrell donkin wrote: On Friday, September 26, 2003, at 08:13 AM, Roy T. Fielding wrote: A release requires 3 +1 and a majority of those voting, wherein the only people allowed to vote are the PMC responsible for that code. In other words, the usual rules apply -- it is simply harder to get the votes. just to make sure that i understand the general ASF policy correctly (hopefully people will correct any misunderstandings): 1. does this mean a vote of the pmc which is responsible for the code (rather than a vote of committers for that code where only pmc members have binding votes)? or can the actual mechanics of the vote vary (per project) provided that the pmc the ultimate authority approving the release? The Board typically creates a PMC under a particular scope and charters that PMC with a set of actions - one of these it to establish the rules (policies and procedures) that it will operate under. As such a PMC is for all intensive purposes is free to establish any rules it sees fit. However, as you imply - there are general ASF policies - in fact there are multiple "general ASF Policies". My understanding is that the committers to project vote on a release plan (the voice of the community) - a release manager, identified in the release plan undertakes the work of release preparation. On completion, it is the PMC that endorces publication of release artifacts under a majority vote with a quorum of 3. Its a process I like because it rooted in a community decision. 2. does this apply to all releases (alphas, beta, and so on) or just to full (stable) releases? My understanding is that this is applicable to all. For reference - I make a distinction between snapshot releases - typically incorporating some important new feature as distinct from offical Apache releases. I will normally publish a snapshot release on non-Apache hardware - whereas with PMC published content I try to follow Apache distribution rules/guidelines as best as possible. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
unicameral solution
Have been thinking along the same lines - although I wasn't able to capture the essence as nicely as Andrew :-). To rephrase Andrew's tricameral process, recasting with veto in mind ... 1. A Sponsoring Entity votes to accept a candidate 2. The Sponsoring Entity votes to exit the candidate. 3. Incubator PMC hold the right to veto. This would bring us to a unicameral solution while maintaining appropriate checks and balances through the diligence of the Incubator. Stephen. Andrew C. Oliver wrote: So we're yack yacking about the incubator (again). The incubator AFAICT replicated a tricameral vote. To release you must have: 1. A PMC vote to accept it 2. The committers of the project vote that they're ready to leave 3. The incubator PMC vote to let them out. The only country that ever invested significantly in such a system was Poland (other examples exist but the other bodies are subservient and generally advise more than consent). This was *one* of the times it was wiped off the map. I would suppose #2 would the be the most vested group and #1 be the second most (substituted for the board in the top level situation)... I'd suppose #3 would be the least vested group. The point? None, I just like pointing my finger childishly when someone does something silly (like create a tricameral voting system... pretty funny, spell check doesn't recognize it, though it finds bicameral)... -Andy -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Question time !
Why are we discussing/considering the possibility of anything other than a TLP incubation? If a project is comming in as part of another project than an existing PMC is bringing it it in and doing so in accordance with the policies, procedures and due-diligence that have been granted under their respective charters. We may well be making a wopping big blunder here in that much of what we are discussing undermines the responsibilities already discharged to existing PMCs. Instead, I propose that we re-focus our attention to role of the Incubator PMC as the adjunct to the board in dealing with new TLP candidates. Stephen. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question time !
Nicola Ken Barozzi wrote: Stephen McConnell wrote: Why are we discussing/considering the possibility of anything other than a TLP incubation? If a project is comming in as part of another project than an existing PMC is bringing it it in and doing so in accordance with the policies, procedures and due-diligence that have been granted under their respective charters. We may well be making a wopping big blunder here in that much of what we are discussing undermines the responsibilities already discharged to existing PMCs. Instead, I propose that we re-focus our attention to role of the Incubator PMC as the adjunct to the board in dealing with new TLP candidates. Read this [1] and you will have all the answers. [1] http://incubator.apache.org/resolution.html Nicola: I'll draw your attention to the first paragraph of said charter: WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with accepting new products into the Foundation, providing guidance and support to help each new product engender their own collaborative community, educating new developers in the philosophy and guidelines for collaborative development as defined by the members of the Foundation, and proposing to the board the promotion of such products to independent PMC status once their community has reached maturity. The phrase "independent PMC status" is pertinent. Reading on in the charter you will find wording that expands the above core, however the expansion is hard to rationalize beyond incorporation of "full projects" within umbrella PMCs. I think it is totally reasonable to assume project assimilation in not within the scope of the incubator. The difference between assimilation and what is describe in the charter is clear. The charter is dealing with the incorporation and development of identifiable communities that are expected to take on a role of autonomous decision making. Actions of assimilation do not lead to a new group identities or supplementary decision making groups. What this means is that we are concerned with: (a) TLP style exit (b) sub-project exit via an umbrella project However - the word on the street is that (b) is bad thing. Which leaves (a). Stephen. Stephen J. McConnell mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
