RE: Indemnification of the PMC
- Original message From: Danny Angus [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sat, 27 Dec 2003 22:58:55 + Subject: RE: Indemnification of the PMC Seems to me that part of the reason it is difficult to resolve the issues confronting Jakarta is that several initial assumptions are required, and that these are not stated or clearly implied anywhere. Greg assures us that the board aren't likely to act precipitately (if thats how you spell it), and we haven't had official communications from The Members of The Board on the topic, yet there are a lot of hints about the unsuitability of Jakarta's present organisation. I think we could do with some concrete direction, or at least an affirmation of our mandate to continue what we are currently doing. Because to me it is increasingly feeling like we're trying to fix something which (apart from a few details like the bylaws) isn't broken on the basis of speculation and conjecture, and the danger in that is obvious, we'll end up breaking the thing we're trying to fix, or failing to fix the parts which are broken. And with the utmost respect for Sam hopefully that is something a new Chairman, with more time and fresh enthusiasm for the role, will be able to provide. Well, first, the idea of consensus is at the core of the Apache culture. Consensus means that everyone involved has agreed that a course of action is the best available. It may not be everyone's first choice, but it is a solution everyone can live with. Consensus is not something that is easy to represent in a list of rules and procedures. It's a process of human engineering and difficult to reduce to writing. It would even be harder to reduce to writing for every community. Communities are like all other human relationship. Each one is a little bit difference, and, in human terms, the little differences can mean a lot. Now, with Jakarta, there seems to be a belief that we should be following a deterministic process with definitive procedures. Elsewhere in ASF land, there's a feeling that if you need to call upon a formal procedure (say, by exercising a veto), then consensus has failed. When this happens, many Apaches might feel that the real problem isn't the technical issue underlying the veto, but the consensus issue underlying the *need* to veto. Procedure is a fail-safe. Achieving consensus through discussion is the nominal process. The Apaches on the board don't like to make dictates, since dictates defeat consensus. They are not our bosses as much as they are our colleagues. They want to us to sort this out for ourselves. Because, if we can't sort it out ourselves, then we're not building a community that can endure. Tough love. As for what we are suppose to be doing here, the board has already made two mandates. One in section 6.3 of the bylaws http://apache.org/foundation/bylaws.html and another by resolution http://tinyurl.com/3x6rs. The PMC is responsible for the active management of the Jakarta codebase. Part of good management is effective oversight http://tinyurl.com/2eyvg, which is to say solving little problems before they become big problems. We know oversight is failing because we've had to take some drastic measures over the years. One subproject could not resolve an issue, either through consensus or by following the voting process. As a result, a committer lost his write access. By Apache standards, having to do such a thing is a red-letter scandal. Consensus oversight failed. We've also had to temporarily restrict access to CVS modules because of unresolved IP issues. All the issues were resolvable and should have been resolved *proactively* rather than *reactively*. IP oversight failed. There is no doubt that the Jakarta subprojects are healthy. Every project has its hiccups, and Jakarta is no exception. But, we seem to lack a mechanism that allows issues of consensus and IP to come to to forefront *before* it is too late. The infrastructure club is our final fail-save, employed as a last, desperate measure. Denying access to resources is a black-mark that screams oversight has failed. It's not an oh well that we can sweep under the rug and forget about. Other ASF projects have fewer lines of code to worry about, and most, or all, of the committers are on the PMC. If a committer/member has a problem, he or she can bring it up directly on the PMC list, without having to find an intermediary or post a sensitive observation on a public list. IMHO, we need to put aside the maverick guidelines posted at Jakarta and just try to do things the ASF Way. * We need to put *all* the decision-markers on the PMC. At Jakarta, that means *all* the committers, and * We need to insist that all subprojects file regular reports, with some statutory bullets to ensure everyone is still thinking about consensus and oversight. If anyone reading this message agrees,
Re: [PROPOSAL] As it ever were (draft 2)
-PROPOSITION (1)- * Require all Jakarta products (or subprojects) to file regular reports with the PMC. You mean 'make each subproject work like a TLP' don't you? Since the PMC cannot delegate its responsibilities, the report would have to be prepared by a PMC member, ideally one directly involved with subproject. (A likely suspect being the DEV list moderator.) Er, doesn't this just emphasise how broken this process is? -PROPOSITION (2)- [snip] Work regarding a specific subproject can continue to occur on that subproject's DEV list. PMC members (aka committers) following that list can vote on its releases and other day-to-day affairs. So long as the minimum quorum is met, the vote is legal and binding. So, we are trying to delegate power to subprojects? Er, but we can't now can we. So who can vote? 'Following the list' is a very vague term. Presumably I can simply subscribe to struts-dev and then vote, never having even used struts? It also seems highly dubious to say that a vote is legal and binding if most of the PMC never knew the vote occurred. Under proposition (1), the significant events occurring for each subproject would be reported to the PMC list, for the review of the PMC at-large. So the PMC is reviewing events already happened, not actively managing. Er, sounds like the relationship between the board and a PMC to me. PMC membership is voluntary. Anyone can resign from the PMC at any time. If a volunteer would like to be a committer, but not a PMC member, then each subproject can then decide whether to support separate committer and PMC member roles or not. -- I would suggest that there is nothing in this proposal that will cause the board members to have any more faith in Jakarta than they do now. And thats because it changes nothing of significance. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PROPOSAL] Proactively encourage TLP status
There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. Background info: http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges Stephen PROPOSAL The Jakarta PMC shall proactively encourage subprojects to reach Top Level Project (TLP) status. It shall do this by - drawing up a list of advantages that TLP status brings - explaining the effect of the ASF only recognizing Jakarta on a subproject's rights - documenting the process, by receiving advice from recent new TLPs - produce a draft template board resolution for creating a TLP - clearly identifying board meeting dates for TLP creation - proactively encouraging proposal then vote on developer lists - setting a timefame of 3 months for the votes In order to respect current reality, voters on each dev list shall be those of committer and PMC member status who have made recent contributions, with the exact list to be determined by the dev list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 9:39 AM, Stephen Colebourne wrote: There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. The board isn't hassling. They have valid concerns that they know we are working on, and they are even helping. This doesn't mean we are out of the woods by any means, but we're not being hassled. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. Background info: http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges Stephen PROPOSAL The Jakarta PMC shall proactively encourage subprojects to reach Top Level Project (TLP) status. It shall do this by - drawing up a list of advantages that TLP status brings - explaining the effect of the ASF only recognizing Jakarta on a subproject's rights - documenting the process, by receiving advice from recent new TLPs - produce a draft template board resolution for creating a TLP - clearly identifying board meeting dates for TLP creation - proactively encouraging proposal then vote on developer lists - setting a timefame of 3 months for the votes In order to respect current reality, voters on each dev list shall be those of committer and PMC member status who have made recent contributions, with the exact list to be determined by the dev list. -1 from me I fully support and respect sup-projects deciding on their own to leave Jakarta and be a TLP if they feel it's better for their community and code, but I see no reason for the PMC to make it their purpose on life to encourage them. Seems rather pointless. You might as well just disband Jakarta and save everyone time. geir - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
On Dec 28, 2003, at 8:43 AM, Ted Husted wrote: * We need to put *all* the decision-markers on the PMC. At Jakarta, that means *all* the committers, and No, it doesn't. We need to put as many as possible, hopefully all, but it's not required to be all. We can also have people that aren't committers on the PMC. * We need to insist that all subprojects file regular reports, with some statutory bullets to ensure everyone is still thinking about consensus and oversight. Erm, I'm not so sure that this needs to be legislated like this. If anyone reading this message agrees, or disagrees, please respond to the As it ever were proposal under another thread. Let's see if we can build a consensus and then create and maintain a solution that works. IMHO, the ASF Way *will* work if we let it; we've just never tried to let it. I don't think that anyone is debating if the ASF works. I think we all know it does. I think we disagree what the ASF Way is - I think it simply requires inclusive participation on the PMC of those willing to feel responsible for more than just the code they are working on, namely project direction and oversight. Thus, the PMC does not necessarily mean forced 100% committer participation, although that percentage is the goal, nor does it mandate strict reporting schedules and reporting content and format. I do believe that if we continue on the way already started - ensuring CLAs, putting as many active Jakarta committers on the PMC as are interested, educating them as to their oversight role, then we would be in a much healthier position and able to then grapple with the day-to-day PMC process. Until we achieve the former, the latter is somewhat of a intellectual game. As you like to point out, we all are adults working for the best interest of the organization. Please work with us on this. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Proactively encourage TLP status
+1 I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND * give notice to each and every Jakarta DEV list that the area exists. My main beef is that we have not done due diligence in alerting ALL of the subprojects of the latest developments. I've outlined a wiki page as described by this proposal http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCTopLevelProjectApplication, and setup a draft TLP resolution. I would also volunteer to subscribe to each of the DEV lists and post a message pointing them to the archive of this thread. (Unless another volunteer already has an account setup to do such things. ) Whether a subproject follows through or not can be totally up to each subproject. The important thing is that we do the due diligence in making sure *everyone* concerned has been apprised. -Ted. - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:39:30 + Subject: [PROPOSAL] Proactively encourage TLP status There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. SNIP/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were (draft 2)
-PROPOSITION (1)- * Require all Jakarta products (or subprojects) to file regular reports with the PMC. You mean 'make each subproject work like a TLP' don't you? Since the PMC cannot delegate its responsibilities, the report would have to be prepared by a PMC member, ideally one directly involved with subproject. (A likely suspect being the DEV list moderator.) Er, doesn't this just emphasise how broken this process is? -PROPOSITION (2)- [snip] Work regarding a specific subproject can continue to occur on that subproject's DEV list. PMC members (aka committers) following that list can vote on its releases and other day-to-day affairs. So long as the minimum quorum is met, the vote is legal and binding. So, we are trying to delegate power to subprojects? Er, but we can't now can we. So who can vote? 'Following the list' is a very vague term. Presumably I can simply subscribe to struts-dev and then vote, never having even used struts? It also seems highly dubious to say that a vote is legal and binding if most of the PMC never knew the vote occurred. Under proposition (1), the significant events occurring for each subproject would be reported to the PMC list, for the review of the PMC at-large. So the PMC is reviewing events already happened, not actively managing. Er, sounds like the relationship between the board and a PMC to me. PMC membership is voluntary. Anyone can resign from the PMC at any time. If a volunteer would like to be a committer, but not a PMC member, then each subproject can then decide whether to support separate committer and PMC member roles or not. -- I would suggest that there is nothing in this proposal that will cause the board members to have any more faith in Jakarta than they do now. And thats because it changes nothing of significance. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were (draft 2)
- Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:16:26 + Subject: Re: [PROPOSAL] As it ever were (draft 2) Since the PMC cannot delegate its responsibilities, the report would have to be prepared by a PMC member, ideally one directly involved with subproject. (A likely suspect being the DEV list moderator.) Er, doesn't this just emphasize how broken this process is? Not that I see. It formalizes what should have been done from the beginning. We tried to do it before, but we then run into the politics of whether the person making the report is the PMC representative to the subproject. The fundamental disconnect is that all of the committers should be on the PMC, because all of the committers are the decision-makers for one or more of our various products. -PROPOSITION (2)- [snip] Work regarding a specific subproject can continue to occur on that subproject's DEV list. PMC members (aka committers) following that list can vote on its releases and other day-to-day affairs. So long as the minimum quorum is met, the vote is legal and binding. So, we are trying to delegate power to subprojects? Er, but we can't now can we. No. We are instituting a minimum threshold meritocracy for each product. The PMC members/committers who are working on a product, and interested in its development, and the ones who make the decisions about that product. That's how it works now socially, and that's how it should work legally. So who can vote? 'Following the list' is a very vague term. Presumably I can simply subscribe to struts-dev and then vote, never having even used struts? It also seems highly dubious to say that a vote is legal and binding if most of the PMC never knew the vote occurred. As it stands today, any of the current PMC members could do exactly that. And, this is also how it works in the Commons today. If I want to chime in on a product and start committing, other volunteers are happy for the help. If you did subscribe to the Struts list and took an interest in the product, I'm sure we'd welcome your commits. You're an Apache Committer, and I'm sure you've earned your stripe. Not by trying to do harm, but by trying to do good. The value of administrative [vote]s on the DEV list are often overrated. A veto must have technical merit to be binding. Malicious vetos are not valid. And, as you know, when someone tried to enforce their own will over the will of the community, the ultimate result (sadly) was a suspension of write access. Under proposition (1), the significant events occurring for each subproject would be reported to the PMC list, for the review of the PMC at-large. So the PMC is reviewing events already happened, not actively managing. Er, sounds like the relationship between the board and a PMC to me. No, the committers to each subproject are committee members. Most Apache projects practice a minimum threshold meritocracy. We don't expect every committer to be involved in every decision, or cast votes or opinion outside their area of interest or expertise. If three committers/members vote +1, we're good to go. The PMC was not meant to be a legislative body: it's suppose to be the core group, the decision-makers, the active managers, the committers. PMC membership is voluntary. Anyone can resign from the PMC at any time. If a volunteer would like to be a committer, but not a PMC member, then each subproject can then decide whether to support separate committer and PMC member roles or not. I would suggest that there is nothing in this proposal that will cause the board members to have any more faith in Jakarta than they do now. And thats because it changes nothing of significance. It changes everything. It turns Jakarta from a place that is supposedly governed by an other wordly elite to a place that practice minimum threshold meritocracy -- both socially and legally. Today our social order is out-of-synch with our legal status. This proposal legalizes what already happens in practice. * It provides a forum where ALL the decision makers can discuss oversight (not just a chosen few). AND, * It puts reporting in the lap of the decision-makers for each product, which ensures it stays on the *decision-makers* radar, and is not pushed up to some body that cannot possible oversee our products. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Proactively encourage TLP status
Geir, I agree with everything that you said, except one. You have the idea that when a project moves to TLP status it leaves Jakarta, and that saddens you. You said the same thing when Logging was promoted, and Ceki tried to reassure you that it wasn't going far. Although I concur that projects that been promoted to TLP status have reduced their ties somewhat with Jakarta, that need not be the case. If you want Jakarta to be an active community hub, it can be so without a monolothic PMC. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 10:50 AM, Noel J. Bergman wrote: Geir, I agree with everything that you said, except one. You have the idea that when a project moves to TLP status it leaves Jakarta, and that saddens you. In the above sentence, there is one correct statement : .. when a project moves to TLP status, it leaves Jakarta. (this is a correct and true statement) and one sort-of correct statement : ... and that saddens you. As it's bitter-sweet - it's good to see projects come out of Jakarta and continue to grow, and it's sad to see them leave, like when leaving a friend after a visit. What really saddens me is the idea of chasing them out the door. You said the same thing when Logging was promoted, and Ceki tried to reassure you that it wasn't going far. I was 100% supportive of logging going, and hope to see it prosper. However, it did go. :) Although I concur that projects that been promoted to TLP status have reduced their ties somewhat with Jakarta, that need not be the case. If you want Jakarta to be an active community hub, it can be so without a monolothic PMC. Jakarta will always have a PMC. Unless the board changes the Jakarta PMCs responsibilities, the PMC will be responsible for the code and communications of Jakarta. We may allow other Apache projects to have links and resources on our website, for example, but as it is the Jakarta PMC legally required to oversee such resources and activities, it's entirely up to us. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 10:25 AM, Ted Husted wrote: +1 I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND Do you think we all should setup our own individual Wiki page, or work together? I'm getting the feeling you don't want to work together on this. * give notice to each and every Jakarta DEV list that the area exists. My main beef is that we have not done due diligence in alerting ALL of the subprojects of the latest developments. What 'developments'? We are discussing things here on general@, and as far as I can see, we have no developments yet. Ted, you seem to be in a terrible hurry to push this through. Can you wait until people come back from the holiday break and read and catch up? the point of doing things here is to *increase* participation, not reduce it by rushing something through during a generally world-wide western holiday. I've outlined a wiki page as described by this proposal http://nagoya.apache.org/wiki/apachewiki.cgi? JakartaPMCTopLevelProjectApplication, and setup a draft TLP resolution. I would also volunteer to subscribe to each of the DEV lists and post a message pointing them to the archive of this thread. (Unless another volunteer already has an account setup to do such things. ) Instead of doing it yourself, why not try to work w/in the PMC structure and get a message that we all agree on, and have one person from each project on the PMC send to their community. It would be a good step in the direction you just were espousing in a different thread, namely increased participation. Whether a subproject follows through or not can be totally up to each subproject. The important thing is that we do the due diligence in making sure *everyone* concerned has been apprised. LOL. There is no legal requirement that any arbitrary idea that a person has *must* be propagated directly to the dev list of each sub-project. Let others join in this... -Ted. - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:39:30 + Subject: [PROPOSAL] Proactively encourage TLP status There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. SNIP/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
I have added to the wiki http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCTopLevelProjectAppli cation a section on board meeting dates (Jan 21st according to the archives). (If anyone knows a better source, or more dates, please update the wiki). Any suggestions of someone who could comment on the TLP promotion experience. Perhaps Ant or Logging? I suggest we wait before contacting the dev lists until the wiki is more complete. Stephen From: Ted Husted [EMAIL PROTECTED] I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND * give notice to each and every Jakarta DEV list that the area exists. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
On Dec 28, 2003, at 8:43 AM, Ted Husted wrote: * We need to put *all* the decision-markers on the PMC. At Jakarta, that means *all* the committers, and No, it doesn't. We need to put as many as possible, hopefully all, but it's not required to be all. We can also have people that aren't committers on the PMC. * We need to insist that all subprojects file regular reports, with some statutory bullets to ensure everyone is still thinking about consensus and oversight. Erm, I'm not so sure that this needs to be legislated like this. If anyone reading this message agrees, or disagrees, please respond to the As it ever were proposal under another thread. Let's see if we can build a consensus and then create and maintain a solution that works. IMHO, the ASF Way *will* work if we let it; we've just never tried to let it. I don't think that anyone is debating if the ASF works. I think we all know it does. I think we disagree what the ASF Way is - I think it simply requires inclusive participation on the PMC of those willing to feel responsible for more than just the code they are working on, namely project direction and oversight. Thus, the PMC does not necessarily mean forced 100% committer participation, although that percentage is the goal, nor does it mandate strict reporting schedules and reporting content and format. I do believe that if we continue on the way already started - ensuring CLAs, putting as many active Jakarta committers on the PMC as are interested, educating them as to their oversight role, then we would be in a much healthier position and able to then grapple with the day-to-day PMC process. Until we achieve the former, the latter is somewhat of a intellectual game. As you like to point out, we all are adults working for the best interest of the organization. Please work with us on this. geir -- Geir Magnusson Jr 203-247-1713(m) [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]
Re: [PROPOSAL] As it ever were (draft 2)
On Dec 28, 2003, at 10:48 AM, Ted Husted wrote: - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:16:26 + Subject: Re: [PROPOSAL] As it ever were (draft 2) Since the PMC cannot delegate its responsibilities, the report would have to be prepared by a PMC member, ideally one directly involved with subproject. (A likely suspect being the DEV list moderator.) Er, doesn't this just emphasize how broken this process is? Not that I see. It formalizes what should have been done from the beginning. This is getting strangely confusing. What we all have been talking about is getting all possible people from the Jakarta sub-projects on the PMC. In doing that, we have coverage of the codebases, and people will be responsible for things they are involved in, *and*, in the event they see something in a project they aren't involved in, can get involved. I agree w/ Ted, partially. From his previous note, suggesting that specific reporting responsibillity falls to the -dev list moderator, I disagree that this should be requires as this limits participation (instead of 2 possible people, it's back to 1), and might make someone not want to help out via list moderation if it also placed additional requirements on them. We tried to do it before, but we then run into the politics of whether the person making the report is the PMC representative to the subproject. Right - given that any PMC member can report issues, the PMC chair simply summarizes what has been happening over the last month for the board. If subproject foo had nothing interesting going on (i.e. all is well), he or she would either just say that, or omit it alltogether, focusing only on the issues that arose. The fundamental disconnect is that all of the committers should be on the PMC, because all of the committers are the decision-makers for one or more of our various products. 100% true. geir -PROPOSITION (2)- [snip] Work regarding a specific subproject can continue to occur on that subproject's DEV list. PMC members (aka committers) following that list can vote on its releases and other day-to-day affairs. So long as the minimum quorum is met, the vote is legal and binding. So, we are trying to delegate power to subprojects? Er, but we can't now can we. No. We are instituting a minimum threshold meritocracy for each product. The PMC members/committers who are working on a product, and interested in its development, and the ones who make the decisions about that product. That's how it works now socially, and that's how it should work legally. So who can vote? 'Following the list' is a very vague term. Presumably I can simply subscribe to struts-dev and then vote, never having even used struts? It also seems highly dubious to say that a vote is legal and binding if most of the PMC never knew the vote occurred. As it stands today, any of the current PMC members could do exactly that. And, this is also how it works in the Commons today. If I want to chime in on a product and start committing, other volunteers are happy for the help. If you did subscribe to the Struts list and took an interest in the product, I'm sure we'd welcome your commits. You're an Apache Committer, and I'm sure you've earned your stripe. Not by trying to do harm, but by trying to do good. The value of administrative [vote]s on the DEV list are often overrated. A veto must have technical merit to be binding. Malicious vetos are not valid. And, as you know, when someone tried to enforce their own will over the will of the community, the ultimate result (sadly) was a suspension of write access. Under proposition (1), the significant events occurring for each subproject would be reported to the PMC list, for the review of the PMC at-large. So the PMC is reviewing events already happened, not actively managing. Er, sounds like the relationship between the board and a PMC to me. No, the committers to each subproject are committee members. Most Apache projects practice a minimum threshold meritocracy. We don't expect every committer to be involved in every decision, or cast votes or opinion outside their area of interest or expertise. If three committers/members vote +1, we're good to go. The PMC was not meant to be a legislative body: it's suppose to be the core group, the decision-makers, the active managers, the committers. PMC membership is voluntary. Anyone can resign from the PMC at any time. If a volunteer would like to be a committer, but not a PMC member, then each subproject can then decide whether to support separate committer and PMC member roles or not. I would suggest that there is nothing in this proposal that will cause the board members to have any more faith in Jakarta than they do now. And thats because it changes nothing of significance. It changes everything. It turns
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 10:25 AM, Ted Husted wrote: +1 I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND Do you think we all should setup our own individual Wiki page, or work together? I'm getting the feeling you don't want to work together on this. * give notice to each and every Jakarta DEV list that the area exists. My main beef is that we have not done due diligence in alerting ALL of the subprojects of the latest developments. What 'developments'? We are discussing things here on general@, and as far as I can see, we have no developments yet. Ted, you seem to be in a terrible hurry to push this through. Can you wait until people come back from the holiday break and read and catch up? the point of doing things here is to *increase* participation, not reduce it by rushing something through during a generally world-wide western holiday. I've outlined a wiki page as described by this proposal http://nagoya.apache.org/wiki/apachewiki.cgi? JakartaPMCTopLevelProjectApplication, and setup a draft TLP resolution. I would also volunteer to subscribe to each of the DEV lists and post a message pointing them to the archive of this thread. (Unless another volunteer already has an account setup to do such things. ) Instead of doing it yourself, why not try to work w/in the PMC structure and get a message that we all agree on, and have one person from each project on the PMC send to their community. It would be a good step in the direction you just were espousing in a different thread, namely increased participation. Whether a subproject follows through or not can be totally up to each subproject. The important thing is that we do the due diligence in making sure *everyone* concerned has been apprised. LOL. There is no legal requirement that any arbitrary idea that a person has *must* be propagated directly to the dev list of each sub-project. Let others join in this... -Ted. - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:39:30 + Subject: [PROPOSAL] Proactively encourage TLP status There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. SNIP/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [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]
Re: Indemnification of the PMC
Is it my mailer that's making a mess here, or is something else going on? This is the second message I've seen today that is attributed to Ted but was written by someone else (in this case me, in the previous case Stephen) geir On Dec 28, 2003, at 11:13 AM, Ted Husted wrote: On Dec 28, 2003, at 8:43 AM, Ted Husted wrote: * We need to put *all* the decision-markers on the PMC. At Jakarta, that means *all* the committers, and No, it doesn't. We need to put as many as possible, hopefully all, but it's not required to be all. We can also have people that aren't committers on the PMC. * We need to insist that all subprojects file regular reports, with some statutory bullets to ensure everyone is still thinking about consensus and oversight. Erm, I'm not so sure that this needs to be legislated like this. If anyone reading this message agrees, or disagrees, please respond to the As it ever were proposal under another thread. Let's see if we can build a consensus and then create and maintain a solution that works. IMHO, the ASF Way *will* work if we let it; we've just never tried to let it. I don't think that anyone is debating if the ASF works. I think we all know it does. I think we disagree what the ASF Way is - I think it simply requires inclusive participation on the PMC of those willing to feel responsible for more than just the code they are working on, namely project direction and oversight. Thus, the PMC does not necessarily mean forced 100% committer participation, although that percentage is the goal, nor does it mandate strict reporting schedules and reporting content and format. I do believe that if we continue on the way already started - ensuring CLAs, putting as many active Jakarta committers on the PMC as are interested, educating them as to their oversight role, then we would be in a much healthier position and able to then grapple with the day-to-day PMC process. Until we achieve the former, the latter is somewhat of a intellectual game. As you like to point out, we all are adults working for the best interest of the organization. Please work with us on this. geir -- Geir Magnusson Jr 203-247-1713(m) [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] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
From: Geir Magnusson Jr. [EMAIL PROTECTED] What really saddens me is the idea of chasing them out the door. To use an analogy, its like being the parents of a family, where the children, aged from 4 to 40, are all living at home. It strikes me that it isn't healthy for that 40 year old to be living at home, expecting his parents to do the washing, feed him and make his bed. Instead, the good parent should be gently enabling the child to set out on their own in the next phase of their life. Sometimes letting go is the hardest part of being a parent. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Indemnification of the PMC
Geir Magnusson Jr. wrote: Is it my mailer that's making a mess here, or is something else going on? This is the second message I've seen today that is attributed to Ted but was written by someone else (in this case me, in the previous case Stephen) The two messages from Ted Husted that concern you contain: Received: from PC15 (roc-24-93-14-71.rochester.rr.com [24.93.14.71]) which appears to match other messages from Ted. My guess is that Ted started to compose a reply and accidentally sent it before doing any edits. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
Noel J. Bergman wrote: Is it my mailer that's making a mess here, or is something else going on? This is the second message I've seen today that is attributed to Ted but was written by someone else (in this case me, in the previous case Stephen) The two messages from Ted Husted that concern you contain: Received: from PC15 (roc-24-93-14-71.rochester.rr.com [24.93.14.71]) which appears to match other messages from Ted. My guess is that Ted started to compose a reply and accidentally sent it before doing any edits. I think the confusing message (for me at least) was at 11:17 a.m. EST with message-id [EMAIL PROTECTED] It appears from Ted Husted, but it is a replying and criticizing text apparently from Ted Husted. The text even says, Ted, you seem to be.. which is very confusing if the message was *from* Ted. Maybe Ted is playing Devil's advocate with himself? -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
- Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 11:11:07 -0500 Subject: Re: [PROPOSAL] Proactively encourage TLP status On Dec 28, 2003, at 10:25 AM, Ted Husted wrote: +1 I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND Do you think we all should setup our own individual Wiki page, or work together? I'm getting the feeling you don't want to work together on this. Steve made a proposal I supported, so I demonstrated my support by pitching in. AFAIK, there's no such thing as a personal wiki page (which Steve has already proven). * give notice to each and every Jakarta DEV list that the area exists. My main beef is that we have not done due diligence in alerting ALL of the subprojects of the latest developments. What 'developments'? We are discussing things here on general@, and as far as I can see, we have no developments yet. Ted, you seem to be in a terrible hurry to push this through. Can you wait until people come back from the holiday break and read and catch up? the point of doing things here is to *increase* participation, not reduce it by rushing something through during a generally world-wide western holiday. I had some time over the holidays myself, so I put together a proposal that reflected how I believe we should proceed. Other people responded to that, so I made some changes and issued another draft. There were other threads that seemed related to that proposal, so I tried to draw them together to see if we could build a consensus. All I've done is make a proposal for the community to review at its leisure. If a consensus were to develop, I'd volunteer to move it along. If not, the kids need shoes ... I've outlined a wiki page as described by this proposal http://nagoya.apache.org/wiki/apachewiki.cgi? JakartaPMCTopLevelProjectApplication, and setup a draft TLP resolution. I would also volunteer to subscribe to each of the DEV lists and post a message pointing them to the archive of this thread. (Unless another volunteer already has an account setup to do such things. ) Instead of doing it yourself, why not try to work w/in the PMC structure and get a message that we all agree on, and have one person from each project on the PMC send to their community. It would be a good step in the direction you just were espousing in a different thread, namely increased participation. Committers commit. I believe it's something that should be done, so I volunteered to do it. I also mentioned if someone else were ready and willing to do it, I'd be happy to step aside. Whether a subproject follows through or not can be totally up to each subproject. The important thing is that we do the due diligence in making sure *everyone* concerned has been apprised. LOL. There is no legal requirement that any arbitrary idea that a person has *must* be propagated directly to the dev list of each sub-project. Let others join in this... My point is that there is a social and ethical requirement to inform the committers of the status quo. There are many ways in which the points covered on the http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges wiki page conflict with the original guidelines. The only way to ensure everyone is aware of the status quo is for a posting to be made to every DEV list. Since I've served on the PMC, I feel jointly responsible for erroneous information. I don't discharge my responsibilities lightly. I guess all that I'm really asking is that a posting be circulated to each DEV list regarding the proposed changes. As mentioned, I'd be happy to do this myself, or help someone else do it, so long as it was done. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
Mea culpa. I'm trying a new mail client and managed to press the wrong buttons. Sorry for the confusion. -Ted. - Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 11:19:04 -0500 Subject: Re: Indemnification of the PMC Is it my mailer that's making a mess here, or is something else going on? This is the second message I've seen today that is attributed to Ted but was written by someone else (in this case me, in the previous case Stephen) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 11:26 AM, Stephen Colebourne wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] What really saddens me is the idea of chasing them out the door. To use an analogy, its like being the parents of a family, where the children, aged from 4 to 40, are all living at home. It strikes me that it isn't healthy for that 40 year old to be living at home, expecting his parents to do the washing, feed him and make his bed. Instead, the good parent should be gently enabling the child to set out on their own in the next phase of their life. Sometimes letting go is the hardest part of being a parent. It's a good analogy, but makes the assumption that the Jakarta PMC will do for the sub-projects whatever is analogous to the care for children - washing, feeding and bed making. In fact (from my POV anyway), the Jakarta PMC has done no such thing in the past, and should do no such thing in the future. [Some proposals seem to want to enforce bed-making and ironing, but I don't think we should do that...] All we're trying to do is get the PMC populated w/ as many committers as possible, educated as to what oversight means, to satisfy the oversight requirements of the ASF.That's not something to take lightly, but it doesn't mandate additional process, control and procedure either. The board or ASF by-laws require no such scaffolding. Things will continue to be community-centered and decisions community-led. Sub-projects still govern their own activities. The PMC - composed of all the sub-projects - just makes those activities legal, in line w/ the oversight requirements of the ASF, and w/ proper education of the PMC members, helps catch problems. By becoming a TLP, a sub-project has changed nothing other than remove some antiquated-and-should-be-changed Jakarta charter restrictions, and removed itself from the larger community that is Jakarta. And yes, I recognize that people don't believe me about the last point. :) geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Indemnification of the PMC
No worries. I was just truly baffled. geir On Dec 28, 2003, at 11:59 AM, Ted Husted wrote: Mea culpa. I'm trying a new mail client and managed to press the wrong buttons. Sorry for the confusion. -Ted. - Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 11:19:04 -0500 Subject: Re: Indemnification of the PMC Is it my mailer that's making a mess here, or is something else going on? This is the second message I've seen today that is attributed to Ted but was written by someone else (in this case me, in the previous case Stephen) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Proactively encourage TLP status
Geir Magnusson Jr. wrote: it's good to see projects come out of Jakarta and continue to grow, and it's sad to see them leave, like when leaving a friend after a visit. I understand. And I understand why you view Jakarta that way. Why do you not feel that Jakarta could be an active community hub, as has been the subject of several discussions? Jakarta will always have a PMC. Unless the board changes the Jakarta PMCs responsibilities, the PMC will be responsible for the code and communications of Jakarta. The Jakarta PMC must oversee all codebases within its project. This implies that we should start by adding almost all currently active Committers to the Jakarta PMC. That is something the PMC could do, pro-actively, right now without further delay. Taking that action would mean that the majority of Committers would be on the PMC and general lists, improving the ability of the PMC to represent a true consensus of where Jakarta should go, and addressing a concern that we both share regard educating the Committers about their oversight responsibilities. Personally, I don't feel that a 400+ person PMC overseeing dozens of codebases represents a truely functional solution, but we can give it a go. It is my belief that subsequently more projects are going to want to seek TLP status, and that we will be all the better for it in terms of oversight and direct participation. So the question remains whether Jakarta should turn itself into a hub, so that when the subprojects acquire TLP status, they aren't forced to leave the community. it's entirely up to us. Exactly. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
Stephen Colebourne wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] What really saddens me is the idea of chasing them out the door. To use an analogy, its like being the parents of a family, where the children, aged from 4 to 40, are all living at home. It strikes me that it isn't healthy for that 40 year old to be living at home, expecting his parents to do the washing, feed him and make his bed. Instead, the good parent should be gently enabling the child to set out on their own in the next phase of their life. Sometimes letting go is the hardest part of being a parent. Stephen So you consider jakarta subprojects as some children, the PMC that makes the bed and feeds them ? ( and the board as the big brother I suppose:-)? I don't know where did you get this idea, but it seems there are quite a few people who feel like big brothers who know what's better for the childish jakarta projects and would like to encourage them to do what they think is best. I see jakarta more like a union ( EU-style ), were the different projects that joined are mature entities that choose to be part of jakarta ( and can choose to get out - all that's needed is a vote ). And the PMC role is to make sure the rules are respected ( oversight ) - not to wash/feed/make the bed for subprojects. So I'm -1 on your proposal ( if you care counting - it seems most people who propose pushing projects to TLP would do anything to reach this goal - except proposing this in the sub-projects they participate in and counting the resulting votes ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
I think I missed the VOTE thread where this proposal has been approved. So far I've seen 2 +1 and 2 -1 votes ( including mine ), this doesn't seem like a consensus. It's better to wait for the vote to finish ( and it would be nice to have a [VOTE] thread and a time limit ) before starting to do it. Ted, Stephen - you are free to propose or encourage any subproject to do whatever you want - but please make clear that this is your personal opinion or proposal ( unless jakarta PMC or the board votes on this ). But please start with the projects you are dirrectly involved with :-) - I don't think it's a good practice to act as a parent for childs you don't know very well. Costin Geir Magnusson Jr. wrote: On Dec 28, 2003, at 10:25 AM, Ted Husted wrote: +1 I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND Do you think we all should setup our own individual Wiki page, or work together? I'm getting the feeling you don't want to work together on this. * give notice to each and every Jakarta DEV list that the area exists. My main beef is that we have not done due diligence in alerting ALL of the subprojects of the latest developments. What 'developments'? We are discussing things here on general@, and as far as I can see, we have no developments yet. Ted, you seem to be in a terrible hurry to push this through. Can you wait until people come back from the holiday break and read and catch up? the point of doing things here is to *increase* participation, not reduce it by rushing something through during a generally world-wide western holiday. I've outlined a wiki page as described by this proposal http://nagoya.apache.org/wiki/apachewiki.cgi? JakartaPMCTopLevelProjectApplication, and setup a draft TLP resolution. I would also volunteer to subscribe to each of the DEV lists and post a message pointing them to the archive of this thread. (Unless another volunteer already has an account setup to do such things. ) Instead of doing it yourself, why not try to work w/in the PMC structure and get a message that we all agree on, and have one person from each project on the PMC send to their community. It would be a good step in the direction you just were espousing in a different thread, namely increased participation. Whether a subproject follows through or not can be totally up to each subproject. The important thing is that we do the due diligence in making sure *everyone* concerned has been apprised. LOL. There is no legal requirement that any arbitrary idea that a person has *must* be propagated directly to the dev list of each sub-project. Let others join in this... -Ted. - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:39:30 + Subject: [PROPOSAL] Proactively encourage TLP status There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. SNIP/ - 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: Scalability and oversight (Was: Just in case you're curious)
On Dec 27, 2003, at 7:39 PM, Santiago Gala wrote: Scalable because big groups of people can coordinate, even if they don't give specific input or they were not there while the decision was taken. OT: after some light holiday-time reading (Prey from Michael Crichton - http://www.amazon.com/exec/obidos/ASIN/0061015725/), it's funny to try and invent some parallels between open source software communities and the agent swarms outlined in his novel. Freaky. /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: [PROPOSAL] Proactively encourage TLP status
Costin Manolache wrote: I see jakarta more like a union ( EU-style ), were the different projects that joined are mature entities that choose to be part of jakarta ( and can choose to get out - all that's needed is a vote ). And the PMC role is to make sure the rules are respected Project maturity aside, I was with you up until the last sentence. The PMC is supposed to be performing the active management of one or more projects, not ensuring that other people are doing it. The PMC is not supposed to be a body of auditors. I see your analogy as describing self-managing bodies, i.e., projects with their own PMC, who operate a collective for the common good. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Proactively encourage TLP status
-1 I don't think the PMC should be doing anything other than encouraging sub-projects to *consider* TLP at this stage. The proposal contains a number of detailed actions most of which I'd wholeheartedly support as they will help sub-projects to consider pro's and con's of promotion. However I think it is inappropriate to be talking about proactively encouraging proposal then vote. I would much rather that individuals who are active participants in the sub-project reach this stage, or don't, without having being prompted by the PMC. For the record I think that many sub-projects would benefit from promotion, but not all of them, but I think the process would be made much harder is the sub-project is hustled into applying before the participants are really comfortable with the nature and consequences of the change. d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 1:42 PM, Noel J. Bergman wrote: Geir Magnusson Jr. wrote: it's good to see projects come out of Jakarta and continue to grow, and it's sad to see them leave, like when leaving a friend after a visit. I understand. And I understand why you view Jakarta that way. Why do you not feel that Jakarta could be an active community hub, as has been the subject of several discussions? I just don't think it will happen. It will be a website at best, and a bad website at worst. As an example, look at the difference between Jakarta Commons to Apache Commons. Jakarta will always have a PMC. Unless the board changes the Jakarta PMCs responsibilities, the PMC will be responsible for the code and communications of Jakarta. The Jakarta PMC must oversee all codebases within its project. And it's website, the project websites, the mail lists and the usage of CVS. This implies that we should start by adding almost all currently active Committers to the Jakarta PMC. That's what we're trying to do. That is something the PMC could do, pro-actively, right now without further delay. Taking that action would mean that the majority of Committers would be on the PMC and general lists, improving the ability of the PMC to represent a true consensus of where Jakarta should go, and addressing a concern that we both share regard educating the Committers about their oversight responsibilities. But we've discussed this, and just glomming everyone wouldn't result in the best outcome as we want to make sure that people are explicitly signing up for project oversight, rather than being drafted to meet a quota. Personally, I don't feel that a 400+ person PMC overseeing dozens of codebases represents a truely functional solution, but we can give it a go. I can't see why not. The point of oversight is to catch the cases where things aren't right (i.e. code comes into the CVS that shouldn't w/o incubation) rather than continuously report when things are going well. It is my belief that subsequently more projects are going to want to seek TLP status, and that we will be all the better for it in terms of oversight and direct participation. So the question remains whether Jakarta should turn itself into a hub, so that when the subprojects acquire TLP status, they aren't forced to leave the community. I think a lot of what you say presupposed some sort of onerous additional work that comes from being a part of the Jakarta PMC. I would argue that it's no different - if you are providing oversight independently of Jakarta or part of Jakarta, it's the same amount of work. The question is how much value you place on Jakarta as a community versus Jakarta as a website. Again, I'll suggest that Jakarta Commons and Apache Commons might illustrate a bit about what I keep [unsuccessfully] trying to say. geir it's entirely up to us. Exactly. :-) --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 3:44 PM, Noel J. Bergman wrote: Costin Manolache wrote: I see jakarta more like a union ( EU-style ), were the different projects that joined are mature entities that choose to be part of jakarta ( and can choose to get out - all that's needed is a vote ). And the PMC role is to make sure the rules are respected Project maturity aside, I was with you up until the last sentence. Then you haven't seen what the EU has been up to :) Talk about over-regulation... The PMC is supposed to be performing the active management of one or more projects, not ensuring that other people are doing it. The PMC is not supposed to be a body of auditors. I see your analogy as describing self-managing bodies, i.e., projects with their own PMC, who operate a collective for the common good. Because the PMC would consist of those doing the active management (i.e. the active, interested committers) , we have things covered. geir --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 3:49 PM, Danny Angus wrote: -1 I don't think the PMC should be doing anything other than encouraging sub-projects to *consider* TLP at this stage. I don't even think they should do that. I don't think the PMC should take a position either way. I don't think there should be any communication that can even be confused as coming from the PMC. The proposal contains a number of detailed actions most of which I'd wholeheartedly support as they will help sub-projects to consider pro's and con's of promotion. However I think it is inappropriate to be talking about proactively encouraging proposal then vote. I would much rather that individuals who are active participants in the sub-project reach this stage, or don't, without having being prompted by the PMC. For the record I think that many sub-projects would benefit from promotion, but not all of them, but I think the process would be made much harder is the sub-project is hustled into applying before the participants are really comfortable with the nature and consequences of the change. And I think that once we have the PMC enlarged with all active, interested committers, these kinds of discussions and awareness will be a natural, open thing, not requiring any special schemes or campaigns geir d. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
Firstly, having details collected together in one place for 'how to become a TLP' is a good thing IMHO. I doubt you are asking us to deny information to subprojects, are you? Secondly, I am acting because I have been the responsibility to act. As a Jakarta PMC member I have direct responsibility for ALL Jakarta subprojects. I am trying to discharge that responsibilty as best I can. If I were unwilling to to this then I should resign, which I don't feel like doing quite yet. Thirdly, this was marked as a proposal, and was asking for views to determine whether a consensus or vote should be held. I believe I do have the right to start a proposal thread. I was also concerned that those members of this list who support a sticking plaster approach were becoming the only voices heard. Finally, the time to vote on Jakarta-Commons is not now, because, as has been pointed out, of the holidays. I would also suggest that J-C contains many of the people talking on this list, so debating here is not without merit. (ie. J-C is unique amongst all dev lists in participation from other Jakarta subprojects - it might also naturally inherit the Jakarta name if all other subprojects left, which complicates the vote) Stephen From: Costin Manolache [EMAIL PROTECTED] Ted, Stephen - you are free to propose or encourage any subproject to do whatever you want - but please make clear that this is your personal opinion or proposal ( unless jakarta PMC or the board votes on this ). But please start with the projects you are dirrectly involved with :-) - I don't think it's a good practice to act as a parent for childs you don't know very well. Costin Geir Magnusson Jr. wrote: On Dec 28, 2003, at 10:25 AM, Ted Husted wrote: +1 I agree that interested volunteers should: * setup a Wiki area describing the TLP process and rationales , AND Do you think we all should setup our own individual Wiki page, or work together? I'm getting the feeling you don't want to work together on this. * give notice to each and every Jakarta DEV list that the area exists. My main beef is that we have not done due diligence in alerting ALL of the subprojects of the latest developments. What 'developments'? We are discussing things here on general@, and as far as I can see, we have no developments yet. Ted, you seem to be in a terrible hurry to push this through. Can you wait until people come back from the holiday break and read and catch up? the point of doing things here is to *increase* participation, not reduce it by rushing something through during a generally world-wide western holiday. I've outlined a wiki page as described by this proposal http://nagoya.apache.org/wiki/apachewiki.cgi? JakartaPMCTopLevelProjectApplication, and setup a draft TLP resolution. I would also volunteer to subscribe to each of the DEV lists and post a message pointing them to the archive of this thread. (Unless another volunteer already has an account setup to do such things. ) Instead of doing it yourself, why not try to work w/in the PMC structure and get a message that we all agree on, and have one person from each project on the PMC send to their community. It would be a good step in the direction you just were espousing in a different thread, namely increased participation. Whether a subproject follows through or not can be totally up to each subproject. The important thing is that we do the due diligence in making sure *everyone* concerned has been apprised. LOL. There is no legal requirement that any arbitrary idea that a person has *must* be propagated directly to the dev list of each sub-project. Let others join in this... -Ted. - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:39:30 + Subject: [PROPOSAL] Proactively encourage TLP status There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. SNIP/ - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
Re: [PROPOSAL] Proactively encourage TLP status
From: Geir Magnusson Jr. [EMAIL PROTECTED] I think a lot of what you say presupposed some sort of onerous additional work that comes from being a part of the Jakarta PMC. I would argue that it's no different - if you are providing oversight independently of Jakarta or part of Jakarta, it's the same amount of work. Well this is a key point. I believe that now I am a Jakarta PMC member I have direct responsibility for ALL subprojects. Given the breadth of Jakarta this is a ridiculous position. So, it is more work. Much more work. For example, I have spent much less time coding in the last 4 weeks. And thats just plain wrong. If I'm not careful, I'll go crazy like Robert. So I may choose to leave the PMC. Others will too, either actually resign, or just ignore it. Oversight is NOT increased - the basic approach of sign 'em up is flawed. The question is how much value you place on Jakarta as a community versus Jakarta as a website. The communities are the subprojects. Again, I'll suggest that Jakarta Commons and Apache Commons might illustrate a bit about what I keep [unsuccessfully] trying to say. Sorry, but I don't get you. A-C was a board invention. If it didn't exist then J-C would be able to TLP cleanly. Perhaps you need to explain more. In fact, perhaps you should set out in a separate thread as to where you see Jakarta in 3-6 months time. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 4:44 PM, Stephen Colebourne wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] I think a lot of what you say presupposed some sort of onerous additional work that comes from being a part of the Jakarta PMC. I would argue that it's no different - if you are providing oversight independently of Jakarta or part of Jakarta, it's the same amount of work. Well this is a key point. I believe that now I am a Jakarta PMC member I have direct responsibility for ALL subprojects. Given the breadth of Jakarta this is a ridiculous position. So, it is more work. Much more work. For example, I have spent much less time coding in the last 4 weeks. And thats just plain wrong. We need to get that view corrected, because there is *nothing* that states that every member of the PMC is *directly* responsible for ever part of every code, doc, mail list and CVS usage in Jakarta, the key word is directly. Think about it. How could this possibly work in ANY ASF project of any useful size? You couldn't do a Commons TLP (be it A-C or J-C) if every participant was directly and personally responsible for every shred of activity. Here is what the ASF bylaws say : Subject to the direction of the Board of Directors, the chairman of each Project Management Committee shall be primarily responsible for project(s) managed by such committee, and he or she shall establish rules and procedures for the day to day management of project(s) for which the committee is responsible A reasonable person should *not* read this to mean the PMC chair is directly, actively responsible in that he or she must read every commit, watch ever mail list, and see every site and wiki change - rather he or she is able and required to organize the day-to-day management as he or she sees fit (subject to board approval) such that all code, site, mail and wiki's are covered by active, responsible oversight. In the event that the management does *not* do this, the chair is responsible, but that's a huge difference from the 'every shred' model. Therefore I would think that given we have coverage of more than one committer per sub-project on the PMC, and those committers understand the oversight role and are actively performing that role, then the Jakarta PMC is compliant with the requirements of the ASF, is scalable, and puts minimal additional responsibility on those on the PMC. Isn't that reasonable? If I'm not careful, I'll go crazy like Robert. So I may choose to leave the PMC. Others will too, either actually resign, or just ignore it. Oversight is NOT increased - the basic approach of sign 'em up is flawed. sign 'em up is flawed, but not for the reason above (which I think is simply a misunderstanding on your part.) It's flawed because we can't assert that those tasked with oversight (of their projects) on behalf of the ASF as PMC member is doing their job is they didn't ask to do it and/or be trained to do it. I first floated the 'deputize them all' approach on the PMC list a while ago, and I'll be the first to say that I was wrong. The question is how much value you place on Jakarta as a community versus Jakarta as a website. The communities are the subprojects. And the subprojects together are also a community. I'm not the only one that recognizes this. Again, I'll suggest that Jakarta Commons and Apache Commons might illustrate a bit about what I keep [unsuccessfully] trying to say. Sorry, but I don't get you. A-C was a board invention. If it didn't exist then J-C would be able to TLP cleanly. Perhaps you need to explain more. In fact, perhaps you should set out in a separate thread as to where you see Jakarta in 3-6 months time. I'll be happy to do the latter. As for the former: A-C was a board invention, as you note, and I think a well-intentioned one. However, after 14 months, it has a single codebase (a http client written in C). J-C was a 'bottom-up' effort of multiple people in the Jakarta community from many *different* sub-projects that self-organized, debated independently (and incessantly) about the charter, presented the proposal to the PMC, had it approved and then rolled up their sleeves and got to work, with the resulting vibrant, productive community. The fact that participants from multiple sub-projects were the force behind J-C (and not the PMC or the board) to me validates my assertion that Jakarta as a whole is also a community. geir -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Proactively encourage TLP status
Geir Magnusson Jr. wrote: you haven't seen what the EU has been up to :) Talk about over-regulation... LOL :-) OK, so it is a bad analogy. I don't believe that either Costin or I live in the EU. The PMC is supposed to be performing the active management of one or more projects, not ensuring that other people are doing it. The PMC is not supposed to be a body of auditors. I see your analogy as describing self-managing bodies, i.e., projects with their own PMC, who operate a collective for the common good. Because the PMC would consist of those doing the active management (i.e. the active, interested committers) , we have things covered. As I've said, let's do it. Get them on. And then see which projects decide to form their own PMC. The issue I was commenting on is not to lose a sense of community with those projects who choose to form their own PMC. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
From: Geir Magnusson Jr. [EMAIL PROTECTED] We need to get that view corrected, because there is *nothing* that states that every member of the PMC is *directly* responsible for ever part of every code, doc, mail list and CVS usage in Jakarta, the key word is directly. As a PMC member, I should care whether there is a new Tapestry release, or a new Lucene committer. These are PMC votes (or should be). But I don't care (especially ;-). Thus there is a tension between my mandated responsibility and my actual interests. This aspect of 'do I care' is key. I read every vote on J-C, I may not choose to vote (since adding lots of +0's wastes space), but I care about the release or new committer. But I don't care about Lucene. Not one jot. Yet I have equal responsibility for it. This just isn't right. All I have heard from the original ASF projects indicate to me that the PMC should represent one codebase and one tight community. Anything else leads to a layer of management separate from the codebase (aka Jakarta PMC). All the current debates exist because we have a layer of management which we do not need. These debates waste vast amounts of time and energy. Thus PMC members are given the choice: - debate/manage continuously and don't code, or - code and ignore the PMC I'm unusual in that I'm bothering putting any effort at all into the former. It won't be long before I'll give up and do the latter. Your POV will win on the PMC because everyone else has better things to do than argue incesantly. Therefore I would think that given we have coverage of more than one committer per sub-project on the PMC, and those committers understand the oversight role and are actively performing that role, then the Jakarta PMC is compliant with the requirements of the ASF, is scalable, and puts minimal additional responsibility on those on the PMC. Isn't that reasonable? No. What you are arguing for is just not human nature. As long as there is a PMC away from the dev list, with other people from the dev list, with other responsibilities and issues, people will not associate with it. People look after what they own, and don't care about what they don't own. They may be on the PMC in name, but that simply isn't enough. It really isn't. The fact that participants from multiple sub-projects were the force behind J-C (and not the PMC or the board) to me validates my assertion that Jakarta as a whole is also a community. The question that we cannot know the answer to (without a time machine) is whether the same result would have occurred if Jakarta had not existed. ie. Is J-C a product of Jakarta, or a product of the need for shared Java code. You believe its the former, I wasn't around so can't really comment, however I see no great reason why exactly the same J-C couldn't have occurred without Jakarta. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
I'll try to be brief. I agree w/ you - I don't want to have to watch ever project. I'm also not interested in endless debate. I'm also not interested in legislation, process or overbearing procedure. And I'm not interested in breaking up Jakarta. All I want to do is get CLAs signed and maximize participation on the PMC that covers all projects to satisfy the ASF oversight requirements. My only concern about Lucene (to use your example) is that the code that comes into the ASF's CVS is free from any problems of provenance, and that the releases are done with the support of the Lucene community, and I would be comfortable w/ that if I knew that the active participants of the Lucene community were on the PMC and understood what the PMC does. (Note that we are not advocating any layer of management separate from the codebase, and have not had that to date.) As I think that your view of your responsibilities as a PMC members is mistaken. I'll ask for a clarification of the responsibilities from someone outside of Jakarta w/ no stake in this debate. I too have no interest in being forced to be involved w/ any project other than those I choose to participate in. geir On Dec 28, 2003, at 7:05 PM, Stephen Colebourne wrote: From: Geir Magnusson Jr. [EMAIL PROTECTED] We need to get that view corrected, because there is *nothing* that states that every member of the PMC is *directly* responsible for ever part of every code, doc, mail list and CVS usage in Jakarta, the key word is directly. As a PMC member, I should care whether there is a new Tapestry release, or a new Lucene committer. These are PMC votes (or should be). But I don't care (especially ;-). Thus there is a tension between my mandated responsibility and my actual interests. This aspect of 'do I care' is key. I read every vote on J-C, I may not choose to vote (since adding lots of +0's wastes space), but I care about the release or new committer. But I don't care about Lucene. Not one jot. Yet I have equal responsibility for it. This just isn't right. All I have heard from the original ASF projects indicate to me that the PMC should represent one codebase and one tight community. Anything else leads to a layer of management separate from the codebase (aka Jakarta PMC). All the current debates exist because we have a layer of management which we do not need. These debates waste vast amounts of time and energy. Thus PMC members are given the choice: - debate/manage continuously and don't code, or - code and ignore the PMC I'm unusual in that I'm bothering putting any effort at all into the former. It won't be long before I'll give up and do the latter. Your POV will win on the PMC because everyone else has better things to do than argue incesantly. Therefore I would think that given we have coverage of more than one committer per sub-project on the PMC, and those committers understand the oversight role and are actively performing that role, then the Jakarta PMC is compliant with the requirements of the ASF, is scalable, and puts minimal additional responsibility on those on the PMC. Isn't that reasonable? No. What you are arguing for is just not human nature. As long as there is a PMC away from the dev list, with other people from the dev list, with other responsibilities and issues, people will not associate with it. People look after what they own, and don't care about what they don't own. They may be on the PMC in name, but that simply isn't enough. It really isn't. The fact that participants from multiple sub-projects were the force behind J-C (and not the PMC or the board) to me validates my assertion that Jakarta as a whole is also a community. The question that we cannot know the answer to (without a time machine) is whether the same result would have occurred if Jakarta had not existed. ie. Is J-C a product of Jakarta, or a product of the need for shared Java code. You believe its the former, I wasn't around so can't really comment, however I see no great reason why exactly the same J-C couldn't have occurred without Jakarta. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESULT][VOTE] ORO 2.0.8 maintenance release
The resolution to approve a 2.0.8 maintenance release of jakarta-oro has passed with 4 binding +1 votes from Jakarta PMC members and no -1 votes. Many thanks to all who voted. I will now proceed to package and upload a release for distribution, update appropriate Web pages, and email an announcement after 24 hours to give sufficient time for mirrors to pick up the release. A summary of the voting results follows: Binding +1 Votes: Geir Magnusson Jr geir.4quarters.com Craig McClanahan cragmcc.apache.org Scott Sanders scott.dotnot.org Daniel Savaresedfs.savarese.org Non-Binding +1 Votes: Gary Gregory ggregory.seagullsw.com (PMC membership pending paperwork) Mark F. Murphy markm.tyrell.com (oro user and code contributor) Takashi Okamototoraneko.kun.ne.jp (oro user and code contributor) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were (draft 2)
Ted: First off - appologies because I havn't read every message on Jakarta. But it seems to me that someone has said that the very notion of federation employed by the board to facilitate management (i.e. the establishment of sub-structures) is for some reason not-allowed beyond the level of the board (that's just a conclusion based on recent posts to this list). Basically I agree with just about everthing you saying in you message - but I'm seeing what appears to be a group attempting to work around constraints that eliminate the potential for composite projects. AFAIAC, if Jakarta put in place an appropriate managemrnt model (involving sub-PMC or whatever), is there anything politically incorrect with that approach? Stephen. Ted Husted wrote: - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:16:26 + Subject: Re: [PROPOSAL] As it ever were (draft 2) Since the PMC cannot delegate its responsibilities, the report would have to be prepared by a PMC member, ideally one directly involved with subproject. (A likely suspect being the DEV list moderator.) Er, doesn't this just emphasize how broken this process is? Not that I see. It formalizes what should have been done from the beginning. We tried to do it before, but we then run into the politics of whether the person making the report is the PMC representative to the subproject. The fundamental disconnect is that all of the committers should be on the PMC, because all of the committers are the decision-makers for one or more of our various products. -PROPOSITION (2)- [snip] Work regarding a specific subproject can continue to occur on that subproject's DEV list. PMC members (aka committers) following that list can vote on its releases and other day-to-day affairs. So long as the minimum quorum is met, the vote is legal and binding. So, we are trying to delegate power to subprojects? Er, but we can't now can we. No. We are instituting a minimum threshold meritocracy for each product. The PMC members/committers who are working on a product, and interested in its development, and the ones who make the decisions about that product. That's how it works now socially, and that's how it should work legally. So who can vote? 'Following the list' is a very vague term. Presumably I can simply subscribe to struts-dev and then vote, never having even used struts? It also seems highly dubious to say that a vote is legal and binding if most of the PMC never knew the vote occurred. As it stands today, any of the current PMC members could do exactly that. And, this is also how it works in the Commons today. If I want to chime in on a product and start committing, other volunteers are happy for the help. If you did subscribe to the Struts list and took an interest in the product, I'm sure we'd welcome your commits. You're an Apache Committer, and I'm sure you've earned your stripe. Not by trying to do harm, but by trying to do good. The value of administrative [vote]s on the DEV list are often overrated. A veto must have technical merit to be binding. Malicious vetos are not valid. And, as you know, when someone tried to enforce their own will over the will of the community, the ultimate result (sadly) was a suspension of write access. Under proposition (1), the significant events occurring for each subproject would be reported to the PMC list, for the review of the PMC at-large. So the PMC is reviewing events already happened, not actively managing. Er, sounds like the relationship between the board and a PMC to me. No, the committers to each subproject are committee members. Most Apache projects practice a minimum threshold meritocracy. We don't expect every committer to be involved in every decision, or cast votes or opinion outside their area of interest or expertise. If three committers/members vote +1, we're good to go. The PMC was not meant to be a legislative body: it's suppose to be the core group, the decision-makers, the active managers, the committers. PMC membership is voluntary. Anyone can resign from the PMC at any time. If a volunteer would like to be a committer, but not a PMC member, then each subproject can then decide whether to support separate committer and PMC member roles or not. I would suggest that there is nothing in this proposal that will cause the board members to have any more faith in Jakarta than they do now. And thats because it changes nothing of significance. It changes everything. It turns Jakarta from a place that is supposedly governed by an other wordly elite to a place that practice minimum threshold meritocracy -- both socially and legally. Today our social order is out-of-synch with our legal status. This proposal legalizes what already happens in practice. * It provides a forum where ALL the
Re: [PROPOSAL] As it ever were (draft 2)
On Dec 28, 2003, at 7:51 PM, Stephen McConnell wrote: Ted: First off - appologies because I havn't read every message on Jakarta. But it seems to me that someone has said that the very notion of federation employed by the board to facilitate management (i.e. the establishment of sub-structures) is for some reason not-allowed beyond the level of the board (that's just a conclusion based on recent posts to this list). Basically I agree with just about everthing you saying in you message - but I'm seeing what appears to be a group attempting to work around constraints that eliminate the potential for composite projects. AFAIAC, if Jakarta put in place an appropriate managemrnt model (involving sub-PMC or whatever), is there anything politically incorrect with that approach? As far as I know, there is nothing that prevents any sub-structures. However, one school of thought (the one I subscribe to) believes that substructures aren't needed. As we aren't trying to manage from above, but rather trying aggregate oversight from below by bringing interested committers into the PMC and providing education on oversight. geir Stephen. Ted Husted wrote: - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:16:26 + Subject: Re: [PROPOSAL] As it ever were (draft 2) Since the PMC cannot delegate its responsibilities, the report would have to be prepared by a PMC member, ideally one directly involved with subproject. (A likely suspect being the DEV list moderator.) Er, doesn't this just emphasize how broken this process is? Not that I see. It formalizes what should have been done from the beginning. We tried to do it before, but we then run into the politics of whether the person making the report is the PMC representative to the subproject. The fundamental disconnect is that all of the committers should be on the PMC, because all of the committers are the decision-makers for one or more of our various products. -PROPOSITION (2)- [snip] Work regarding a specific subproject can continue to occur on that subproject's DEV list. PMC members (aka committers) following that list can vote on its releases and other day-to-day affairs. So long as the minimum quorum is met, the vote is legal and binding. So, we are trying to delegate power to subprojects? Er, but we can't now can we. No. We are instituting a minimum threshold meritocracy for each product. The PMC members/committers who are working on a product, and interested in its development, and the ones who make the decisions about that product. That's how it works now socially, and that's how it should work legally. So who can vote? 'Following the list' is a very vague term. Presumably I can simply subscribe to struts-dev and then vote, never having even used struts? It also seems highly dubious to say that a vote is legal and binding if most of the PMC never knew the vote occurred. As it stands today, any of the current PMC members could do exactly that. And, this is also how it works in the Commons today. If I want to chime in on a product and start committing, other volunteers are happy for the help. If you did subscribe to the Struts list and took an interest in the product, I'm sure we'd welcome your commits. You're an Apache Committer, and I'm sure you've earned your stripe. Not by trying to do harm, but by trying to do good. The value of administrative [vote]s on the DEV list are often overrated. A veto must have technical merit to be binding. Malicious vetos are not valid. And, as you know, when someone tried to enforce their own will over the will of the community, the ultimate result (sadly) was a suspension of write access. Under proposition (1), the significant events occurring for each subproject would be reported to the PMC list, for the review of the PMC at-large. So the PMC is reviewing events already happened, not actively managing. Er, sounds like the relationship between the board and a PMC to me. No, the committers to each subproject are committee members. Most Apache projects practice a minimum threshold meritocracy. We don't expect every committer to be involved in every decision, or cast votes or opinion outside their area of interest or expertise. If three committers/members vote +1, we're good to go. The PMC was not meant to be a legislative body: it's suppose to be the core group, the decision-makers, the active managers, the committers. PMC membership is voluntary. Anyone can resign from the PMC at any time. If a volunteer would like to be a committer, but not a PMC member, then each subproject can then decide whether to support separate committer and PMC member roles or not. I would suggest that there is nothing in this proposal that will cause the board members to have any more faith in Jakarta than they do now. And thats because it changes
Re: [PROPOSAL] Proactively encourage TLP status
On Dec 28, 2003, at 6:05 PM, Noel J. Bergman wrote: Geir Magnusson Jr. wrote: you haven't seen what the EU has been up to :) Talk about over-regulation... LOL :-) OK, so it is a bad analogy. I don't believe that either Costin or I live in the EU. I don't either. I live in Connecticut, USA. I was always suspicious that something was amiss trying to integrate proud countries with long individual histories, but it was confirmed the first time I had to schelp from Terminal 4 to Terminal 3 at Heathrow just so I could pick up the bus to Reading, which used to stop at all 4 terminals, but stopped going to terminal 4 because EU regs said the total trip was too long. The whole thing is something like an hour. :/ You also can't get soft cheese at a reasonable temperature in a restaurant under EU regs. They must keep them cold until being served. Ug. The PMC is supposed to be performing the active management of one or more projects, not ensuring that other people are doing it. The PMC is not supposed to be a body of auditors. I see your analogy as describing self-managing bodies, i.e., projects with their own PMC, who operate a collective for the common good. Because the PMC would consist of those doing the active management (i.e. the active, interested committers) , we have things covered. As I've said, let's do it. Get them on. And then see which projects decide to form their own PMC. The issue I was commenting on is not to lose a sense of community with those projects who choose to form their own PMC. True. geir --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] As it ever were (draft 2)
Geir Magnusson Jr. wrote: On Dec 28, 2003, at 7:51 PM, Stephen McConnell wrote: Ted: First off - appologies because I havn't read every message on Jakarta. But it seems to me that someone has said that the very notion of federation employed by the board to facilitate management (i.e. the establishment of sub-structures) is for some reason not-allowed beyond the level of the board (that's just a conclusion based on recent posts to this list). Basically I agree with just about everthing you saying in you message - but I'm seeing what appears to be a group attempting to work around constraints that eliminate the potential for composite projects. AFAIAC, if Jakarta put in place an appropriate managemrnt model (involving sub-PMC or whatever), is there anything politically incorrect with that approach? As far as I know, there is nothing that prevents any sub-structures. However, one school of thought (the one I subscribe to) believes that substructures aren't needed. As we aren't trying to manage from above, but rather trying aggregate oversight from below by bringing interested committers into the PMC and providing education on oversight. Your sentiments are very close to my own. But instead of thinking about substructures as unit to mange - think about substructures as units that provide a Jakarta PMC with information that you need in order to fulfil the reposibilities of the Jakarta PMC. Its' like saying - hey guys - a bunch of Jakart PMC members cannot do everyting alone - we need some support - and one way to get support is to put in some structure (a.k.a. delegation of reponsibility) to the subprojects that the Jakarta PMC is responsible for. If those subprojects jump-up and say - hey, here is an elected representative who hase volunteered to keep you up to date and even better - they say our elected representative is only there to present the opinion of a bunch of a committed committers - and by the way - we are calling ourselves a PMC or XPM or ZPC or whatever. Bottom line - I was involved with an unmanged suproject of Jakarta. That project has now exited Jakarta because the Board provided the management model. What I'm thinking is that there is no reason why the Jakarta PMC cannot provide the environment to its subproject (i.e. provide the managemewnt model) to take on responsibility - and though this, strengthen and support the Jakarta PMC. Stephen. geir Stephen. Ted Husted wrote: - Original message From: Stephen Colebourne [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 14:16:26 + Subject: Re: [PROPOSAL] As it ever were (draft 2) Since the PMC cannot delegate its responsibilities, the report would have to be prepared by a PMC member, ideally one directly involved with subproject. (A likely suspect being the DEV list moderator.) Er, doesn't this just emphasize how broken this process is? Not that I see. It formalizes what should have been done from the beginning. We tried to do it before, but we then run into the politics of whether the person making the report is the PMC representative to the subproject. The fundamental disconnect is that all of the committers should be on the PMC, because all of the committers are the decision-makers for one or more of our various products. -PROPOSITION (2)- [snip] Work regarding a specific subproject can continue to occur on that subproject's DEV list. PMC members (aka committers) following that list can vote on its releases and other day-to-day affairs. So long as the minimum quorum is met, the vote is legal and binding. So, we are trying to delegate power to subprojects? Er, but we can't now can we. No. We are instituting a minimum threshold meritocracy for each product. The PMC members/committers who are working on a product, and interested in its development, and the ones who make the decisions about that product. That's how it works now socially, and that's how it should work legally. So who can vote? 'Following the list' is a very vague term. Presumably I can simply subscribe to struts-dev and then vote, never having even used struts? It also seems highly dubious to say that a vote is legal and binding if most of the PMC never knew the vote occurred. As it stands today, any of the current PMC members could do exactly that. And, this is also how it works in the Commons today. If I want to chime in on a product and start committing, other volunteers are happy for the help. If you did subscribe to the Struts list and took an interest in the product, I'm sure we'd welcome your commits. You're an Apache Committer, and I'm sure you've earned your stripe. Not by trying to do harm, but by trying to do good. The value of administrative [vote]s on the DEV list are often overrated. A veto must have technical merit to be binding. Malicious vetos are not valid. And, as you know, when someone tried
Re: [PROPOSAL] Proactively encourage TLP status
Geir Magnusson Jr. wrote: You also can't get soft cheese at a reasonable temperature in a restaurant under EU regs. They must keep them cold until being served. Ug. I can help you out on this particular subject! No shortage of soft cheese ready for a stated day of delivery where live. 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: [PROPOSAL] Proactively encourage TLP status
Stephen McConnell wrote: Geir Magnusson Jr. wrote: You also can't get soft cheese at a reasonable temperature in a restaurant under EU regs. They must keep them cold until being served. Ug. I can help you out on this particular subject! No shortage of soft cheese ready for a stated day of delivery where live. s/where live/where I live SJM 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: EU analogy [PROPOSAL] Proactively encourage TLP status
you haven't seen what the EU has been up to :) Talk about over-regulation... LOL :-) OK, so it is a bad analogy. I don't believe that either Costin or I live in the EU. I don't either. I live in Connecticut, USA. I was always suspicious that something was amiss trying to integrate proud countries with long individual histories, but it was confirmed the first time I had to schelp from Terminal 4 to Terminal 3 at Heathrow just so I could pick up the bus to Reading, which used to stop at all 4 terminals, but stopped going to terminal 4 because EU regs said the total trip was too long. The whole thing is something like an hour. :/ I live in the UK, so can comment ;-) The thing that I spot about the EU is that is is often used as a scapegoat. When individual countries (or often the media) wants to shift blame it is convenient. This comes about because citizens of each country identify more with their own country than with the EU. (Note: I believe that the EU does a lot of good, but it'll never be my country) Perhaps the parallel is that a Struts 'citizen' identifies more with the Struts 'country' than the Jakarta 'union'. Of course one key difference is that we don't have the individual governments at the country/Struts level. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EU analogy [PROPOSAL] Proactively encourage TLP status
Stephen Colebourne wrote: you haven't seen what the EU has been up to :) Talk about over-regulation... LOL :-) OK, so it is a bad analogy. I don't believe that either Costin or I live in the EU. I don't either. I live in Connecticut, USA. I was always suspicious that something was amiss trying to integrate proud countries with long individual histories, but it was confirmed the first time I had to schelp from Terminal 4 to Terminal 3 at Heathrow just so I could pick up the bus to Reading, which used to stop at all 4 terminals, but stopped going to terminal 4 because EU regs said the total trip was too long. The whole thing is something like an hour. :/ I live in the UK, so can comment ;-) The thing that I spot about the EU is that is is often used as a scapegoat. When individual countries (or often the media) wants to shift blame it is convenient. This comes about because citizens of each country identify more with their own country than with the EU. (Note: I believe that the EU does a lot of good, but it'll never be my country) Perhaps the parallel is that a Struts 'citizen' identifies more with the Struts 'country' than the Jakarta 'union'. Of course one key difference is that we don't have the individual governments at the country/Struts level. +100 Stephen. 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: EU analogy [PROPOSAL] Proactively encourage TLP status
On Mon, 29 Dec 2003 02:45:18 +0100 Stephen McConnell wrote: Perhaps the parallel is that a Struts 'citizen' identifies more with the Struts 'country' than the Jakarta 'union'. Of course one key difference is that we don't have the individual governments at the country/Struts level. +100 Since i introduced EU analogy to this list a few days ago :), I comment. -- As the Name Apache and the lex causae would be highly related to the United States, I was wondering what would fit to describe Apache and Jakarta communities themselves, and have been casting about in my mind for good words. Well, there could be two styles of the OSS communities -- American Style (United States) .. (1) -- European Style (Union of Nations) ... (2) What I could perceive from the participation to this community was the latter style. So, I used EU analogy. The keyword would be Identity. Yes, I know that we can rather describe the history of the Apache/Jakarta better by using United States styled analogy, however, the strong Identity of the each communities in Apache realm can be described by EU analogy better, i suspect. Please do not use the analogy in order to dispute forever. Please use it in order to strengthen the understandings of the community and to achieve the improvement of the community. (1) and (2) have their own good points. Piling up good points would be one of the key factors which can keep the health of the OSS communities. I am not in the United states nor in Europe. Thanks, -- Tetsuya. ([EMAIL PROTECTED]) P.S. (1) --- related to right-side cerebral cortex in brain (2) --- related to right-side limbic system in brain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-site2/docs/site binindex.html sourceindex.html
dfs 2003/12/28 20:32:37 Modified:xdocs/site binindex.xml sourceindex.xml docs/site binindex.html sourceindex.html Log: Updated ORO release links to version 2.0.8 and added KEYS file nad PGP signature links. Revision ChangesPath 1.330 +8 -8 jakarta-site2/xdocs/site/binindex.xml Index: binindex.xml === RCS file: /home/cvs/jakarta-site2/xdocs/site/binindex.xml,v retrieving revision 1.329 retrieving revision 1.330 diff -u -r1.329 -r1.330 --- binindex.xml 26 Dec 2003 18:24:57 - 1.329 +++ binindex.xml 29 Dec 2003 04:32:37 - 1.330 @@ -570,20 +570,20 @@ /p !-- oro -- -pORO emunsigned/em +pORO a href=http://www.apache.org/dist/jakarta/oro/KEYS;KEYS/a ul li -a href=[preferred]/jakarta/oro/binaries/jakarta-oro-2.0.7.zip2.0.7 zip/a -PGP -a href=http://www.apache.org/dist/jakarta/oro/binaries/jakarta-oro-2.0.7.zip.md5;MD5/a +a href=[preferred]/jakarta/oro/source/jakarta-oro-2.0.8.zip2.0.8 zip/a +a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.8.zip.sig;PGP/a +a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.8.zip.md5;MD5/a /li li -a href=[preferred]/jakarta/oro/binaries/jakarta-oro-2.0.7.tar.gz 2.0.7 tar.gz/a -PGP -a href=http://www.apache.org/dist/jakarta/oro/binaries/jakarta-oro-2.0.7.tar.gz.md5;MD5/a +a href=[preferred]/jakarta/oro/source/jakarta-oro-2.0.8.tar.gz2.0.8 tar.gz/a +a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.8.tar.gz.sig;PGP/a +a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.8.tar.gz.md5;MD5/a /li /ul -/p +/p !-- POI -- pPOI emunsigned/em 1.224 +7 -7 jakarta-site2/xdocs/site/sourceindex.xml Index: sourceindex.xml === RCS file: /home/cvs/jakarta-site2/xdocs/site/sourceindex.xml,v retrieving revision 1.223 retrieving revision 1.224 diff -u -r1.223 -r1.224 --- sourceindex.xml 14 Dec 2003 06:03:59 - 1.223 +++ sourceindex.xml 29 Dec 2003 04:32:37 - 1.224 @@ -542,17 +542,17 @@ /p !-- jakarta oro -- -pORO emunsigned, combined distribution only/em +pORO a href=http://www.apache.org/dist/jakarta/oro/KEYS;KEYS/a ul li -a href=[preferred]/jakarta/oro/source/jakarta-oro-2.0.7.zip2.0.7 zip/a -PGP -a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.7.zip.md5;MD5/a +a href=[preferred]/jakarta/oro/source/jakarta-oro-2.0.8.zip2.0.8 zip/a +a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.8.zip.sig;PGP/a +a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.8.zip.md5;MD5/a /li li -a href=[preferred]/jakarta/oro/source/jakarta-oro-2.0.7.tar.gz2.0.7 tar.gz/a -PGP -a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.7.tar.gz.md5;MD5/a +a href=[preferred]/jakarta/oro/source/jakarta-oro-2.0.8.tar.gz2.0.8 tar.gz/a +a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.8.tar.gz.sig;PGP/a +a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.8.tar.gz.md5;MD5/a /li /ul /p 1.389 +7 -7 jakarta-site2/docs/site/binindex.html Index: binindex.html === RCS file: /home/cvs/jakarta-site2/docs/site/binindex.html,v retrieving revision 1.388 retrieving revision 1.389 diff -u -r1.388 -r1.389 --- binindex.html 26 Dec 2003 18:24:57 - 1.388 +++ binindex.html 29 Dec 2003 04:32:37 - 1.389 @@ -681,17 +681,17 @@ /li /ul /p -pORO emunsigned/em +pORO a href=http://www.apache.org/dist/jakarta/oro/KEYS;KEYS/a ul li -a href=[preferred]/jakarta/oro/binaries/jakarta-oro-2.0.7.zip2.0.7 zip/a -PGP -a href=http://www.apache.org/dist/jakarta/oro/binaries/jakarta-oro-2.0.7.zip.md5;MD5/a +a href=[preferred]/jakarta/oro/source/jakarta-oro-2.0.8.zip2.0.8 zip/a +a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.8.zip.sig;PGP/a +a href=http://www.apache.org/dist/jakarta/oro/source/jakarta-oro-2.0.8.zip.md5;MD5/a /li li -a href=[preferred]/jakarta/oro/binaries/jakarta-oro-2.0.7.tar.gz 2.0.7 tar.gz/a
Re: [PROPOSAL] Proactively encourage TLP status
-1 My knee jerk reaction to Proactively encourage TLP status is the same as I had to one of my conservative friend who set out to convert a family of another religion to their true religion. That is repugnant to me, and so is Proactively encourage TLP status If you want to make the information available in a well documented fashion on how to go TLP then +1. For example I am happy where Struts is now, in Jakarta. If Martin Ted want to expend energy making it a TLP I won't -1 it but would -0 it if that was a voting option. For Jakarta Commons I would Strongly -1, to pull out major components like collections. The Jakarta Commons works. It is absolutely one of the most vibrant communities around. As one of the growing number of new PMC members, I want to focus on IP/Licensing matters. I understand that TLP changes what we take responsibility of for Jakarta PMC, but to me it is just one more distraction I don't need right now. I'll take each project that wants to go TLP case by case, its their right to do that, but hope that they think long and hard about it. -Rob Stephen Colebourne wrote: There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. Background info: http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges Stephen PROPOSAL The Jakarta PMC shall proactively encourage subprojects to reach Top Level Project (TLP) status. It shall do this by - drawing up a list of advantages that TLP status brings - explaining the effect of the ASF only recognizing Jakarta on a subproject's rights - documenting the process, by receiving advice from recent new TLPs - produce a draft template board resolution for creating a TLP - clearly identifying board meeting dates for TLP creation - proactively encouraging proposal then vote on developer lists - setting a timefame of 3 months for the votes In order to respect current reality, voters on each dev list shall be those of committer and PMC member status who have made recent contributions, with the exact list to be determined by the dev list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PROPOSAL] Proactively encourage TLP status
Geir Magnusson Jr. wrote: Noel J. Bergman wrote: We see a couple of things differently. For one, you don't seem to believe that a community can be built by multiple collaborating PMCs. I don't believe that the Apache vs Jakarta Commons analogy applies. AFAICS, Apache Commons was an idea created before it had a community. A project needs a community. I feel that Apache Commons could be another hub, for Commons projects. just glomming everyone [onto the PMC] wouldn't result in the best outcome as we want to make sure that people are explicitly signing up for project oversight, rather than being drafted to meet a quota. I agree, but getting the active committers onto the PMC isn't a matter of meeting a quota. The PMC is supposed to be made up of the people actively managing the project. That is its raison d'etre. Personally, I don't feel that a 400+ person PMC overseeing dozens of codebases represents a truely functional solution, but we can give it a go. I can't see why not. The point of oversight is to catch the cases where things aren't right (i.e. code comes into the CVS that shouldn't w/o incubation) rather than continuously report when things are going well. A PMC is not just about oversight. The PMC is supposed to provide the active managment of the project. Code review, voting in new Committers, voting in new PMC members, voting on releases, etc. I do not believe that Stephen Colebourne is unique in his outlook, nor incorrect in his approach. I think a lot of what you say presupposed some sort of onerous additional work that comes from being a part of the Jakarta PMC. What I say presupposes that having a PMC consisting of 400+ people, with a lot of different disjoint factions keeping up on any of dozens of projects is a PMC in name only, and that asking everyone to watch everything under such a PMC would be impractical. I would argue that it's no different - if you are providing oversight independently of Jakarta or part of Jakarta, it's the same amount of work. Not if people, like Stephen, decide that being responsible for active project management means having to at least follow every project. If you tell me that doing that won't scale, I will agree. That said, I'm willing to start with the mega-PMC. I just don't expect it to last. I expect projects to start asking for promotion to TLP status. The question is how much value you place on Jakarta as a community versus Jakarta as a website. What in particular makes Jakarta a community, as you see it? This is not an idle question. If you look at the question from the perspective of my expectations, and you accept that I really do want to help preserve the idea of a Jakarta community, then understanding how to structure a community that survives the creation of multiple new PMCs takes on some importance. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ontology-based portals - RDF, LDAP, Xindice (was: java@apache)
On Fri, 26 Dec 2003, Noel J. Bergman wrote: J.Pietschmann wrote: Noel J. Bergman wrote: This could be interesting, Henri. If we had an formal description of a project, providing its name, resource (www, scm, wiki, etc.) locations, ontological classifications, etc., I imagine that could be useful in producing a portal. Sounds awfully close to a Maven project.xml. As you note, sounds close to a lot of different things. There should not any dependence on Maven, although Maven could populate the system for projects that are using it. However, the key thing above, and seemingly missing from Maven's Project descriptor, is ontology, so I am curious to see Henri's approach. Okay, spent the holiday period playing with it a bit. I've not used XSL in 3 years, and my CSS is pretyt juvenile, so treat with the level of contempt it deserves: I've re-used the Maven project.xml's for Jakarta Commons, as it's a good database of information on a large group of Jakarta codebases. So at the bottom of the tree you have 'codebases', or more colloquially 'projects'. The next level up is a community. Noel uses the word ontology here, but even though I started using this, I don't understand what it is, so have gone with something simpler. Easy to s+r out. I've defined a community xml file: ?xml version=1.0? community namestruts-commons/name logoimages/struts.gif/logo membersmember-roles.xml/members urlhttp://jakarta.apache.org/struts//url descriptionComponents which came from Struts/description projects projectprojects/beanutils.xml/project projectprojects/convert.xml/project projectprojects/digester.xml/project projectprojects/fileupload.xml/project /projects /community Then above this, we have a portal made up of communities: ?xml version=1.0? portal namejakarta/name logoimages/jakarta-logo.gif/logo communities communitycommons.xml/community communitycommons-proper.xml/community communitycommons-sandbox.xml/community communitycommons-core.xml/community communitystruts.xml/community /communities /portal All the work is in the Style.java class which takes a portal.xml and applies an xsl [community.xsl] to each community in it. The filename portal.xml is hardcoded in community.xsl though, I need to solve that. http://www.apache.org/~bayard/pergamum/ is where I've pushed the bits up. http://www.apache.org/~bayard/pergamum/j-c/html-j-c-new/community_jakarta-commons.html is the 'tigris' lf, and: http://www.apache.org/~bayard/pergamum/j-c/html-j-c-old/community_jakarta-commons.html is the 'old' lf via a different css and image. Oh, and: http://www.apache.org/~bayard/pergamum/osjava/html-osjava/community_genjava.html is a non-apache portal. Just to keep it honest and non-apache-only. Anyway. Views, ideas, put-downs appreciated. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] Proactively encourage TLP status
Agreed on the -1 for the proposal's subject line, yet +1 to Stephen's suggestions of preparing Wiki resources for Jakarta sub-projects that want to move to TLP-ness. I do plan to proactively encourage TLP status for Commons, but as a Commons committer. As a Taglibs committer I'm happy where it is. Etc. Hen On Sun, 28 Dec 2003, Robert Leland wrote: -1 My knee jerk reaction to Proactively encourage TLP status is the same as I had to one of my conservative friend who set out to convert a family of another religion to their true religion. That is repugnant to me, and so is Proactively encourage TLP status If you want to make the information available in a well documented fashion on how to go TLP then +1. For example I am happy where Struts is now, in Jakarta. If Martin Ted want to expend energy making it a TLP I won't -1 it but would -0 it if that was a voting option. For Jakarta Commons I would Strongly -1, to pull out major components like collections. The Jakarta Commons works. It is absolutely one of the most vibrant communities around. As one of the growing number of new PMC members, I want to focus on IP/Licensing matters. I understand that TLP changes what we take responsibility of for Jakarta PMC, but to me it is just one more distraction I don't need right now. I'll take each project that wants to go TLP case by case, its their right to do that, but hope that they think long and hard about it. -Rob Stephen Colebourne wrote: There has been considerable emphasis on this list over recent weeks for the sticking plaster approach. That is to make small minor changes to Jakarta in the hope the board will stop hassling us. This could be because this is the consensus view and I'm an odd one out. Or it could be that those in favour of multiple TLPs just can't be bothered with the arguing. So I thought I'd place the alternative proposal on the table. If you like it, +1 it. Background info: http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges Stephen PROPOSAL The Jakarta PMC shall proactively encourage subprojects to reach Top Level Project (TLP) status. It shall do this by - drawing up a list of advantages that TLP status brings - explaining the effect of the ASF only recognizing Jakarta on a subproject's rights - documenting the process, by receiving advice from recent new TLPs - produce a draft template board resolution for creating a TLP - clearly identifying board meeting dates for TLP creation - proactively encouraging proposal then vote on developer lists - setting a timefame of 3 months for the votes In order to respect current reality, voters on each dev list shall be those of committer and PMC member status who have made recent contributions, with the exact list to be determined by the dev list. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
