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]
