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 16:05:11 -0500 Subject: Re: [PROPOSAL] Proactively encourage TLP status SNIP/ I never understand why you keep doing this. There is no 'schism' between the PMC and the community, and no one is proposing it. I hate to appeal to authority because the ASF charter does provide a healthy bit of freedom for any given PMC, but for example, if we want to follow the model of the httpd project, from which the ASF bylaws were fashioned, and I know you are a vocal proponent of the 'ASF Way', it is my understanding they invite committers onto the PMC after some time after receiving committership when it's clear that is appropriate for that person. Committing != oversight. There are people who are committers that may not wish to participate on the PMC. We want everyone to, but if they aren't *interested* in doing it, putting them on the PMC achieves nothing, and actually, IMO, weakens the PMC. There are all sorts of valid reasons to not want to be on the PMC, I suppose, and we should never stop inviting that person. 100% should be the goal, not the requirement. The schism is that the PMC did not elect our committers. In the normal course, the body that elects the committers also decides which committers (or other interested parties) merit inclusion in the PMC. However, Jakarta has not done things in the normal course. The PMC did not select most of the committers: the subproject communities did. And when our community selected the committers they expected that these individuals would be the ones actively managing the codebase. The community expected these individuals to have the rights and responsibilities we now abscribe only to the PMC. I believe from the ASF perspective committing==voting and committing==oversight Every time a committer commits, they vote for the code they commit. Most often, it a vote subject to lazy consensus, and in rare cases it might not be binding. But, it is vote nonetheless. Every time a committer commits, they either donate code to the ASF or facilitate a donation, and they incur the obligation to ensure, to the best of their ability, that this is IP that can be donated to the ASF. If we have a committer that does not accept these obligations, then a misunderstanding has occurred, and such committers should step down. The ASF does not grant write-access lightly. I think people understand that. In the normal course, virtually all ASF committers are PMC members, because its the committers make the decisions and do the work. It is true that on occasion an ASF committer will not yet be member of the project PMC. Their votes may not be binding, and their commits will be scrutinized by PMC members (which is to say other members of the development team). But, in due course, the PMC that made them a committer also makes them a member. When our community elected all of our committers, it was with the understanding that they were the ones with binding votes, that they were the decision makers, that the Jakarta Committers were, in practice, the Jakarta PMC. In my humble opinion, it is the duty of the PMC to now ratify the decisions our community has already made. Since we now know that the PMC is *not* a steering committee and is in fact the active managers of the codebase, we are obligated to finish the job our community started: give the committers the legal rights and responsibility that we always believed they already had. Make the committers the PMC, because they are the only true PMC that we have ever had. Each and every one of our committers have earned their stripe. They have all proven to the community that they are thoughtful, responsible self-starters capable of managing our codebase on the community's behalf. These are the individuals that have been creating, maintaining and releasing the products we all cherish. These are the individuals that have been doing the true work of the PMC. Where things have gone wrong, they have gone wrong because we were still using a bootstrap PMC that excluded all but a few of our decision makers. I'm sure that there are Jakarta committers that would be unwilling to serve on a bootstrap PMC, but serving on a true, inclusive PMC may be a different matter. Right now, the only plan seems to be to nominate committers one-by-one on the PMC list. I'm just saying that we shouldn't play favorites. I believe all Jakarta committers have already earned membership in the PMC; we should tender the offer to every Jakarta committer and let each decision-maker decide for himself or herself. If the consensus is that the bootstrap PMC will continue to hand-pick which of our duly-elected committers are promoted to the PMC, and which are not, then so be it. But, personally, I think that process is nothing but busy work. The community
Re: [PROPOSAL] Proactively encourage TLP status
On Tue, 30 Dec 2003, Ted Husted wrote: Right now, the only plan seems to be to nominate committers one-by-one on the PMC list. I'm just saying that we shouldn't play favorites. I believe all Jakarta committers have already earned membership in the PMC; we should tender the offer to every Jakarta committer and let each decision-maker decide for himself or herself. If the consensus is that the bootstrap PMC will continue to hand-pick which of our duly-elected committers are promoted to the PMC, and which are not, then so be it. But, personally, I think that process is nothing but busy work. The community has already decided. Let's ratify the community's decisions and let Jakarta be whatever Jakarta wants to be. [In case my actions suggest otherwise] I'm +0 to this, but do plan to keep pushing the one-by-one [or more likely, ten-by-ten as it's easier to handle] nominations through because it works. If the General list can agree to push all people up, I'll happily volunteer any time to be spent on that, but until such agreement occurs I want to at least make a little movement happen. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] ORO 2.0.8 maintenance release
Now I see it went just to general pmc, because I was following on the informative re-broadcast, so this is the reason why it has not been counted. No, I screwed up. I remember counting your vote and verifying bindingness against the committee file, but screwed up and didn't record it because I was interrupted by something else at the time. I think (I seem to recall it used to be done) that VOTEs should specify where they should happen. Yes, I should have done that. It was okay for the announcement to go to multiple lists, but I should have specified a list for the casting of votes. I'll restate the vote results for the record. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[CORRETION][RESULT][VOTE] ORO 2.0.8 maintenance release
The original vote tally for this vote was incorrectly listed as 4 +1 binding votes. There were in fact 5 +1 binding votes. The restated results follow: - The resolution to approve a 2.0.8 maintenance release of jakarta-oro has passed with 5 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: Santiago Gala sgala.hisitech.com 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] Proactively encourage TLP status
On Tue, 30 Dec 2003, Ted Husted wrote: - Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 16:05:11 -0500 Subject: Re: [PROPOSAL] Proactively encourage TLP status SNIP/ I never understand why you keep doing this. There is no 'schism' between the PMC and the community, and no one is proposing it. I hate to appeal to authority because the ASF charter does provide a healthy bit of freedom for any given PMC, but for example, if we want to follow the model of the httpd project, from which the ASF bylaws were fashioned, and I know you are a vocal proponent of the 'ASF Way', it is my understanding they invite committers onto the PMC after some time after receiving committership when it's clear that is appropriate for that person. Committing != oversight. There are people who are committers that may not wish to participate on the PMC. We want everyone to, but if they aren't *interested* in doing it, putting them on the PMC achieves nothing, and actually, IMO, weakens the PMC. There are all sorts of valid reasons to not want to be on the PMC, I suppose, and we should never stop inviting that person. 100% should be the goal, not the requirement. The schism is that the PMC did not elect our committers. In the normal course, the body that elects the committers also decides which committers (or other interested parties) merit inclusion in the PMC. However, Jakarta has not done things in the normal course. The PMC did not select most of the committers: the subproject communities did. And when our community selected the committers they expected that these individuals would be the ones actively managing the codebase. The community expected these individuals to have the rights and responsibilities we now abscribe only to the PMC. This doesn't seem quite right to me. I agree that when we have voted in a new committer, both the existing committers and the new committer have had the same expectations with respect to their rights and responsibilities *within the sub-project*. While those rights and responsibilities may be the same ones that apply to members of the PMC, the domain over which they apply is very different. I don't think it would be right to turn around now, and tell a committer on sub-project X oh, by the way, you're now part of the PMC and that means that you are (collectively) responsible for all of Jakarta. That doesn't meet the expectations *I* originally had at all, when I first became a Jakarta committer myself. Foisting additional responsibility on committers doesn't seem like the right way to go, to me. Allowing - even encouraging - them to take on the additional responibilities of a PMC member would fit much better with *my* original expectations, at least. -- Martin Cooper I believe from the ASF perspective committing==voting and committing==oversight Every time a committer commits, they vote for the code they commit. Most often, it a vote subject to lazy consensus, and in rare cases it might not be binding. But, it is vote nonetheless. Every time a committer commits, they either donate code to the ASF or facilitate a donation, and they incur the obligation to ensure, to the best of their ability, that this is IP that can be donated to the ASF. If we have a committer that does not accept these obligations, then a misunderstanding has occurred, and such committers should step down. The ASF does not grant write-access lightly. I think people understand that. In the normal course, virtually all ASF committers are PMC members, because its the committers make the decisions and do the work. It is true that on occasion an ASF committer will not yet be member of the project PMC. Their votes may not be binding, and their commits will be scrutinized by PMC members (which is to say other members of the development team). But, in due course, the PMC that made them a committer also makes them a member. When our community elected all of our committers, it was with the understanding that they were the ones with binding votes, that they were the decision makers, that the Jakarta Committers were, in practice, the Jakarta PMC. In my humble opinion, it is the duty of the PMC to now ratify the decisions our community has already made. Since we now know that the PMC is *not* a steering committee and is in fact the active managers of the codebase, we are obligated to finish the job our community started: give the committers the legal rights and responsibility that we always believed they already had. Make the committers the PMC, because they are the only true PMC that we have ever had. Each and every one of our committers have earned their stripe. They have all proven to the community that they are thoughtful, responsible self-starters capable of managing our codebase on the
Re: [PROPOSAL] Proactively encourage TLP status
Martin Cooper wrote: On Tue, 30 Dec 2003, Ted Husted wrote: - Original message From: Geir Magnusson Jr. [EMAIL PROTECTED] To: Jakarta General List [EMAIL PROTECTED] Received: Sun, 28 Dec 2003 16:05:11 -0500 Subject: Re: [PROPOSAL] Proactively encourage TLP status SNIP/ I never understand why you keep doing this. There is no 'schism' between the PMC and the community, and no one is proposing it. I hate to appeal to authority because the ASF charter does provide a healthy bit of freedom for any given PMC, but for example, if we want to follow the model of the httpd project, from which the ASF bylaws were fashioned, and I know you are a vocal proponent of the 'ASF Way', it is my understanding they invite committers onto the PMC after some time after receiving committership when it's clear that is appropriate for that person. Committing != oversight. There are people who are committers that may not wish to participate on the PMC. We want everyone to, but if they aren't *interested* in doing it, putting them on the PMC achieves nothing, and actually, IMO, weakens the PMC. There are all sorts of valid reasons to not want to be on the PMC, I suppose, and we should never stop inviting that person. 100% should be the goal, not the requirement. The schism is that the PMC did not elect our committers. In the normal course, the body that elects the committers also decides which committers (or other interested parties) merit inclusion in the PMC. However, Jakarta has not done things in the normal course. The PMC did not select most of the committers: the subproject communities did. And when our community selected the committers they expected that these individuals would be the ones actively managing the codebase. The community expected these individuals to have the rights and responsibilities we now abscribe only to the PMC. This doesn't seem quite right to me. I agree that when we have voted in a new committer, both the existing committers and the new committer have had the same expectations with respect to their rights and responsibilities *within the sub-project*. While those rights and responsibilities may be the same ones that apply to members of the PMC, the domain over which they apply is very different. I don't think it would be right to turn around now, and tell a committer on sub-project X oh, by the way, you're now part of the PMC and that means that you are (collectively) responsible for all of Jakarta. That doesn't meet the expectations *I* originally had at all, when I first became a Jakarta committer myself. Yes, but I thought I had a say, by way of binding votes, in the project I was elected in, and was responsible for the future of the project and now that doesn't seem true either. I haven't been around for too long but this whole thing seems like a problem of misunderstanding of rights and responsibilities. Not that I have a good understanding :) It seems that oversight is the only extra responsibility of a PMC member, and it seems oversight is about making sure that contributed code conforms to IP rights. If so, may be somebody has to explain why the CLA is not good enough to ensure the acceptance of this responsibility. I think Ted's proposal is not forcing all committers to become PMC members but rather extending the membership to every one of them and gives them an option to opt out. I don't think there should be any criteria, other than the willingness of the committer, to become a PMC member. This proposal fulfills that and makes the process faster, I think. -Harish PS. I think my thoughts follow the right[eous] path ;) Foisting additional responsibility on committers doesn't seem like the right way to go, to me. Allowing - even encouraging - them to take on the additional responibilities of a PMC member would fit much better with *my* original expectations, at least. -- Martin Cooper I believe from the ASF perspective committing==voting and committing==oversight Every time a committer commits, they vote for the code they commit. Most often, it a vote subject to lazy consensus, and in rare cases it might not be binding. But, it is vote nonetheless. Every time a committer commits, they either donate code to the ASF or facilitate a donation, and they incur the obligation to ensure, to the best of their ability, that this is IP that can be donated to the ASF. If we have a committer that does not accept these obligations, then a misunderstanding has occurred, and such committers should step down. The ASF does not grant write-access lightly. I think people understand that. In the normal course, virtually all ASF committers are PMC members, because its the committers make the decisions and do the work. It is true that on occasion an ASF committer will not yet be member of the project PMC. Their votes may not be binding, and their commits will be scrutinized by PMC members (which is to say other members of the
