Re: Another cut at roles and responsibilities
Cliff, Just saw your updates. Many thanks indeed! Allowed me to be lazy :. Have also added something around your comment, echoed by Nicola, around the Shepherd not being an initial committer, but having CVS access for administrative purposes. Cheers, Berin Cliff Schmidt wrote: On Wednesday, September 24, 2003 5:23 AM, Berin Lautenbach wrote: Cliff, Firstly - thanks for all the thoughts. Great stuff! (I think. Grumble grumble, more work, mutter mutter :) You are more than welcome to update anything in the document you so desire. However that's not a hint - am happy to (and will tomorrow) take all this on board and make the changes. Berin, I'd be happy to make the changes myself. I just didn't want to intrude on the document since I had not been as involved as you and Stephen recently. However, now that I've gotten reactions from both of you on it, I'll take care of making the changes that you both agreed with. I'll take care of it within a couple hours. Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Berin Lautenbach wrote: From: Noel J. Bergman [EMAIL PROTECTED] It's about having an elder shepherd mentoring the main shepherd, and possibly requiring at least two people helping in Incubation. As someone who has seen multiple incubations, you feel that there is an expertise related to incubation held by people who have devoted time to going through this process previously, and you would like to see that expertise leveraged for the benefit of the podling and the ASF. If the Incubator PMC feels, in the course of exercising its duties, that more than oversight is necessary in a given instance, e.g., that the Shephard could use some help, there is nothing that prevents the Incubator PMC from taking that, or other, action to help out. It is just less formal. Berin, does that reflect your intent? Yes it does indeed reflect my original intent. You are reading my mind :. I get it too now ;-) So, having read the other e-mails, it seems to me that we can take the same approach as with the sponsor. This is an important potential role, but one that is not formally locked into the processes and procedures. So under the Incubator PMC section, I can (and will) add some text around for particularly complex incubations, or in cases where the Shepherd needs assistance, the Incubator PMC may choose to provide assistance, possibly through assigning another experienced Shepherd to assist in the process - or something similar and better worded. Let me know if there are any objections, but I believe that this is a good way forward. +1 Thanks guys, this thing is finally moving big time! :-D -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
On Tuesday, September 23, 2003 5:29 AM, Berin Lautenbach wrote: Would be great if you could have a read through the new version of http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings I also think this is a very well-written and extremely useful document. Below are a few notes/questions I had, many of them fairly small, but some might be worth considering before the document goes final. I also just made minor grammatical fixes to the Wiki page (no changes of substance). Thanks to Berin / Stephen for all the work in putting this together. If any of these notes are straight-forward enough to be applied to the doc, I'd be happy to help with that if you need it. Thanks, Cliff NOTES -- * Starting with the last sentence in the first paragraph of the Establishment section, the draft begins to address the people involved in the candidate project, but there are large sections of the document that are not addressing anyone and just describing the process (probably related to the fact that the document has multiple authors). If this document is meant to address people of all roles, I suggest removing the instances of you and your. * How does one, who isn't familiar with Apache, find a Sponsor? One extreme would be to set up a mailing list like looking-for-a-sponsor at apache.org that would be subscribed by all members/officer who would be willing to consider taking such a role. The other extreme is to leave it to the individual to figure it out (if they really care they'll find a way). However, without a list, I think links [1][2] should be included to at least let the proposer discover who is even authorized to be a Sponsor. Incidentally, I found my sponsor (Steven Noels) when we were both speaking at XML Europe 2003, otherwise I didn't know anyone here (actually I did, but I didn't know it at the time). * Either in the Establishment section, or the Sponsor section, it might be worth noting that the Sponsor can help those behind a potential candidate project understand the general Apache Way before even proposing the project and possibly wasting everyone's time. While we would rarely want to encourage private conversations, I think private consultation between a neophyte proposer and the Sponsor may be in everyone's best interests. Of course, this will be less important as we have more good docs like this one. ;-) * If this doc is meant to be read by a new proposer, some of the references to relevant mailing lists and either pmc@ or board@ may need to be spelled out a little more somewhere. Maybe an appendix of useful mailing lists? * In the Sponsor and Candidate sections, it states that the Sponsor presents the Candidate's proposal to the Sponsoring Entity. Does this mean that someone behind the proposal will not be the one sending out the first public proposal to [EMAIL PROTECTED] entity} and cc'ing Incubator? Or does this just mean that the Sponsor will be standing by to help moderate the discussion/explain things that the initial proposers cannot? * Should a proposal template be attached to this document (another appendix)? XMLBeans used the Jakarta new subproject guidelines [3] as a template, because I'd seen others use it, but I don't think it has been an official practice. Seems like it could be a helpful thing to formalize. * In either the Sponsoring Entity section or Shepherd section, I would consider explicitly stating that another responsibility/good reason for the involvement of the TLP Sponsoring Entity (not the board or Incubator PMC) is to educate the Candidate about practices specific to the sponsoring TLP, and about other subprojects that could relate to the Candidate. * Since the doc spells out the roles so clearly, I would replace the first instance of Apache Administration with ASF Secretary and the second instance with ASF Infrastructure team. * On acceptance of a candidate project, the assigned Shepherd and nominated Sponsor shall be added to the set of committers for the duration of the incubation process. Does this mean that these two are removed from being committers on the project once it escalates? Also, the general idea of automatically giving specific people committership seems somewhat contrary to a meritocracy. I actually don't think this is a bad idea; it just seems a little messy and somewhat inconsistent. * keep your Shepherd informed and Sponsor...in-the-loop We may want to say this can be greatly aided by conducting business on the -dev list, which can be monitored by these two. I would think most of what a Shepherd needs to report can be determined by looking at the -dev list. [1] http://www.apache.org/foundation/members.html [2] http://www.apache.org/foundation/index.html [3] http://jakarta.apache.org/site/newproject.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Cliff, Firstly - thanks for all the thoughts. Great stuff! (I think. Grumble grumble, more work, mutter mutter :) You are more than welcome to update anything in the document you so desire. However that's not a hint - am happy to (and will tomorrow) take all this on board and make the changes. Before I do, some thoughts on your notes, so that people can see what I'm going to do. Cliff Schmidt wrote: NOTES -- * Starting with the last sentence in the first paragraph of the Establishment section, the draft begins to address the people involved in the candidate project, but there are large sections of the document that are not addressing anyone and just describing the process (probably related to the fact that the document has multiple authors). If this document is meant to address people of all roles, I suggest removing the instances of you and your. I see this document as a non-normative what you need to do document. So I think it is appropriate to address it as a document to a proposer (i.e. you and your). This is what you are going to go through. The normative policy document on the other hand would be more formal, and use the RFC (can't remember number) that defines policy terms such as SHALL, WILL, WOULD etc. This would not be addressed to a person. On the web site, the first part of the document would be the description, linking off to other documents. The roles-and-resposibilities might be less you/your and would be on a separate page. Does that sound fair? * How does one, who isn't familiar with Apache, find a Sponsor? One extreme would be to set up a mailing list like looking-for-a-sponsor at apache.org that would be subscribed by all members/officer who would be willing to consider taking such a role. The other extreme is to leave it to the individual to figure it out (if they really care they'll find a way). However, without a list, I think links [1][2] should be included to at least let the proposer discover who is even authorized to be a Sponsor. Incidentally, I found my sponsor (Steven Noels) when we were both speaking at XML Europe 2003, otherwise I didn't know anyone here (actually I did, but I didn't know it at the time). Good thought. I will add something in. Those two links are a great start, and I might also put something about finding a project that looks to be related (e.g. XML and Jakarta for XMLBeans) and subscribing to the general@ lists as a lurker for a period of time to see how things work. * Either in the Establishment section, or the Sponsor section, it might be worth noting that the Sponsor can help those behind a potential candidate project understand the general Apache Way before even proposing the project and possibly wasting everyone's time. While we would rarely want to encourage private conversations, I think private consultation between a neophyte proposer and the Sponsor may be in everyone's best interests. Of course, this will be less important as we have more good docs like this one. ;-) Yes. Very good point. The whole reason for Incubation is the Apache Way, so it's better to ensure people find out what this is early and what it might mean. This is especially useful in a document like this that is supposed to be an informal guide to prospecitve incubees. * If this doc is meant to be read by a new proposer, some of the references to relevant mailing lists and either pmc@ or board@ may need to be spelled out a little more somewhere. Maybe an appendix of useful mailing lists? GRIN. Yes it is a bit cryptic isn't it. * In the Sponsor and Candidate sections, it states that the Sponsor presents the Candidate's proposal to the Sponsoring Entity. Does this mean that someone behind the proposal will not be the one sending out the first public proposal to [EMAIL PROTECTED] entity} and cc'ing Incubator? Or does this just mean that the Sponsor will be standing by to help moderate the discussion/explain things that the initial proposers cannot? No, it was supposed to mean that the Sponsor is there to help (your second definition). I will clean up. * Should a proposal template be attached to this document (another appendix)? XMLBeans used the Jakarta new subproject guidelines [3] as a template, because I'd seen others use it, but I don't think it has been an official practice. Seems like it could be a helpful thing to formalize. For now, a link to the Jakarta guidelines seems sensible, until we have had an opportunity to plagiarise it into an Incubator document :. * In either the Sponsoring Entity section or Shepherd section, I would consider explicitly stating that another responsibility/good reason for the involvement of the TLP Sponsoring Entity (not the board or Incubator PMC) is to educate the Candidate about practices specific to the sponsoring TLP, and about other subprojects that could relate to the Candidate. Yup. Will do. * Since the doc spells out the roles so clearly, I would replace
RE: Another cut at roles and responsibilities
On Wednesday, September 24, 2003 5:23 AM, Berin Lautenbach wrote: Cliff, Firstly - thanks for all the thoughts. Great stuff! (I think. Grumble grumble, more work, mutter mutter :) You are more than welcome to update anything in the document you so desire. However that's not a hint - am happy to (and will tomorrow) take all this on board and make the changes. Berin, I'd be happy to make the changes myself. I just didn't want to intrude on the document since I had not been as involved as you and Stephen recently. However, now that I've gotten reactions from both of you on it, I'll take care of making the changes that you both agreed with. I'll take care of it within a couple hours. Cliff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
From: Nicola Ken Barozzi [EMAIL PROTECTED] Sometimes a sponsor or a shepherd has to act fast and remove from CVS things that are not correct, like licensing. Or simply to give a hand, always about incubation things. I don't find it inconsistent with meritrocracy, as they should be committers only to things that regard the incubation, not for general programming. What I mean is that they have commit access but are not listed /automatically/ as developer, nor can vote on project matters. If the project is new though, like Geronimo, it's a different matter, as they can be the start of the community, not outside helpers. OK - so I think we just need to word something that makes it clear the Shepherd gets CVS access, but this is for Shepherd duties only. The Shepherd, just like anyone else, needs to earn the right to be able to generall submit code to the CVS. Cheers, Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
I hope that the policies, procedures, responsibilities, and ultimate accountabilities, will have a tangible and net- positive impact on the overall development of the Apache Community. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
From: Stephen McConnell [EMAIL PROTECTED] I think that Berin and I are aiming at the same objective and have very similar motives. I happen to think that we can leverage and utilize the contribution of Berin's process by analysing his concers and underlying interests and drawing from that the essence that is intrinsically important to policy, while preserving, and maintain the liberty he is persuing. Absolutely agree with all of the above. I think :. I remain confident that Berin will be more than happy to share a , Fosters, Southark (?), Redback, or (that other one that I cannot remember) should the opportunity arise. GRIN. Absolutely. And probably more than 1. Cheers, Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Stephen McConnell wrote: Thus you have the shepherd appointed by the sponsor PMC, but being bound by the Incubator PMC rules and regs. (And I would imagine the incubator would need to agree the choice.) Which does not work in practice (with respect to current policy). The Icubator PMC has been charged with the responsiblity of incubation. We have to give them the opportunity to do this. Your PMC, my PMC, neither are charged with this responsibility. All we can do it is establish a framework that ensures the integrity of the transition. Thought I would just pick up on this one. This is what we did for XMLBeans. Ted (as a member of the XML PMC) volunteered to take on the shepherd role and the Incubator agreed. Personally I like this approach. Ted keeps using the term infrastructure tax. I see this as similar. We want something - we do the work to make it happen. In other cases, the Incubator PMC (or the board) might be the sponsoring entity (parent?). In these cases, the shepherd might be nominated from the Incubator PMC or from elsewhere. The key oversite from the Incubator is (to my mind) and independant review of what is happening. If the incubator also has to find people willing to shepherd each candidate as it comes along, we risk never finding willing shepherds. Does that sound fair? Yes - providing we give the Incuabtor PMC due responsibility and ... we ensure that the policies and procedures protect us from potential absuse or neglect of said responsibilites by said PMC. I think we are - in the form of oversite and directions of actions taken by shepherds. Cheers, Berin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Nicola Ken Barozzi wrote: An incubation needs someone that actively nutrures the community, pushes the agenda and reports to the PMC of which he is part. I call him the sponsor. We also need someone that is knowlegable of how the Incubator works and that reports to the Incubator PMC. I call him the shepherd. Would be great if you could have a read through the new version of http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings I'm hoping that it is something that will work. I've actually got it such that the Shepherd reports to both. The Sponsor is someone who helps out everywhere, but has no *formal* responsibility. Otherwise there are a whole lot of people formally responsibly for a whole lot of things and it could get messy. Cheers, Berin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Nicola Ken Barozzi wrote: It's about having an elder shepherd mentoring the main shepherd, and possibly requiring at least two people helping in Incubation. What do others think about this? Over-regulation. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Berin Lautenbach wrote: Would be great if you could have a read through the new version of http://nagoya.apache.org/wiki/apachewiki.cgi?IncubatorMussings 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: Re: Another cut at roles and responsibilities
From: Stephen McConnell [EMAIL PROTECTED] One point concerning the description of the Sponsoring Entity. I currently includes a sub-heading Responsibilities of the Sponsoring Entity. The content is basically describing responsibilities of the Shepherd. It would read better if this section were removed and the respective responsibilities integrated with the definition of Shepherd. Ahh yes. Fair call :. I will do so. Cheers, Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Berin Lautenbach wrote: ... I have also very much de-emphasised the role of the sponsor. From what I've seen, the key role post acceptance is the Shepherd. If the Sponsor wishes to become the shepherd, then they retain the responsibilities, otherwise they can move onto other things, having convinced an appropriate body in the ASF to take on the candidate. Hmmm, I don't like the idea that sponsors can simply walk away in incubation. It makes it easy to push for an idea and let others do the hard work. If someone doesn't want to do the work, then in my book he's not a sponsor, as a sponsor gives something to get something, and in this case he's just advocating. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 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: Another cut at roles and responsibilities
I like the notion of the Sponsoring Entity at this addresses the entity into which a prodling is destined. Apparently, the part that destination is an exit criteria hasn't resonated with you. Yes, it is helpful to have an idea up front, but not in the sense where you took it, specifically: Perhaps we could change the name to Parent. if a cadidate aims to be top-level, its parent would be the Board. IMO, the Board's involvement should not be required for an unproven podling. That is the purpose of the Incubator PMC. The Sponsor would be the ASF Member/Officer who has sponsored the project. Depending upon how many other co-sponsors had been lined up, the Incubator PMC might be more or less active in incubation to help fledge the new podling. On the other hand ... If the project aims to enter into a project such as Avalon, the parent would be the Avalon PMC. Then there should be no lack of people who ought to take an interest in welcoming the hopefully-soon-to-be member of their TLP. If that is NOT the case, I would consider that a warning sign. 2. Shepherd versus Sponsor. The names may be interfering with the roles. One is the Incubator PMC representative, who is most likely going to focus on what criteria needs to be met to allow exit; the other is the person who is going to focus on the positive aspects of Community building and project development, although may be asked as and when necessary by the Incubator PMC to address an incubation criteria issue. Shepherd role should be maintained as monitoring, operational support, validation and assessment. That sounds about right, AIUI. The Sponsor should not be a walk-away position The role seems better viewed as Sponsor/Mentor. One should not be permitted to do the former without being willing to be the latter. The person could delegate tasks, but would still be responsible, and would need to keep on top of whatever tasks were delegated. Ownership of responsibility needs to be clear, and resident in that one person, not groups. To make this concrete, if the James Project wanted to incubate something, then either an ASF Member or Serge, our PMC Chair, would have to be the responsible party. Serge could delegate tasks, but cannot delegate responsibility. Please note: other than the very first item way up top (destination), I don't believe that we are actually disagreeing. Just clarifying. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Steve, From: Stephen McConnell [EMAIL PROTECTED] 1. Entities (Board, Parent, Incubator PMC) should not assigned actional responsibilities - only decision responsibility. Actional reposibility should be assigned to roles that are represented by accountable individuals. There were a couple of places in the document that needed to be tightened up in this respect. Personally Not sure I fully agree with this, having seen XMLBeans. If the XML Project wants to have the Incubator take on something on its behalf, then there is a two way accountability. I fully believe that the XML Project has to take some accountability for assisting the podling. That accountability (in the case of XMLBeans) is discharged by the Shepherd, who is a member of the XML PMC, but can call on others in the XML project for assistance at any time. Otherwise this is throwing all the responsibility back on a couple of people. To me the whole Apache concept is about community, so lets demonstrate what that means to the podlings. If Ted stops doing his role as Shepherd, then I would see it as the responsibility of the XML project to step in and find someone else. My impression is that we are actually aiming towards the same thing but that what you thinking of as Sheperd is what I'm thinking of as Sponsor. There are a few other little things but I thought it best to get these two items clarified first. I think you are correct, that we are heading to the same end, but I think it important to separate the sponsor of the original proposal away from the incubation. There are people who are visionaries. I can see why this is a great project and why it will be a good fit for Apache. They can help a candidate sell a proposal to Apache. Are they necessarily the best person to help a project through Incubation? Not so sure. To me, that's what the very notion of a shepherd is - someone who guards and protects the flock. A shepherd is not necessarily a great sponsor. (Might be, but I believe it's useful to split the two apart.) Cheers, Berin This message was sent through MyMail http://www.mymail.com.au - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Berin: Have just read though your email and I feel that I have very strong empathy with the position your raising - but all the same I'm going to disagree with you! I'm confident that if we were in a cafe down in the 14e we would tie this up nicely in less that a couple of hours. But that isn't the case so I'll try my best to present the issues I see in this email. Zut ... Australia really is at the end of the earth relative to France! (Zut translated into Australian is B* H***). Berin Lautenbach wrote: Steve, From: Stephen McConnell [EMAIL PROTECTED] 1. Entities (Board, Parent, Incubator PMC) should not assigned actional responsibilities - only decision responsibility. Actional reposibility should be assigned to roles that are represented by accountable individuals. There were a couple of places in the document that needed to be tightened up in this respect. Personally Not sure I fully agree with this, having seen XMLBeans. If the XML Project wants to have the Incubator take on something on its behalf, then there is a two way accountability. I fully believe that the XML Project has to take some accountability for assisting the podling. That accountability (in the case of XMLBeans) is discharged by the Shepherd, who is a member of the XML PMC, but can call on others in the XML project for assistance at any time. Consider the following assertion. The XML Project PMC, the Incubator PMC, the Avalon PMC, the Apache Board, ... all of these are basically dysfunctional entities when it comes down to doing something actionable. These entities are only good for taking decisions (although I must confess that the Board does break this logic from time to time). Let me get to the point - the XML Project PMC can make a decision to sponsor something. In doing so the XML Project PMC Chair has a responsibility concerning the implementation of the decision of the PMC. Now we all know that PMC chairs are gods, and as gods, they are surrounded by angels, and gods like playing golf, so gods, being responsible, delegate things to angels. Fortunately we can associate names with angels, we can hold them responsible and through them we hold the gods accountable. What this means is that the XML Project is doing what you want - but me - as a outsider, I can point a finger at an angel and I can hey - this needs to be done - and you (angel) personally are responsible. If that doesn't get done - I can go to god and say hey god, something is wrong - your angel isn't doing what he/she/it? should be doing and your responsible. God gets kind of annoyed - goes to the council of angels (the XML Project PMC) and says - hey guys - we have a problem (meaning hey guys I have a problem). God, using his immortal powers sends down another angel to fix the problem. Have you ever seen the movie Dogma - at the end of the day *she* is responsible. Bottom line - we are always dealing with individuals. The individual may change over time, but there is an individual that is responsible and therefore accountable. Otherwise this is throwing all the responsibility back on a couple of people. To me the whole Apache concept is about community, so lets demonstrate what that means to the podlings. If Ted stops doing his role as Shepherd, then I would see it as the responsibility of the XML project to step in and find someone else. Small change in wording. If Ted stops doing his role as Shepherd, then I would see it as the responsibility of the XML Project PMC Chair to step in and find someone else. My impression is that we are actually aiming towards the same thing but that what you thinking of as Sheperd is what I'm thinking of as Sponsor. There are a few other little things but I thought it best to get these two items clarified first. I think you are correct, that we are heading to the same end, but I think it important to separate the sponsor of the original proposal away from the incubation. There are people who are visionaries. I can see why this is a great project and why it will be a good fit for Apache. They can help a candidate sell a proposal to Apache. Are they necessarily the best person to help a project through Incubation? Not so sure. Absolutely 100% agree. But hang in there for a moment and thing about separation of these roles. One role A is about responsible representation and guidance with a engagement that is implicit for the duration of incubation - for better or worse. Another role B is about vision, excitement, opportunity, enterprise. What the policies and procedures of incubation need is A. What the project needs initially and on re-occurring occasions is a brilliant B. But B is not the subject of concern of an incubation policy. I think A needs to be on the PMC and to represent the project and I think B needs to in the public face making sure that the value proposition is communicated. Tying B to a set of policies and
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
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***). GRIN. 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 what I was trying to do, but I
RE: Another cut at roles and responsibilities
if this relates to an actionable issue - could you be a touch more specific as to the action. Actually, at this point I think that discussion has converged, a consensus appears to have emerged, and since Berin has taken a lead on coalescing this material, I think it makes sense to give him (and the Incubator PMC) time to pull it together. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
Once I got past some of your phrasing, which I consider somewhat injudiciously selected considering your likely audience, Hang on a tick - I have to look this one up! LOL Well, for a start, referring to every decision making body as dysfunctional wasn't the wisest course of action in my view. :-) Your point that things work better if after a consensus is reached, responsibility is vested in individuals is valid, but too easily lost in the response that people have to the expression. And yes, I realize that you didn't quite say it that way, but when people react reflexively, it is a difference without a distinction. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Another cut at roles and responsibilities
Think of this entire process as the establishment of a set of imutable procedures that will protect us from the breakdown of their system. Things don't work that way, Stephen. People don't. Especially the kind of people who participate here. This is not a community of bureaucrats. As underspecified as the process may have been, you are engaging in vast overengineering. We will do far, far better with a clear set of guidelines that people can understand and are willing to implement, than a legal tome. We have multiple parties to provide oversight, and means to correct problems. The Incubator PMC, Sponsor, other members, the podling itself, the Community at large ... any one of them is capable of noticing and raising an issue to be addressed. That is the nice thing about a community of intelligent life forms. You don't have to program them. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
Noel J. Bergman wrote: Think of this entire process as the establishment of a set of imutable procedures that will protect us from the breakdown of their system. Things don't work that way, Stephen. People don't. Especially the kind of people who participate here. This is not a community of bureaucrats. As underspecified as the process may have been, you are engaging in vast overengineering. We will do far, far better with a clear set of guidelines that people can understand and are willing to implement, than a legal tome. If there is overengineering I need specific in order to address the concern. We have multiple parties to provide oversight, and means to correct problems. The Incubator PMC, Sponsor, other members, the podling itself, the Community at large ... any one of them is capable of noticing and raising an issue to be addressed. And aach capable of assuming that the other is undertaking the responsibility. Each negligent in assuring oversight, each justified in claiming non-culpability. You and I have very different views here (which is ok). I view the incubator as an emergent entity within Apache - an entity that is clearly in need of a framework, a framework that: (a) protect itself from itself (b) establishes concrete rules (c) establish accountability (d) is robust Such a framework has to be embedded in policies and procedures. Please consider me as the anti-christ. If I jump in on this list and within a few posts manage to change proposed structural policy - all it means is that the policy does not exist. I am simply manipulating the status quo. Make the assumption that I am here to corrupt, to circumvent, to manipulate - then ask yourself the question ... what framework do you have in place today to protect youself and the community you represent? Today the incubator is for all purposes is defenseless. Hopefully this will change with the establishment and adoption of concrete set of policies and procedures. Now make another assumption .. Steve is about to enter into an incubation, and Steve does not have the spare-time to to deal with indecision, lack of accountability, nor political ineptitude, and as such Steve will go out of his way to close every gap and loophole to ensure that a rapid and successful exit from this process is all but assured. Was that sufficiently politically correct or should I be more subtle and rephrase something? Cheers, Steve. -- mailto:[EMAIL PROTECTED] Stephen J. McConnell - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another cut at roles and responsibilities
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]
