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]
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] 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] 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
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] 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] As it ever were (draft 2)
[PROPOSAL] As it ever were I've incorporated many of the suggestions made on the list and prepared another draft for community review. -ISSUE- The ASF Board has indicated that it does not believe that the Jakarta PMC, in its present form, is capable of providing oversight of all the subprojects under its purview. The role of the Jakarta PMC is two-fold: * The PMC is responsible the active management of the project * The PMC provides oversight for the project -Management- When the board creates a project, it passes a resolution. Resolutions regarding Jakarta have been passed here: http://tinyurl.com/3x6rs and here http://tinyurl.com/2zkdb The board's authority to create Projects and PMCs stems from section 6.3 of the ASF bylaws: http://apache.org/foundation/bylaws.html From a legal perspective, the PMC is the only entity that the board recognizes as being responsible for the management of a project. Only committee members have binding votes. Only committee members would be indemnified by the ASF in the event of a law suit http://tinyurl.com/3eq9c. In fact, most of the rights and responsibilities we at Jakarta have ascribed to committers in fact belong only to PMC members. Originally, we envisioned the PMC to be a steering committee http://tinyurl.com/2o2v5, responsible for the strategic direction and success of the Jakarta Project. But this is *not* the case. The PMC doesn't just set the agenda, it is the body that *actively manages* the project. The PMC has the rights and responsibilities that most of us would ascribe to the subproject committers. -Oversight- As used here, the term oversight follows its dictionary definition: o·ver·sight 1. An unintentional omission or mistake. 2. Watchful care or management; supervision http://tinyurl.com/2eyvg The board expects PMCs to exercise (2) so as to avoid (1). :) All good managers must provide oversight, and a PMC is no exception. For a PMC, oversight boils down to issues of committer consensus and intellectual property. In the past, there have been incidents at Jakarta on both counts that lead to suspension of access, for both individuals and modules (on different occasions). Jakarta now manages 21 subprojects (with Pluto on the way), and another 40+ components in the Commons and Commons Sandbox, The board's question is How can the Jakarta PMC, as it is now constituted, possibly provide oversight for all of this code?. -CURRENT APPROACH- The PMC has decided to expand its membership to an indefinite number and is actively soliciting nominations of qualified committers. So far, the PMC has rejected the idea of nominating all the committers or any committers who volunteers. Each new nominee must be voted in by the PMC (or not). At this time, no other changes are on the agenda. For additional background, see * http://tinyurl.com/226pt * http://tinyurl.com/2vclu and the archives for the general list * http://tinyurl.com/2gq7d or http://tinyurl.com/3cw3e. -PROPOSED CHANGES- (1) Require all Jakarta products (or subprojects) to file regular reports with the PMC (2) Promote all Jakarta Committers to the Jakarta PMC, nunc pro tunc -PROPOSITION (1)- * Require all Jakarta products (or subprojects) to file regular reports with the PMC. A key element of oversight is vigilance. One way to achieve vigilance is regular reporting. Just as the board requires the vice president of a project to file regular reports, the PMC should require each subproject to file a similar report. Here is a format often used by projects reporting to the board: * What code releases have been made? * Legal issues: * Cross-project issues: * Any problems with committers, members, etc? * Plans and expectations for the next period? 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.) Failure to report would have to be considered a serious matter, possibly leading to blocking CVS access. Accordingly, each subproject would want to be very, very sure these reports are in fact being filed. -PROPOSITION (2)- * Promote all Jakarta Committers to the Jakarta PMC, nunc pro tunc The original Jakarta guidelines state that committers have the binding votes and make the decisions regarding the codebase. We now know that, from an ASF perspective, committers have write-access to the codebase, but the PMC members have binding votes and make the decisions. The idea of committers with non-binding votes has been broached many times over the years. Each time, the consensus has been that we vote most with our commits, and that every volunteer committing to a Jakarta codebase is entitled to a binding vote (and veto). Whenever we selected any committer for any Jakarta codebase, we did so with the expectation that they would be responsible for its active management. We were in fact not merely electing committers but PMC
