Re: [proposal] Emeritus committers & removing inter-project commit restrictions
+1 Rahul Carlos Sanchez wrote: On 1/8/07, Brett Porter <[EMAIL PROTECTED]> wrote: On 27/12/2006, at 8:50 AM, Brett Porter wrote: > 1) Establish a list of emeritus committers. ok, this has been taken care of. I've added myself a todo to document what we have in place. > 2) Remove inter-project commit restrictions > > The first does not depend on the second. But I think the second > does depend on the first. I would like to put each to a separate > vote once all the pros and cons have been gathered from this > discussion. I'd expect each vote to operate as requiring 2/3rds of > the PMC to vote (12), with a majority of +1's within those votes > for it to pass. Other votes would be welcome with reasons as > advisory, but not binding. This is still pending. We've had some discussions on both sides, with the general trend towards being in favour - but haven't heard from a large number of people. Does anyone have anything else to add? I'm +1 I don't think anybody will touch something before talking to other people Are there any objections to calling a vote and abiding by the result given the process above? (though it's now 13 votes required after the addition of John, and I also intended to keep it open 72 hours regardless so that folks have an opportunity to change their vote). > > * Removing restrictions > > The list of groups we have can be seen here: http:// > people.apache.org/~jim/projects.html. There are a lot. (the page is > currently down, unfortunately) > > Currently, only PMC members can commit to anything. > > Rather than using this technological boundary, which can be a > hindrance, I'd rather use a social boundary. That is, if you don't > quite know what you are doing but would like to try something new, > or want to make a big change in something you don't regularly > commit to - ask first. Perhaps create a branch and have the regular > committers review it first. > > I look forward to hearing your comments. - 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] Emeritus committers & removing inter-project commit restrictions
On 1/8/07, Brett Porter <[EMAIL PROTECTED]> wrote: On 27/12/2006, at 8:50 AM, Brett Porter wrote: > 1) Establish a list of emeritus committers. ok, this has been taken care of. I've added myself a todo to document what we have in place. > 2) Remove inter-project commit restrictions > > The first does not depend on the second. But I think the second > does depend on the first. I would like to put each to a separate > vote once all the pros and cons have been gathered from this > discussion. I'd expect each vote to operate as requiring 2/3rds of > the PMC to vote (12), with a majority of +1's within those votes > for it to pass. Other votes would be welcome with reasons as > advisory, but not binding. This is still pending. We've had some discussions on both sides, with the general trend towards being in favour - but haven't heard from a large number of people. Does anyone have anything else to add? I'm +1 I don't think anybody will touch something before talking to other people Are there any objections to calling a vote and abiding by the result given the process above? (though it's now 13 votes required after the addition of John, and I also intended to keep it open 72 hours regardless so that folks have an opportunity to change their vote). > > * Removing restrictions > > The list of groups we have can be seen here: http:// > people.apache.org/~jim/projects.html. There are a lot. (the page is > currently down, unfortunately) > > Currently, only PMC members can commit to anything. > > Rather than using this technological boundary, which can be a > hindrance, I'd rather use a social boundary. That is, if you don't > quite know what you are doing but would like to try something new, > or want to make a big change in something you don't regularly > commit to - ask first. Perhaps create a branch and have the regular > committers review it first. > > I look forward to hearing your comments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
On 27/12/2006, at 8:50 AM, Brett Porter wrote: 1) Establish a list of emeritus committers. ok, this has been taken care of. I've added myself a todo to document what we have in place. 2) Remove inter-project commit restrictions The first does not depend on the second. But I think the second does depend on the first. I would like to put each to a separate vote once all the pros and cons have been gathered from this discussion. I'd expect each vote to operate as requiring 2/3rds of the PMC to vote (12), with a majority of +1's within those votes for it to pass. Other votes would be welcome with reasons as advisory, but not binding. This is still pending. We've had some discussions on both sides, with the general trend towards being in favour - but haven't heard from a large number of people. Does anyone have anything else to add? Are there any objections to calling a vote and abiding by the result given the process above? (though it's now 13 votes required after the addition of John, and I also intended to keep it open 72 hours regardless so that folks have an opportunity to change their vote). * Removing restrictions The list of groups we have can be seen here: http:// people.apache.org/~jim/projects.html. There are a lot. (the page is currently down, unfortunately) Currently, only PMC members can commit to anything. Rather than using this technological boundary, which can be a hindrance, I'd rather use a social boundary. That is, if you don't quite know what you are doing but would like to try something new, or want to make a big change in something you don't regularly commit to - ask first. Perhaps create a branch and have the regular committers review it first. I look forward to hearing your comments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
Brett Porter wrote: Sorry, just catching up on a couple of these now. Myself and Brett can flip SVN bits and generally one of us is around. And if you're a committer you've already got access to sandboxes. I'm not really talking about the relative difficulty of granting access. Yes, that's quick. Though a vote is first required. And at what point do you ask for commit? Or do you wait for someone to nominate you? Does everyone know the current permissions structure enough to be able to do that effectively? Or are they just going to assume someone is already a committer and not think about it? That someone could check in some code and deploy a snapshot without talking to anyone, which is a possibility with the free-for-all scenario, is not something I want to go have to fix. Anyone here can deploy a snapshot now, without checking it in or talking to anyone. So we have a disparity of permissions there (though that obviously can be fixed, too). We've had no cross-plugin barriers though some people obviously know more about some than others. How many times have we had a problem there? By the way, if such a thing occurred and was innocent, it's fixable - and it's just as likely to innocently happen by someone who does have permission. Sometimes people already working on the same thing disagree. And if it's malicious, then the fix is fairly easy too. Doesn't take long to remove all karma. I agree, someone who is voted in as a committer is done so for a reason. They have proved that they can produce good code and/or documentation and that they understand and sympathize with open source. I think the risk that someone does something "bad" is minimal. There, in reality, are several little teams or networks. Many people are part of many of them but there are still boundaries to these networks and things like public acceptance by everyone on these little teams is actually the more socially acceptable path IMO. A simple vote is not onerous. You're right - and I trust people to be socially responsible. I have full karma, but I still come and ask before doing something on a new area that I'm not all that familiar with (like the recent stuff with the plugin parent POM). I expect everyone to behave the same way. I don't really expect to vote in a committer at all that won't play by those rules. And really, who is actually going to get turned down by such a vote? If it's just meant to be a social pat of the back, let's just do that. "Hey, I'm going to fix a bunch of bugs in the webdav wagon. I know I haven't done anything on there before, but I need this to deploy". "Nice work, go for it!". And if it happens to just be fixing a typo on the web site, then they can go for it and save everyone else the inconvenience. +1 It's so much easier to review a patch and say "OK, go ahead" than it is to apply it yourself. This might sound lazy, but we're volunteering our free time here, so we tend to prioritize our own itches before others'. To apply the patch you'd need to: - check out the source, or update your already checked out working copy, unless you have made local changes to it, in which case you need a fresh checkout - apply the patch to your working copy - build, install, test - commit - resolve issue in JIRA - publish a snapshot - publish the site And it's not really a matter of not trusting people. People can be careless, or think what they doing is ok when they haven't looked at any existing plans, or they may just be socially awkward (which is definitely not impossible with a bunch of predominantly male programmers who sit in front of computers all day). I think the best way to bring someone into the group is with a visible show of acceptance from the group. And we've already done that to bring them into the project in the first place (and all those problems are equally applicable to the existing committers). I don't think building up walls inside the project is healthy. The current situation leads to discouraging situations more than encouraging situations. Part of the problem is that the real social boundaries don't map easily to the technological ones. For example, I think nobody would have an objection to Wendy editing documentation for the plugins. But the commit rights say she only has permission on the main site. If she decided to rewrite the clover plugin, I think Vincent would want to hear about it first :) So should we give her permission to all the various bits of documentation scattered throughout the trees, and the parent pom, but not other parts of the code? That'd be a mess in the configuration. So, we can either give her full access (and trust her to consult Vincent before rewriting his plugin), or as now require she submit patches to documentation. That has lead to the following situation (by my count): 5 unapplied patches from Wendy. 4 from Brian fox (and one that could have been taken care of quite quickly b
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
Brett Porter wrote: Sorry, just catching up on a couple of these now. Myself and Brett can flip SVN bits and generally one of us is around. And if you're a committer you've already got access to sandboxes. I'm not really talking about the relative difficulty of granting access. Yes, that's quick. Though a vote is first required. And at what point do you ask for commit? Or do you wait for someone to nominate you? Does everyone know the current permissions structure enough to be able to do that effectively? Or are they just going to assume someone is already a committer and not think about it? That someone could check in some code and deploy a snapshot without talking to anyone, which is a possibility with the free-for-all scenario, is not something I want to go have to fix. Anyone here can deploy a snapshot now, without checking it in or talking to anyone. So we have a disparity of permissions there (though that obviously can be fixed, too). We've had no cross-plugin barriers though some people obviously know more about some than others. How many times have we had a problem there? By the way, if such a thing occurred and was innocent, it's fixable - and it's just as likely to innocently happen by someone who does have permission. Sometimes people already working on the same thing disagree. And if it's malicious, then the fix is fairly easy too. Doesn't take long to remove all karma. There, in reality, are several little teams or networks. Many people are part of many of them but there are still boundaries to these networks and things like public acceptance by everyone on these little teams is actually the more socially acceptable path IMO. A simple vote is not onerous. You're right - and I trust people to be socially responsible. I have full karma, but I still come and ask before doing something on a new area that I'm not all that familiar with (like the recent stuff with the plugin parent POM). I expect everyone to behave the same way. I don't really expect to vote in a committer at all that won't play by those rules. And really, who is actually going to get turned down by such a vote? If it's just meant to be a social pat of the back, let's just do that. "Hey, I'm going to fix a bunch of bugs in the webdav wagon. I know I haven't done anything on there before, but I need this to deploy". "Nice work, go for it!". And if it happens to just be fixing a typo on the web site, then they can go for it and save everyone else the inconvenience. And it's not really a matter of not trusting people. People can be careless, or think what they doing is ok when they haven't looked at any existing plans, or they may just be socially awkward (which is definitely not impossible with a bunch of predominantly male programmers who sit in front of computers all day). I think the best way to bring someone into the group is with a visible show of acceptance from the group. And we've already done that to bring them into the project in the first place (and all those problems are equally applicable to the existing committers). I don't think building up walls inside the project is healthy. The current situation leads to discouraging situations more than encouraging situations. Part of the problem is that the real social boundaries don't map easily to the technological ones. For example, I think nobody would have an objection to Wendy editing documentation for the plugins. But the commit rights say she only has permission on the main site. If she decided to rewrite the clover plugin, I think Vincent would want to hear about it first :) So should we give her permission to all the various bits of documentation scattered throughout the trees, and the parent pom, but not other parts of the code? That'd be a mess in the configuration. So, we can either give her full access (and trust her to consult Vincent before rewriting his plugin), or as now require she submit patches to documentation. That has lead to the following situation (by my count): 5 unapplied patches from Wendy. 4 from Brian fox (and one that could have been taken care of quite quickly by him, but went unnoticed and was filed 3 times, wasting a bunch of time to sort out). 5 from Dennis (who has commit access, but is adhering to the social rule of not being familiar with it yet). 9 from Edwin, 2 from Andy, 1 from Milos. There are more, and there have been plenty in the past. More than 25 fixes going to waste - about 10% of all the patches we have. Basically, I think this stops things getting done, with no discernible advantage. If they're not sure, they're going to ask or keep submitting patches instead. If they're not sure and not going to do that, they don't belong here in the first place. Anyway, I'm calling the emeritus vote now, but would like to hear more on this. I think I agree with you now, Brett. We've given them karma once, why should we have to ask the same questions
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
Heh :) On 04/01/2007, at 5:36 PM, Dion Gillard wrote: That list is woefully out of date. This one is way more telling: http://maven.apache.org/maven-1.x/developer-activity-report.html On 12/29/06, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > > > I'm just curious, what problem does establishing a list of emeritus > committers solve? When you see this page [1], how many committers are there for maven 1 ? Who is active ? Arnaud [1] http://maven.apache.org/maven-1.x/team-list.html -- http://www.multitask.com.au/people/dion/ Rule of Acquisition #91: Hear all, trust nothing. - 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] Emeritus committers & removing inter-project commit restrictions
That list is woefully out of date. This one is way more telling: http://maven.apache.org/maven-1.x/developer-activity-report.html On 12/29/06, Arnaud HERITIER <[EMAIL PROTECTED]> wrote: > > > I'm just curious, what problem does establishing a list of emeritus > committers solve? When you see this page [1], how many committers are there for maven 1 ? Who is active ? Arnaud [1] http://maven.apache.org/maven-1.x/team-list.html -- http://www.multitask.com.au/people/dion/ Rule of Acquisition #91: Hear all, trust nothing. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
Sorry, just catching up on a couple of these now. Myself and Brett can flip SVN bits and generally one of us is around. And if you're a committer you've already got access to sandboxes. I'm not really talking about the relative difficulty of granting access. Yes, that's quick. Though a vote is first required. And at what point do you ask for commit? Or do you wait for someone to nominate you? Does everyone know the current permissions structure enough to be able to do that effectively? Or are they just going to assume someone is already a committer and not think about it? That someone could check in some code and deploy a snapshot without talking to anyone, which is a possibility with the free-for-all scenario, is not something I want to go have to fix. Anyone here can deploy a snapshot now, without checking it in or talking to anyone. So we have a disparity of permissions there (though that obviously can be fixed, too). We've had no cross-plugin barriers though some people obviously know more about some than others. How many times have we had a problem there? By the way, if such a thing occurred and was innocent, it's fixable - and it's just as likely to innocently happen by someone who does have permission. Sometimes people already working on the same thing disagree. And if it's malicious, then the fix is fairly easy too. Doesn't take long to remove all karma. There, in reality, are several little teams or networks. Many people are part of many of them but there are still boundaries to these networks and things like public acceptance by everyone on these little teams is actually the more socially acceptable path IMO. A simple vote is not onerous. You're right - and I trust people to be socially responsible. I have full karma, but I still come and ask before doing something on a new area that I'm not all that familiar with (like the recent stuff with the plugin parent POM). I expect everyone to behave the same way. I don't really expect to vote in a committer at all that won't play by those rules. And really, who is actually going to get turned down by such a vote? If it's just meant to be a social pat of the back, let's just do that. "Hey, I'm going to fix a bunch of bugs in the webdav wagon. I know I haven't done anything on there before, but I need this to deploy". "Nice work, go for it!". And if it happens to just be fixing a typo on the web site, then they can go for it and save everyone else the inconvenience. And it's not really a matter of not trusting people. People can be careless, or think what they doing is ok when they haven't looked at any existing plans, or they may just be socially awkward (which is definitely not impossible with a bunch of predominantly male programmers who sit in front of computers all day). I think the best way to bring someone into the group is with a visible show of acceptance from the group. And we've already done that to bring them into the project in the first place (and all those problems are equally applicable to the existing committers). I don't think building up walls inside the project is healthy. The current situation leads to discouraging situations more than encouraging situations. Part of the problem is that the real social boundaries don't map easily to the technological ones. For example, I think nobody would have an objection to Wendy editing documentation for the plugins. But the commit rights say she only has permission on the main site. If she decided to rewrite the clover plugin, I think Vincent would want to hear about it first :) So should we give her permission to all the various bits of documentation scattered throughout the trees, and the parent pom, but not other parts of the code? That'd be a mess in the configuration. So, we can either give her full access (and trust her to consult Vincent before rewriting his plugin), or as now require she submit patches to documentation. That has lead to the following situation (by my count): 5 unapplied patches from Wendy. 4 from Brian fox (and one that could have been taken care of quite quickly by him, but went unnoticed and was filed 3 times, wasting a bunch of time to sort out). 5 from Dennis (who has commit access, but is adhering to the social rule of not being familiar with it yet). 9 from Edwin, 2 from Andy, 1 from Milos. There are more, and there have been plenty in the past. More than 25 fixes going to waste - about 10% of all the patches we have. Basically, I think this stops things getting done, with no discernible advantage. If they're not sure, they're going to ask or keep submitting patches instead. If they're not sure and not going to do that, they don't belong here in the first place. Anyway, I'm calling the emeritus vote now, but would like to hear more on this. Cheers, Brett ---
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
Jason van Zyl wrote: People get voted on to the PMC by other PMC members. Being a committer doesn't automatically get you on the PMC in these parts. I'm personally not for the free-for-all access to everything. I don't honestly understand why there is any distinction between a committer and PMC member in Cocoon if it's always the same thing. Committers are people who code and contribute, while PMC members are helping to direct the project. Some Cocoon committers choose not to join the PMC. I'm not really sure why. And I don't really understand your distinction as it implies that some PMC members don't code or contribute but yet help direct the project. I'm not sure why someone who codes and contributes can't help direct the project (in fact, they do since every source code change they commit changes the project). Generally, the PMC only offers commit privileges to people who actively participate on the mailing lists by helping others and who have either submitted patches (and thus can document their knowledge in how Cocoon works) or by working on the documentation. Some people have been on the Cocoon mailing lists for years and haven't been offered commit privileges while others have it offered after several months. In general though, by the time they are offered commit privileges the PMC has a pretty good idea of their desire to participate in the community and their ability to do so, so at that point we feel being a PMC member is appropriate. BTW, I'm not trying to say one way of doing things is better than the other. Obviously, both communities seem to be pretty healthy. I'm simply trying to understand what criteria you use when you offer PMC membership. Ralph - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
On 28 Dec 06, at 9:50 PM 28 Dec 06, Ralph Goers wrote: I'm a little curious. I'm a committer on a few projects and am on the Cocoon PMC. This is the first time I've every heard of a proposal for people to automatically lose their commit privileges. Although, I haven't found any rules anywhere that says you can't do it, it seems a bit odd to me. I know Jetspeed does it. I started Velocity and noticed I can't commit to it anymore. I don't where it started. It's easy to get your access back if you ask. No biggie. Second, I didn't find anything that discusses just how Maven distinguishes between committers and PMC members. I know it is up to each community to decide. I'm just used to all committers also being able to be on the PMC if they want to. So how does it work here? People get voted on to the PMC by other PMC members. Being a committer doesn't automatically get you on the PMC in these parts. I'm personally not for the free-for-all access to everything. I don't honestly understand why there is any distinction between a committer and PMC member in Cocoon if it's always the same thing. Committers are people who code and contribute, while PMC members are helping to direct the project. Jason. Ralph Alan D. Cabrera wrote: On Dec 26, 2006, at 1:50 PM, Brett Porter wrote: Hi, I'd like to propose two things: 1) Establish a list of emeritus committers. 2) Remove inter-project commit restrictions The first does not depend on the second. But I think the second does depend on the first. I would like to put each to a separate vote once all the pros and cons have been gathered from this discussion. I'd expect each vote to operate as requiring 2/3rds of the PMC to vote (12), with a majority of +1's within those votes for it to pass. Other votes would be welcome with reasons as advisory, but not binding. * Emeritus committers Someone can request to be made emeritus at any time they want (usually because they have moved on to other things, or just don't have the time). They will be listed as past members of the team, but have no karma. An emeritus committer can request commit access again at any time they feel they can be active, and a vote will be held to accept them or not. To start with, anyone who hasn't committed in 12 months will be made automatically emeritus. PMC members will not be made emeritus (unless they chose to stand down from the PMC). I'm just curious, what problem does establishing a list of emeritus committers solve? Regards, Alan - 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]
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
On 29/12/2006, at 1:50 PM, Ralph Goers wrote: I'm a little curious. I'm a committer on a few projects and am on the Cocoon PMC. This is the first time I've every heard of a proposal for people to automatically lose their commit privileges. Although, I haven't found any rules anywhere that says you can't do it, it seems a bit odd to me. This is just one clean up because we have a large number of people that haven't committed in 3+ years due to the changes in technology, the move to TLP, etc. Such things have before been discussed in Jakarta, another project with large numbers of committers that have moved on. Second, I didn't find anything that discusses just how Maven distinguishes between committers and PMC members. I know it is up to each community to decide. I'm just used to all committers also being able to be on the PMC if they want to. So how does it work here? I think you'll find it's not a matter of "committers being on the PMC if they want to". No project to my knowledge (Cocoon included), operates that way. However, many have set the committer bar higher, to the level of the PMC membership, so both are voted on at the same time (eg, Forrest, and perhaps that's how Cocoon operates). It's one of those discussions that happens at the ASF from time to time and nobody ever agrees on which way it should be. As we stand, we have a lower bar for committership, but a higher bar for PMC membership. One thing to note is that the emeritus policy will bring our number of PMC members and committers much closer together, which is desirable too. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
I'm a little curious. I'm a committer on a few projects and am on the Cocoon PMC. This is the first time I've every heard of a proposal for people to automatically lose their commit privileges. Although, I haven't found any rules anywhere that says you can't do it, it seems a bit odd to me. Second, I didn't find anything that discusses just how Maven distinguishes between committers and PMC members. I know it is up to each community to decide. I'm just used to all committers also being able to be on the PMC if they want to. So how does it work here? Ralph Alan D. Cabrera wrote: On Dec 26, 2006, at 1:50 PM, Brett Porter wrote: Hi, I'd like to propose two things: 1) Establish a list of emeritus committers. 2) Remove inter-project commit restrictions The first does not depend on the second. But I think the second does depend on the first. I would like to put each to a separate vote once all the pros and cons have been gathered from this discussion. I'd expect each vote to operate as requiring 2/3rds of the PMC to vote (12), with a majority of +1's within those votes for it to pass. Other votes would be welcome with reasons as advisory, but not binding. * Emeritus committers Someone can request to be made emeritus at any time they want (usually because they have moved on to other things, or just don't have the time). They will be listed as past members of the team, but have no karma. An emeritus committer can request commit access again at any time they feel they can be active, and a vote will be held to accept them or not. To start with, anyone who hasn't committed in 12 months will be made automatically emeritus. PMC members will not be made emeritus (unless they chose to stand down from the PMC). I'm just curious, what problem does establishing a list of emeritus committers solve? Regards, Alan - 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] Emeritus committers & removing inter-project commit restrictions
I'm just curious, what problem does establishing a list of emeritus committers solve? When you see this page [1], how many committers are there for maven 1 ? Who is active ? Arnaud [1] http://maven.apache.org/maven-1.x/team-list.html
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
On Dec 26, 2006, at 1:50 PM, Brett Porter wrote: Hi, I'd like to propose two things: 1) Establish a list of emeritus committers. 2) Remove inter-project commit restrictions The first does not depend on the second. But I think the second does depend on the first. I would like to put each to a separate vote once all the pros and cons have been gathered from this discussion. I'd expect each vote to operate as requiring 2/3rds of the PMC to vote (12), with a majority of +1's within those votes for it to pass. Other votes would be welcome with reasons as advisory, but not binding. * Emeritus committers Someone can request to be made emeritus at any time they want (usually because they have moved on to other things, or just don't have the time). They will be listed as past members of the team, but have no karma. An emeritus committer can request commit access again at any time they feel they can be active, and a vote will be held to accept them or not. To start with, anyone who hasn't committed in 12 months will be made automatically emeritus. PMC members will not be made emeritus (unless they chose to stand down from the PMC). I'm just curious, what problem does establishing a list of emeritus committers solve? Regards, Alan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
On 28 Dec 06, at 8:35 AM 28 Dec 06, Trygve Laugstøl wrote: Brett Porter wrote: Hi, I'd like to propose two things: 1) Establish a list of emeritus committers. 2) Remove inter-project commit restrictions The first does not depend on the second. But I think the second does depend on the first. I would like to put each to a separate vote once all the pros and cons have been gathered from this discussion. I'd expect each vote to operate as requiring 2/3rds of the PMC to vote (12), with a majority of +1's within those votes for it to pass. Other votes would be welcome with reasons as advisory, but not binding. * Emeritus committers Someone can request to be made emeritus at any time they want (usually because they have moved on to other things, or just don't have the time). They will be listed as past members of the team, but have no karma. An emeritus committer can request commit access again at any time they feel they can be active, and a vote will be held to accept them or not. To start with, anyone who hasn't committed in 12 months will be made automatically emeritus. PMC members will not be made emeritus (unless they chose to stand down from the PMC). +1. * Removing restrictions The list of groups we have can be seen here: http:// people.apache.org/~jim/projects.html. There are a lot. (the page is currently down, unfortunately) Currently, only PMC members can commit to anything. Rather than using this technological boundary, which can be a hindrance, I'd rather use a social boundary. That is, if you don't quite know what you are doing but would like to try something new, or want to make a big change in something you don't regularly commit to - ask first. Perhaps create a branch and have the regular committers review it first. -0, I like the fact that people are forced to ask before doing stuff, but OTOH it's a bit annoying having to wait a couple of days if you have a couple of quick fixes for a product that you can fix *now*. Myself and Brett can flip SVN bits and generally one of us is around. And if you're a committer you've already got access to sandboxes. That someone could check in some code and deploy a snapshot without talking to anyone, which is a possibility with the free-for-all scenario, is not something I want to go have to fix. There, in reality, are several little teams or networks. Many people are part of many of them but there are still boundaries to these networks and things like public acceptance by everyone on these little teams is actually the more socially acceptable path IMO. A simple vote is not onerous. And it's not really a matter of not trusting people. People can be careless, or think what they doing is ok when they haven't looked at any existing plans, or they may just be socially awkward (which is definitely not impossible with a bunch of predominantly male programmers who sit in front of computers all day). I think the best way to bring someone into the group is with a visible show of acceptance from the group. Jason. -- Trygve - 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] Emeritus committers & removing inter-project commit restrictions
Brett Porter wrote: Hi, I'd like to propose two things: 1) Establish a list of emeritus committers. 2) Remove inter-project commit restrictions The first does not depend on the second. But I think the second does depend on the first. I would like to put each to a separate vote once all the pros and cons have been gathered from this discussion. I'd expect each vote to operate as requiring 2/3rds of the PMC to vote (12), with a majority of +1's within those votes for it to pass. Other votes would be welcome with reasons as advisory, but not binding. * Emeritus committers Someone can request to be made emeritus at any time they want (usually because they have moved on to other things, or just don't have the time). They will be listed as past members of the team, but have no karma. An emeritus committer can request commit access again at any time they feel they can be active, and a vote will be held to accept them or not. To start with, anyone who hasn't committed in 12 months will be made automatically emeritus. PMC members will not be made emeritus (unless they chose to stand down from the PMC). +1. * Removing restrictions The list of groups we have can be seen here: http://people.apache.org/~jim/projects.html. There are a lot. (the page is currently down, unfortunately) Currently, only PMC members can commit to anything. Rather than using this technological boundary, which can be a hindrance, I'd rather use a social boundary. That is, if you don't quite know what you are doing but would like to try something new, or want to make a big change in something you don't regularly commit to - ask first. Perhaps create a branch and have the regular committers review it first. -0, I like the fact that people are forced to ask before doing stuff, but OTOH it's a bit annoying having to wait a couple of days if you have a couple of quick fixes for a product that you can fix *now*. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] Emeritus committers & removing inter-project commit restrictions
On 26 Dec 06, at 4:50 PM 26 Dec 06, Brett Porter wrote: Hi, I'd like to propose two things: 1) Establish a list of emeritus committers. 2) Remove inter-project commit restrictions The first does not depend on the second. But I think the second does depend on the first. I would like to put each to a separate vote once all the pros and cons have been gathered from this discussion. I'd expect each vote to operate as requiring 2/3rds of the PMC to vote (12), with a majority of +1's within those votes for it to pass. Other votes would be welcome with reasons as advisory, but not binding. * Emeritus committers Someone can request to be made emeritus at any time they want (usually because they have moved on to other things, or just don't have the time). They will be listed as past members of the team, but have no karma. An emeritus committer can request commit access again at any time they feel they can be active, and a vote will be held to accept them or not. To start with, anyone who hasn't committed in 12 months will be made automatically emeritus. PMC members will not be made emeritus (unless they chose to stand down from the PMC). Sounds fine. Isn't it 6 months in other projects? * Removing restrictions The list of groups we have can be seen here: http:// people.apache.org/~jim/projects.html. There are a lot. (the page is currently down, unfortunately) Currently, only PMC members can commit to anything. Rather than using this technological boundary, which can be a hindrance, I'd rather use a social boundary. That is, if you don't quite know what you are doing but would like to try something new, or want to make a big change in something you don't regularly commit to - ask first. Perhaps create a branch and have the regular committers review it first. If they can work in a branch and have it reviewed then it doesn't take much to turn the karma on. I frankly don't like the idea of people having carte blanche access. It takes five seconds to flip the bit and it makes sure people ask if they are not so inclined. I would rather everyone else who is responsible for a code base see who's requesting karma with a vote. It's not that difficult a procedure. I think this should apply to everyone and not just PMC members. I think this is just a courtesy to people who have worked on the code and it's not a high barrier. It just means you must interact with someone before twiddling a new code base. Jason. I look forward to hearing your comments. Cheers, Brett - 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]
