Re: Close to completion? (acl policy questions)

[David Blevins <da...@visi.com>]

If you vote for this, no complaining later -- you eat your own dog food.


     ----------------------------------------------------------
     NOTE: I apologize in advance for using the words
     "incubation", "incubating", "incubated", and finally
     "incubator".  The word "sandbox" is not a verb and really
     hard to use as one, nor could I think of another verb.
     Sorry, sorry, sorry.  Please, please, please try and focus
     on the content in the questions.
     ----------------------------------------------------------


Do ACLs extend to things like:
 - websites
 - documentation (possibly donated as well)
 - QA
 - project management


What is the policy on how this affects voting?
 - Can a restricted committer -1 a change made by a non-restricted committer
 - Does a restricted committer get a binding vote on the code to which they have access?
 - Does a restricted committer have a binding vote to code to which they do not have access?
 - Does a restricted committer have a binding vote on non-technical issues?


New committers:
 - Does an existing ASF committer contributing to the incubating code get restricted commit?
 - Does an existing ASF committer contributing to the incubating code and some to other code get full commit?
 - Does an employee of the donor contributing to the incubating code get restricted commit?
 - Does an employee of the donor contributing to the incubating code and some to other code get full commit?
 - Does an unknown community member contributing to the incubating code get restricted commit?
 - Does an unknown community member contributing to the incubating code and some to other code get full commit?
 - Will there be an advantage to *not* contributing to the incubating code as to avoid getting voted in as a restricted committer.


Releasing:
 - Can code being Geronimo incubated be distributed in our unstable builds?
 - Can code being Geronimo incubated be distributed in official releases?
 - Can code being Geronimo incubated be certified and distributed in a certified release?


Management and dynamics:
 - Can we handle having 2 or 3 more donations in addition to the two we plan?
 - Is is possible that the number of active restricted committers outnumbers the active fully privileged committers?
 - How much time are you willing to dedicate in a week to managing issues, documenting guidelines and general Apache Way mentoring?
 - Will we be open to assistance from experienced ASF people willing to assist in managing issues, documenting guidelines and general Apache Way mentoring?
 - Would they get a binding vote?
 - Would they get and be welcome to use commit privileges?


PMC:
 - Can a restricted committer join the Geronimo PMC?
 - Can a person under a documentation ACL join the PMC?
 - Can a person under a management ACL join the PMC?


Moving Up:
 - What is the criteria for leaving the Geronimo incubator?
 - Is it acceptable to take half or less of the code?
 - How is this consensus reached, public vote or private vote?
 - How do restricted committers become full committers?
 - If a donation moves to full status, are the restrictions of all committers working on that code removed?
 - Are these people free to vote on matters of other donated code?


Moving Out:
 - Is it possible to remove a project from incubation and not accept it as a part of Geronimo?
 - How long will donors have to wait to get this answer?
 - On what basis will the PMC vote on removing a project? 
 - Is that a public or private vote?
 - Is it possible to remove all commit access for a restricted committer.
 - On what basis will the PMC vote on removing all commit access? 
 - Is that a public or private vote?


Potential fairness issues:
 - Donor X gets in the incubator in March, donor Y gets in the incubator two months later.  Sometime later, the PMC votes to graduate donor Y's code.  Do we graduate X as well?  If not, do we owe X and explanation of why they aren't being graduated?
 - Adam and Jack are restricted committers from donor ABC.  Jack is voted in as a full committer.  Do we vote in Adam as well?  If not, do we owe Adam an explanation of why?
 - Bill and Ben are restricted committers from donor QRS.  Bill and Ben are having a hard time getting really involved.  Eric is an Apache committer from another project who started working with the donated code and was made a restricted committer.  The PMC decides to vote Eric in as a full Geronimo committer.  Do we make Bill and Ben full committers as well?  If no, how do we handle Bill and Ben's expectations?

Re: Close to completion? (acl policy questions)

["Geir Magnusson Jr." <ge...@apache.org>]

I'll be a good little fishy, as I think this is important.  I'm  
keeping the following in mind from a recent post by David Jencks as I  
go through the list :

"I'd like to reemphasize that bringing in new committers with their  
code is going to be a lot of work for the existing community.  If we  
fail to integrate a donation a very large part of the responsibility  
rests with us for not having good enough community skills to work  
with the newcomers.  It seems to me that discussions about limited  
commit access/ acls/ etc are fundamentally discussions about what  
happens if we fail.  I wonder what would happen if we instead  
discussed how we will provide superb support and mentoring for our  
new members and left the questions of what to do if we fail to such  
time as it might be needed."


On Jul 13, 2005, at 2:37 PM, David Blevins wrote:

> If you vote for this, no complaining later -- you eat your own dog  
> food.

If you vote for anything, and we don't like it, we change it.  We  
aren't bending re-bar and pouring cement...

>
>
>      ----------------------------------------------------------
>      NOTE: I apologize in advance for using the words
>      "incubation", "incubating", "incubated", and finally
>      "incubator".

Why didn't you just avoid using it then?  We're not creating an  
incubator.  We're trying to bring in code, add committers and build  
*our* community.

[SNIP]

>
> Do ACLs extend to things like:
>  - websites
>  - documentation (possibly donated as well)
>  - QA
>  - project management
>

If we want them to, and I think we want them to.  The goal here is  
Geronimo project participation, not "off in the corner" participation.

>
> What is the policy on how this affects voting?
>  - Can a restricted committer -1 a change made by a non-restricted  
> committer

In the code they are working on?  Yes because the "non-restricted  
committer" will have karma to the "restricted" svn repo.

>  - Does a restricted committer get a binding vote on the code to  
> which they have access?

yes

>  - Does a restricted committer have a binding vote to code to which  
> they do not have access?

No

>  - Does a restricted committer have a binding vote on non-technical  
> issues?

That's an interesting question to think about, and I think my answer  
is yes, again because it's about growing project participation.

To explain, I want to object to the lingo of "restricted committer"  
vs "non-restricted committer".  I think of as "committer to Geronimo  
main SVN" vs "committer to Geronimo $foo SVN"

So yes.  And I think that for code being brought into Geronimo  
project (even in a $foo SVN) would mean that all committers to  
Geronimo main SVN have commit to $foo SVN so that

a) we have PMC oversight
b) we have full interaction and participation

>
>

For the following, I'll assume "incubating" means "code in Geronimo  
$foo repository" where $foo != main

> New committers:
>  - Does an existing ASF committer contributing to the incubating  
> code get restricted commit?

Like someone from httpd?  No.

>  - Does an existing ASF committer contributing to the incubating  
> code and some to other code get full commit?

No - I assume you mean some arbitrary committer from Jakarta or -ish?

>  - Does an employee of the donor contributing to the incubating  
> code get restricted commit?

Any arbitrary employee?  of course not.  I would assume we'd craft  
some guideline asking the donor to list the humans that worked on the  
code and wish to continue.

Note that "donor" isn't necessarily an entity with employees - for  
example, if hypothetically something like MX4J decided to come to  
Geronimo...

>  - Does an employee of the donor contributing to the incubating  
> code and some to other code get full commit?

do you mean "if a person that is working on the code in the Geronimo  
$foo repository starts contributing to the Geronimo main repository,  
do we offer them commit"?  yes, at some point, which I assume is  
going to be *way* accelerated because they've been working right in  
the community all long on stuff that's part of the community.

>  - Does an unknown community member contributing to the incubating  
> code get restricted commit?
>  - Does an unknown community member contributing to the incubating  
> code and some to other code get full commit?

If someone starts posting patches to the Geronimo $foo repo, and we  
feel that they meet our criterion for offered commit access,yes, lets  
offer them commit access to the Geronimo $foo repository.

>  - Will there be an advantage to *not* contributing to the  
> incubating code as to avoid getting voted in as a restricted  
> committer.

I don't get it.

When I think of "restricted ACL" I think of simply setting up another  
repository with a different group of committers, that includes all  
the committers from the main [current] repository, along with the  
people that want to keep working on their donation with us.

If a "restricted ACL" repo is a place where someone wants to  
contribute, lets let them earn commit status there if they didn't  
come with the code...

>
>
> Releasing:
>  - Can code being Geronimo incubated be distributed in our unstable  
> builds?
>  - Can code being Geronimo incubated be distributed in official  
> releases?
>  - Can code being Geronimo incubated be certified and distributed  
> in a certified release?

Being there is no incubation, I'd say "yes" to all of these questions  
- at all times the main repository committers are committers on the  
$foo respoitory, the PMC has full responsibility and oversight, etc.

If there is no one but the donor committers working on the codebase  
here, it shouldn't be here.  Either this is stuff we work on with  
them, or they can be elswhere.  We're not an incubator.

>
>
> Management and dynamics:
>  - Can we handle having 2 or 3 more donations in addition to the  
> two we plan?

It certainly will be easier with more people.  it's up to us to gauge  
who and what we bring in.  You have a good point here - we must  
always consider the load on the existing committers for anything like  
this that we do.  Making commitments means making commitments - doing  
it elsewhere just leaves less time for here.

>  - Is is possible that the number of active restricted committers  
> outnumbers the active fully privileged committers?

Anything is possible, and I think that would mean we weren't paying  
attention to what you pointed out above.  If we do this, it's our error.

And I think that it's not the end of the world if it happens, as if G  
is the set of all committers in the main geronimo repo and C is the  
new people that want to come and work on console then
C' is the set of commiters in the console repo

   C' = G + C

assume the same for Trifork (see, got the case of the "F" right...  
sorry about my previous errors...)

   T' = G + T


>  - How much time are you willing to dedicate in a week to managing  
> issues, documenting guidelines and general Apache Way mentoring?

meaning, working with others in the community?  I seem to put in a  
bit of time now.  I know if I didn't have to spend the time on this  
subject, I'd have oodles of free hours :)

>  - Will we be open to assistance from experienced ASF people  
> willing to assist in managing issues, documenting guidelines and  
> general Apache Way mentoring?

We always are.  But we're not doing an incubator.

>  - Would they get a binding vote?

No.

>  - Would they get and be welcome to use commit privileges?

Interesting question :)  In some places at the ASF, being an existing  
ASF committer is a huge step towards commit if you are known, but  
lets not go there in this thread.

>
>
> PMC:
>  - Can a restricted committer join the Geronimo PMC?

I'd like to avoid this.  If a person has been around such that we  
believe they deserve to be on the PMC, we trust them with commit to  
main repo, and if peeps like that have been around, we should be just  
integrating the pile of people into the main tree anyway?


>  - Can a person under a documentation ACL join the PMC?
>  - Can a person under a management ACL join the PMC?

I don't know what a "management ACL" is, but for the same reasons as  
above...

The model I'm worried about is the Jakarta model, which was having  
committers from the various subprojects (a reasonable analogy -  
different CVS roots with separate ACLs for each root) be on the PMC  
in a limited way.  That gave PMC oversight officially, as if there  
were 3 committers from Jakarta Wombat that voted +1 on a release,  
because they were on the PMC, that provided the necessary minimum  
legal requirement.

We *may* be able to do this if we start from scratch with the goal  
that *every* committer should be on the PMC, and that the "restricted  
ACL" is just an internal management feature of code access.

I could easily talk myself into this, but we'd have to be very clear  
from the get-go that we will work to have everyone on the PMC (which  
is our goal now, btw) and people should have the good manners and  
common sense to abstain from voting on things they aren't a part of.

>
>
> Moving Up:
>  - What is the criteria for leaving the Geronimo incubator?

There is no Geronimo incubator.

I see it as the question of "when can and how do we combine these  
repos"?

>  - Is it acceptable to take half or less of the code?

Sure

>  - How is this consensus reached, public vote or private vote?

public

>  - How do restricted committers become full committers?

"How does someone w/o commit access to the main Geronimo repository  
get commit access?"  ?  I don't see us having special rules - if we  
believe the person does good work, is committed, etc, then we vote  
that person in as committer.

Our guidelines for committer access apply to any repo.  There are no  
special "Geronimo incubator" rules.


>  - If a donation moves to full status, are the restrictions of all  
> committers working on that code removed?

Again, in my mental model, it's not about restriction but commit in  
other parts of our multi-repo SVN.

>  - Are these people free to vote on matters of other donated code?

I don't grok

>
>
> Moving Out:
>  - Is it possible to remove a project from incubation and not  
> accept it as a part of Geronimo?

There is no Geronimo incubation.

But yes, we've had sandbox code that we never used, and just threw it  
out.  Not a new issue.

>  - How long will donors have to wait to get this answer?

Huh?

>  - On what basis will the PMC vote on removing a project?

I assume that there's all sorts of factors that will come up.
>
>  - Is that a public or private vote?

if it's technology, public.  if there's people issues involved, private.

>  - Is it possible to remove all commit access for a restricted  
> committer.

of course.  it's possible to remove all commit access for any committer

>  - On what basis will the PMC vote on removing all commit access?

For the same reasons that I would now - gross breach of trust,  
prolonged inactivity, etc

>  - Is that a public or private vote?

Private.  It's a person.

>
>
> Potential fairness issues:
>  - Donor X gets in the incubator in March, donor Y gets in the  
> incubator two months later.  Sometime later, the PMC votes to  
> graduate donor Y's code.  Do we graduate X as well?  If not, do we  
> owe X and explanation of why they aren't being graduated?

Oh, I see.  Because there is no Geronimo incubator...  Let me rephrase :

Donor X gets a contribution accepted into repoX in March and begins  
working.  Donor Y gets a contribution accepted into repoY and begins  
working.  At some point, the community votes to combine the code from  
repoY into repoMain.  X and repoX keep doing their thing.  They are  
all independent.

Because there is no Geronimo incubator, there is nothing to  
"graduate" from.  If it makes technological or other sense to move  
things around, we do it.


>  - Adam and Jack are restricted committers from donor ABC.  Jack is  
> voted in as a full committer.  Do we vote in Adam as well?  If not,  
> do we owe Adam an explanation of why?

I assume that Jack was contributing to mainRepo and it was time to  
give him access?  Or do you mean that repoABC is combined with  
repoMain?  In the latter case, I think that not taking all the people  
would be an extreme corner case and would have to deal with  
individually.

(Note - there's a similar problem if we went and sponsored something  
in the Apache Incubator to incorporate into Geronimo - at that point,  
each committer would have to earn commit status independently, so you  
could have the situation where we fractured that community ... :/  )


>  - Bill and Ben are restricted committers from donor QRS.  Bill and  
> Ben are having a hard time getting really involved.  Eric is an  
> Apache committer from another project who started working with the  
> donated code and was made a restricted committer.  The PMC decides  
> to vote Eric in as a full Geronimo committer.  Do we make Bill and  
> Ben full committers as well?  If no, how do we handle Bill and  
> Ben's expectations?

Be honest and up front with them?  I think that this is a corner  
case, and self-solving.  If they aren't involved, why would they care?

Whew!  Happy to get through that before my meeting starts.

Just to recap the model I'm thinking of is a set of additional repos  
besides the "main" Geronimo repo that has the committer set denoted  
as G.  Each non-main repo has a committer set that is G + additions  
that either came with a donation (if that's how it started) or people  
that wanted to participate in that part of our world and earned commit.

There is no "graduation" - there is combining technology when and if  
it makes sense, and granting further commit when and if it makes  
sense for a person.

The key is that all would be part of the same community, working  
together.  I expect that if we did something like this, a trusted  
person X with commit rights to repoX that wanted to work on repoY  
would be subject to a quick vote and given access.

My only concern is how to really ensure that we have no balkanization  
of the community.  I think we saw it happen in Jakarta as it really  
grew, and the things to avoid are partitioned dev lists, for one, and  
not working as hard as possible to get all committers on the PMC from  
day 0.  (I'm not criticizing Jakarta - I think it has been  
phenomenally successful in many ways, and we just need to learn from  
their groundbreaking efforts.)

Thanks for the thought-provoking questions.

geir

-- 
Geir Magnusson Jr                                  +1-203-665-6437
geirm@apache.org