Donations & Policies

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Donations & Policies

ammulder
        Okay, it seems I was was under the mistaken impression that
everyone on the CORBA call wanted the TriFork code to come to a Geronimo
"sandbox area", whereas in fact some people want it to go to the
incubator.  I think that's totally acceptable, and I'm sorry I didn't walk
away from the call with a clear picture of what people want.

        After giving the whole issue some more thought, I think I would
prefer the TriFork code go to the incubator.  I'm fine going either way
with the web console (incubator or "sandbox area" with own ACL).  I guess
that means that if we need a single policy/guideline, I'd lean toward the
incubator.

        Part of the thinking that went into this was I considered the
possible donation of an EJB container, web container, JMS broker, etc.  
All of those are pieces of every J2EE servers, and we've seen at least one
J2EE vendor willing to make donations.  I don't really think it would be
appropriate to bring one of those components I just listed directly into a
Geronimo sandbox.  We are already using high-quality open source projects
in each of those areas, and they're good at what they do, and I don't want
to insult them or ourselves be on the hook to support and maintain those
features.

        There are other smaller components we might accept into Geronimo
without conflicting, but I don't think we should base our
policy/guidelines on those.

Thanks,
        Aaron
Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Geir Magnusson Jr.

On Jul 11, 2005, at 10:13 PM, Aaron Mulder wrote:

>     Okay, it seems I was was under the mistaken impression that
> everyone on the CORBA call wanted the TriFork code to come to a  
> Geronimo
> "sandbox area", whereas in fact some people want it to go to the
> incubator.  I think that's totally acceptable, and I'm sorry I  
> didn't walk
> away from the call with a clear picture of what people want.

Yes, I had the same mis-impression given that everyone said "yes"  
when we clarified it :)

It would good to see a show of hands of who actually wanted what,  
including the TriFork contributors.

I'll start - I was under the impression that the TriFork CORBA  
donation would come to the Geronimo project directly and we'd put the  
code out of the main tree and invite the TriFork people to work on it  
there with us, integrating it tightly at first into Geronimo, leaving  
the door open to making a standalone server or TLP later.


>
>     After giving the whole issue some more thought, I think I would
> prefer the TriFork code go to the incubator.  I'm fine going either  
> way
> with the web console (incubator or "sandbox area" with own ACL).  I  
> guess
> that means that if we need a single policy/guideline, I'd lean  
> toward the
> incubator.
>
>     Part of the thinking that went into this was I considered the
> possible donation of an EJB container, web container, JMS broker, etc.
> All of those are pieces of every J2EE servers, and we've seen at  
> least one
> J2EE vendor willing to make donations.  I don't really think it  
> would be
> appropriate to bring one of those components I just listed directly  
> into a
> Geronimo sandbox.  We are already using high-quality open source  
> projects
> in each of those areas, and they're good at what they do, and I  
> don't want
> to insult them or ourselves be on the hook to support and maintain  
> those
> features.
>
>     There are other smaller components we might accept into Geronimo
> without conflicting, but I don't think we should base our
> policy/guidelines on those.

I think we should have a general policy no matter what the code is.  
If a contributor bring something like a EJB container, we can always  
choose to simply vote no - that we don't want it in Geronimo for  
whatever reason, be it not wanting to insult another project, or not  
wanting to be on the hook for support...

But please,  lets create a clear policy independent of who the donor  
is or what they are donating, and do it now.

geir

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Alan Cabrera-2
Geir Magnusson Jr. wrote, On 7/11/2005 7:23 PM:

>
> On Jul 11, 2005, at 10:13 PM, Aaron Mulder wrote:
>
>>     Okay, it seems I was was under the mistaken impression that
>> everyone on the CORBA call wanted the TriFork code to come to a  
>> Geronimo
>> "sandbox area", whereas in fact some people want it to go to the
>> incubator.  I think that's totally acceptable, and I'm sorry I  
>> didn't walk
>> away from the call with a clear picture of what people want.
>
>
> Yes, I had the same mis-impression given that everyone said "yes"  
> when we clarified it :)
>
> It would good to see a show of hands of who actually wanted what,  
> including the TriFork contributors.
>
> I'll start - I was under the impression that the TriFork CORBA  
> donation would come to the Geronimo project directly and we'd put the  
> code out of the main tree and invite the TriFork people to work on it  
> there with us, integrating it tightly at first into Geronimo, leaving  
> the door open to making a standalone server or TLP later.


This was my understanding as well.  Who is proposing that this is not
what we had originally proposed?  Please, please, please, don't make me
read that tennis match of a thread.

>>     After giving the whole issue some more thought, I think I would
>> prefer the TriFork code go to the incubator.  I'm fine going either  way
>> with the web console (incubator or "sandbox area" with own ACL).  I  
>> guess
>> that means that if we need a single policy/guideline, I'd lean  
>> toward the
>> incubator.
>
I don't see the value add in going directly to the incubator unless they
wanted to graduate as a TLP out of the gate.  If this is the case, then
they wouldn't have bothered us to begin w/.

> I think we should have a general policy no matter what the code is.  
> If a contributor bring something like a EJB container, we can always  
> choose to simply vote no - that we don't want it in Geronimo for  
> whatever reason, be it not wanting to insult another project, or not  
> wanting to be on the hook for support...
>
> But please,  lets create a clear policy independent of who the donor  
> is or what they are donating, and do it now.


I think that we should have a single simple process.

All vendors must propose the code donation to the community.  
Embarrassing denials can be averted by creating a gmail account and
asking if people are interested in technology X going into Geronimo.

All code donations go into

/geronimo/incubator/donationx/*

The contributors would get restricted committer access to their project;
granting committer access gives us better visibility how well the person
works in a community setting.  They and, hopefully Geronimo committers,
would whip it into shape.  The community would provide guidance and,
hopefully, vote it into Geronimo once its ready and all the appropriate
paper work was obtained.

The "probationary" committers would, hopefully, get voted into Geronimo,
regardless of their projects status.  I have never heard of a motivated
developer not getting committer access.

If the contribution was wildly popular it would graduate, as would any
Geronimo module, to be a sub-project where it would have its own release
cycles.  If it became obscenely popular, it would become a TLP.


Regards,
Alan



Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Geir Magnusson Jr.

On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:

[SNIP]

>
>
>>>     After giving the whole issue some more thought, I think I would
>>> prefer the TriFork code go to the incubator.  I'm fine going  
>>> either  way
>>> with the web console (incubator or "sandbox area" with own ACL).  
>>> I  guess
>>> that means that if we need a single policy/guideline, I'd lean  
>>> toward the
>>> incubator.
>>>
>>
>>
> I don't see the value add in going directly to the incubator unless  
> they wanted to graduate as a TLP out of the gate.  If this is the  
> case, then they wouldn't have bothered us to begin w/.
>

Just a comment -

yes - that's something we need to get a handle on - what's the value  
to send off to Incubator unless it will be some kind of TLP or a  
distinct, standalone community of some sort.

I don't wish to see our subprojects, if we add them, be formally  
distinct sub-communities of Geronimo.

geir

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Rick McGuire
Geir Magnusson Jr. wrote:

>
> On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:
>
> [SNIP]
>
>>
>>
>>>>     After giving the whole issue some more thought, I think I would
>>>> prefer the TriFork code go to the incubator.  I'm fine going  
>>>> either  way
>>>> with the web console (incubator or "sandbox area" with own ACL).  
>>>> I  guess
>>>> that means that if we need a single policy/guideline, I'd lean  
>>>> toward the
>>>> incubator.
>>>>
>>>
>>>
>> I don't see the value add in going directly to the incubator unless  
>> they wanted to graduate as a TLP out of the gate.  If this is the  
>> case, then they wouldn't have bothered us to begin w/.
>>
>
> Just a comment -
>
> yes - that's something we need to get a handle on - what's the value  
> to send off to Incubator unless it will be some kind of TLP or a  
> distinct, standalone community of some sort.


Has the Harmony project addressed the ORB issue yet?  That's certainly a
project that will need to come to grips with this issue at some point.  
If they have a common interest, that's would certainly be a point in
favor of the incubator.  Otherwise, it might make more sense for it to
be part of Geronimo so it can be the "best Geronimo ORB" possible.

>
> I don't wish to see our subprojects, if we add them, be formally  
> distinct sub-communities of Geronimo.
>
> geir
>

Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Geir Magnusson Jr.

On Jul 12, 2005, at 11:23 AM, Rick McGuire wrote:

> Geir Magnusson Jr. wrote:
>
>
>>
>> On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:
>>
>> [SNIP]
>>
>>
>>>
>>>
>>>
>>>>>     After giving the whole issue some more thought, I think I  
>>>>> would
>>>>> prefer the TriFork code go to the incubator.  I'm fine going  
>>>>> either  way
>>>>> with the web console (incubator or "sandbox area" with own  
>>>>> ACL).   I  guess
>>>>> that means that if we need a single policy/guideline, I'd  
>>>>> lean   toward the
>>>>> incubator.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> I don't see the value add in going directly to the incubator  
>>> unless  they wanted to graduate as a TLP out of the gate.  If  
>>> this is the  case, then they wouldn't have bothered us to begin w/.
>>>
>>>
>>
>> Just a comment -
>>
>> yes - that's something we need to get a handle on - what's the  
>> value  to send off to Incubator unless it will be some kind of TLP  
>> or a  distinct, standalone community of some sort.
>>
>
>
> Has the Harmony project addressed the ORB issue yet?

No :)

> That's certainly a project that will need to come to grips with  
> this issue at some point.  If they have a common interest, that's  
> would certainly be a point in favor of the incubator.  Otherwise,  
> it might make more sense for it to be part of Geronimo so it can be  
> the "best Geronimo ORB" possible.

Right - clearly Harmony will need to have this in some way, but it's  
not clear when and how, other than, like Geronimo, it won't need a  
stand-alone server either.  So I'm not sure this needs to be part of  
the calculation now.  We can always change and adapt in the future.

geir

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Geir Magnusson Jr.
In reply to this post by Alan Cabrera-2

On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:

>
> I think that we should have a single simple process.
> All vendors must propose the code donation to the community.  
> Embarrassing denials can be averted by creating a gmail account and  
> asking if people are interested in technology X going into Geronimo.

s/vendors/contributors/

Also, anyone can approach the PMC privately on  
[hidden email] if they wish to discuss a contribution before-
hand.  I see nothing wrong with that, and yes, if satisfied, we then  
ask the contributor to propose directly to the community on dev@

>
> All code donations go into
>
> /geronimo/incubator/donationx/*
>
> The contributors would get restricted committer access to their  
> project; granting committer access gives us better visibility how  
> well the person works in a community setting.  They and, hopefully  
> Geronimo committers, would whip it into shape.  The community would  
> provide guidance and, hopefully, vote it into Geronimo once its  
> ready and all the appropriate paper work was obtained.
> The "probationary" committers would, hopefully, get voted into  
> Geronimo, regardless of their projects status.  I have never heard  
> of a motivated developer not getting committer access.
>

I'd like to propose a slight modification.  That we give them  
committer access w/o a formal, restricted ACL, but a clear  
understanding that there's a place where they are bring brought in to  
work, and if they wish to participate elsewhere, they do so via  
standard engagement of working with others, learning about the area,  
proposing changes on dev@ etc, until they and others are comfortable,  
etc.

Any change can be vetoed, and any change can be rolled back.  I think  
we should assume a level of trust, and if broken, commit priv can be  
revoked.

Just consider for a little while.  I believe that this won't be a  
popular suggestion, but the risk is small, and the upside great, it  
keeps things simple, and I believe leads to a more unified, richer  
community. :)

geir

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

DWoods2
Comments in-line below.

-Donald

--- "Geir Magnusson Jr." <[hidden email]> wrote:

>
> On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:
>
> >
> > I think that we should have a single simple
> process.
> > All vendors must propose the code donation to the
> community.  
> > Embarrassing denials can be averted by creating a
> gmail account and  
> > asking if people are interested in technology X
> going into Geronimo.
>
> s/vendors/contributors/
>
> Also, anyone can approach the PMC privately on  
> [hidden email] if they wish to discuss a
> contribution before-
> hand.  I see nothing wrong with that, and yes, if
> satisfied, we then  
> ask the contributor to propose directly to the
> community on dev@

+1 to allowing pre-screening by the PMC first and then
a public review period.

>
> >
> > All code donations go into
> >
> > /geronimo/incubator/donationx/*
> >
> > The contributors would get restricted committer
> access to their  
> > project; granting committer access gives us better
> visibility how  
> > well the person works in a community setting.
> They and, hopefully  
> > Geronimo committers, would whip it into shape.
> The community would  
> > provide guidance and, hopefully, vote it into
> Geronimo once its  
> > ready and all the appropriate paper work was
> obtained.
> > The "probationary" committers would, hopefully,
> get voted into  
> > Geronimo, regardless of their projects status.  I
> have never heard  
> > of a motivated developer not getting committer
> access.
> >
>
> I'd like to propose a slight modification.  That we
> give them  
> committer access w/o a formal, restricted ACL, but a
> clear  
> understanding that there's a place where they are
> bring brought in to  
> work, and if they wish to participate elsewhere,
> they do so via  
> standard engagement of working with others, learning
> about the area,  
> proposing changes on dev@ etc, until they and others
> are comfortable,  
> etc.
>
> Any change can be vetoed, and any change can be
> rolled back.  I think  
> we should assume a level of trust, and if broken,
> commit priv can be  
> revoked.
>

+1 to automatic committer access to their incubator
project, since they will probably have the most domain
knowledge on the contributed code.

As far as committer access to all of Geronimo, I
believe it should follow the current practice today of
waiting to see if the person is going to be a real
contributor and then using the @dev feedback and
voting for giving them committer access.

> Just consider for a little while.  I believe that
> this won't be a  
> popular suggestion, but the risk is small, and the
> upside great, it  
> keeps things simple, and I believe leads to a more
> unified, richer  
> community. :)
>
> geir
>
> --
> Geir Magnusson Jr                                
> +1-203-665-6437
> [hidden email]
>
>
>

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

David Jencks
In order to avoid mile-long emails I'm starting over.

I think our overall goal is to strengthen the geronimo community by
bringing in new developers and code that we as well as they want to
work on.

This process is likely to be more work for us than the new developers,
since they  already know their code very well, whereas we need to learn
their code and more importantly mentor them into being part of the
geronimo community.  Therefore, we need to put together a process that
involves the least work for us, and we need to commit the time needed
to be good mentors.  To me, this means that the new people need to be
given commit access to at least their donated code, since we simply
won't have time to review all the patches that are likely to result
otherwise, and the svn structure needs to be set up for minimal
nuisance/simplest builds.  I think the last would be best with the new
code going somewhere in the geronimo/trunk tree: although svn tricks
are certainly possible to pull it in from elsewhere in apache svn, this
would add some complexity for no gain I can see.

I also think it is important to publish a process for donations, so we
don't spend weeks discussing this every time someone offers something,
and so potential donors know what to expect and dont get the idea that
we are playing favorites.  If we run into problems, we can certainly
update the process.

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.

thanks
david jencks

Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Davanum Srinivas
+1  ("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.")

-- dims

On 7/12/05, David Jencks <[hidden email]> wrote:

> In order to avoid mile-long emails I'm starting over.
>
> I think our overall goal is to strengthen the geronimo community by
> bringing in new developers and code that we as well as they want to
> work on.
>
> This process is likely to be more work for us than the new developers,
> since they  already know their code very well, whereas we need to learn
> their code and more importantly mentor them into being part of the
> geronimo community.  Therefore, we need to put together a process that
> involves the least work for us, and we need to commit the time needed
> to be good mentors.  To me, this means that the new people need to be
> given commit access to at least their donated code, since we simply
> won't have time to review all the patches that are likely to result
> otherwise, and the svn structure needs to be set up for minimal
> nuisance/simplest builds.  I think the last would be best with the new
> code going somewhere in the geronimo/trunk tree: although svn tricks
> are certainly possible to pull it in from elsewhere in apache svn, this
> would add some complexity for no gain I can see.
>
> I also think it is important to publish a process for donations, so we
> don't spend weeks discussing this every time someone offers something,
> and so potential donors know what to expect and dont get the idea that
> we are playing favorites.  If we run into problems, we can certainly
> update the process.
>
> 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.
>
> thanks
> david jencks
>
>


--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

David Blevins
In reply to this post by David Jencks
("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.")

+1  Building relationships, mentoring, thousand points of light.


Respectfully,
David


On Tue, Jul 12, 2005 at 10:32:48AM -0700, David Jencks wrote:

> In order to avoid mile-long emails I'm starting over.
>
> I think our overall goal is to strengthen the geronimo community by
> bringing in new developers and code that we as well as they want to
> work on.
>
> This process is likely to be more work for us than the new developers,
> since they  already know their code very well, whereas we need to learn
> their code and more importantly mentor them into being part of the
> geronimo community.  Therefore, we need to put together a process that
> involves the least work for us, and we need to commit the time needed
> to be good mentors.  To me, this means that the new people need to be
> given commit access to at least their donated code, since we simply
> won't have time to review all the patches that are likely to result
> otherwise, and the svn structure needs to be set up for minimal
> nuisance/simplest builds.  I think the last would be best with the new
> code going somewhere in the geronimo/trunk tree: although svn tricks
> are certainly possible to pull it in from elsewhere in apache svn, this
> would add some complexity for no gain I can see.
>
> I also think it is important to publish a process for donations, so we
> don't spend weeks discussing this every time someone offers something,
> and so potential donors know what to expect and dont get the idea that
> we are playing favorites.  If we run into problems, we can certainly
> update the process.
>
> 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.
>
> thanks
> david jencks
Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Jeff Genender
I have been waffling a bit back and forth on this issue...but I think I
have come to terms on my thinking on this subject.

I am not sure a "concrete" policy is necessary.  Every piece of code
that comes through as a donation, either from a commercial vendor or
from another open source project or community will have different
manners in which they come through the door.  Some may approch the PMC
first.  Some may just announce the desire on the the lists.  Each on
will be different.

How we handle each of these projects will likely not be the same
niether.  Some may flourish as a sub project to stand on thier own, some
are good for just being Geronimo specific.  A good example is the
console vs Trifork.  Clearly one can live on its own where the other cannot.

Perhaps "guidelines" or a howto, that offers options on how to get your
code into the project as a opposed to a "policy'.  Ultimately, IMHO,
each will be individually handled based on the merits and direction of
the code base coming in, as well as any additional baggage that comes
along with it.

David Blevins wrote:

> ("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.")
>
> +1  Building relationships, mentoring, thousand points of light.
>
>
> Respectfully,
> David
>
>
> On Tue, Jul 12, 2005 at 10:32:48AM -0700, David Jencks wrote:
>
>>In order to avoid mile-long emails I'm starting over.
>>
>>I think our overall goal is to strengthen the geronimo community by
>>bringing in new developers and code that we as well as they want to
>>work on.
>>
>>This process is likely to be more work for us than the new developers,
>>since they  already know their code very well, whereas we need to learn
>>their code and more importantly mentor them into being part of the
>>geronimo community.  Therefore, we need to put together a process that
>>involves the least work for us, and we need to commit the time needed
>>to be good mentors.  To me, this means that the new people need to be
>>given commit access to at least their donated code, since we simply
>>won't have time to review all the patches that are likely to result
>>otherwise, and the svn structure needs to be set up for minimal
>>nuisance/simplest builds.  I think the last would be best with the new
>>code going somewhere in the geronimo/trunk tree: although svn tricks
>>are certainly possible to pull it in from elsewhere in apache svn, this
>>would add some complexity for no gain I can see.
>>
>>I also think it is important to publish a process for donations, so we
>>don't spend weeks discussing this every time someone offers something,
>>and so potential donors know what to expect and dont get the idea that
>>we are playing favorites.  If we run into problems, we can certainly
>>update the process.
>>
>>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.
>>
>>thanks
>>david jencks
Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Alan Cabrera-2
In reply to this post by Geir Magnusson Jr.
Geir Magnusson Jr. wrote, On 7/12/2005 8:43 AM:

>
> On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:
>
>>
>> All code donations go into
>>
>> /geronimo/incubator/donationx/*
>>
>> The contributors would get restricted committer access to their  
>> project; granting committer access gives us better visibility how  
>> well the person works in a community setting.  They and, hopefully  
>> Geronimo committers, would whip it into shape.  The community would  
>> provide guidance and, hopefully, vote it into Geronimo once its  
>> ready and all the appropriate paper work was obtained.
>> The "probationary" committers would, hopefully, get voted into  
>> Geronimo, regardless of their projects status.  I have never heard  
>> of a motivated developer not getting committer access.
>>
>
> I'd like to propose a slight modification.  That we give them  
> committer access w/o a formal, restricted ACL, but a clear  
> understanding that there's a place where they are bring brought in to  
> work, and if they wish to participate elsewhere, they do so via  
> standard engagement of working with others, learning about the area,  
> proposing changes on dev@ etc, until they and others are comfortable,  
> etc.
>
> Any change can be vetoed, and any change can be rolled back.  I think  
> we should assume a level of trust, and if broken, commit priv can be  
> revoked.
>
> Just consider for a little while.  I believe that this won't be a  
> popular suggestion, but the risk is small, and the upside great, it  
> keeps things simple, and I believe leads to a more unified, richer  
> community. :)


I don't think that the extended privs would necessarily lead to "a more
unified, richer  community" but would, instead, increase the burden on
those Geronimo committers charged with monitoring the contribution under
probation.


Regards,
Alan




Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Alan Cabrera-2
In reply to this post by David Jencks
David Jencks wrote, On 7/12/2005 10:32 AM:

> 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.

Very good points.

My thought was that isolating the contributions would be done to make
the mentor's job easier.  It would not be meant as a DMZ, which would
limit a project's potential flameout.


Regards,
Alan



Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Geir Magnusson Jr.
In reply to this post by Alan Cabrera-2

On Jul 12, 2005, at 8:32 PM, Alan D. Cabrera wrote:

> Geir Magnusson Jr. wrote, On 7/12/2005 8:43 AM:
>
>
>>
>> On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:
>>
>>
>>>
>>> All code donations go into
>>>
>>> /geronimo/incubator/donationx/*
>>>
>>> The contributors would get restricted committer access to their  
>>> project; granting committer access gives us better visibility  
>>> how  well the person works in a community setting.  They and,  
>>> hopefully  Geronimo committers, would whip it into shape.  The  
>>> community would  provide guidance and, hopefully, vote it into  
>>> Geronimo once its  ready and all the appropriate paper work was  
>>> obtained.
>>> The "probationary" committers would, hopefully, get voted into  
>>> Geronimo, regardless of their projects status.  I have never  
>>> heard  of a motivated developer not getting committer access.
>>>
>>>
>>
>> I'd like to propose a slight modification.  That we give them  
>> committer access w/o a formal, restricted ACL, but a clear  
>> understanding that there's a place where they are bring brought in  
>> to  work, and if they wish to participate elsewhere, they do so  
>> via  standard engagement of working with others, learning about  
>> the area,  proposing changes on dev@ etc, until they and others  
>> are comfortable,  etc.
>>
>> Any change can be vetoed, and any change can be rolled back.  I  
>> think  we should assume a level of trust, and if broken, commit  
>> priv can be  revoked.
>>
>> Just consider for a little while.  I believe that this won't be a  
>> popular suggestion, but the risk is small, and the upside great,  
>> it  keeps things simple, and I believe leads to a more unified,  
>> richer  community. :)
>>
>
>
> I don't think that the extended privs would necessarily lead to "a  
> more unified, richer  community" but would, instead, increase the  
> burden on those Geronimo committers charged with monitoring the  
> contribution under probation.
>

Why?  we have the same responsibility to the codebase either way.

geir


--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Davanum Srinivas
and we expect the same outcome either way too!!! (well integrated/well packaged)

On 7/12/05, Geir Magnusson Jr. <[hidden email]> wrote:

>
> On Jul 12, 2005, at 8:32 PM, Alan D. Cabrera wrote:
>
> > Geir Magnusson Jr. wrote, On 7/12/2005 8:43 AM:
> >
> >
> >>
> >> On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:
> >>
> >>
> >>>
> >>> All code donations go into
> >>>
> >>> /geronimo/incubator/donationx/*
> >>>
> >>> The contributors would get restricted committer access to their
> >>> project; granting committer access gives us better visibility
> >>> how  well the person works in a community setting.  They and,
> >>> hopefully  Geronimo committers, would whip it into shape.  The
> >>> community would  provide guidance and, hopefully, vote it into
> >>> Geronimo once its  ready and all the appropriate paper work was
> >>> obtained.
> >>> The "probationary" committers would, hopefully, get voted into
> >>> Geronimo, regardless of their projects status.  I have never
> >>> heard  of a motivated developer not getting committer access.
> >>>
> >>>
> >>
> >> I'd like to propose a slight modification.  That we give them
> >> committer access w/o a formal, restricted ACL, but a clear
> >> understanding that there's a place where they are bring brought in
> >> to  work, and if they wish to participate elsewhere, they do so
> >> via  standard engagement of working with others, learning about
> >> the area,  proposing changes on dev@ etc, until they and others
> >> are comfortable,  etc.
> >>
> >> Any change can be vetoed, and any change can be rolled back.  I
> >> think  we should assume a level of trust, and if broken, commit
> >> priv can be  revoked.
> >>
> >> Just consider for a little while.  I believe that this won't be a
> >> popular suggestion, but the risk is small, and the upside great,
> >> it  keeps things simple, and I believe leads to a more unified,
> >> richer  community. :)
> >>
> >
> >
> > I don't think that the extended privs would necessarily lead to "a
> > more unified, richer  community" but would, instead, increase the
> > burden on those Geronimo committers charged with monitoring the
> > contribution under probation.
> >
>
> Why?  we have the same responsibility to the codebase either way.
>
> geir
>
>
> --
> Geir Magnusson Jr                                  +1-203-665-6437
> [hidden email]
>
>
>


--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Reply | Threaded
Open this post in threaded view
|

Re: Donations & Policies

Geir Magnusson Jr.
In reply to this post by Alan Cabrera-2

On Jul 12, 2005, at 8:32 PM, Alan D. Cabrera wrote:

> Geir Magnusson Jr. wrote, On 7/12/2005 8:43 AM:
>
>
>>
>> On Jul 11, 2005, at 10:56 PM, Alan D. Cabrera wrote:
>>
>>
>>>
>>> All code donations go into
>>>
>>> /geronimo/incubator/donationx/*
>>>
>>> The contributors would get restricted committer access to their  
>>> project; granting committer access gives us better visibility  
>>> how  well the person works in a community setting.  They and,  
>>> hopefully  Geronimo committers, would whip it into shape.  The  
>>> community would  provide guidance and, hopefully, vote it into  
>>> Geronimo once its  ready and all the appropriate paper work was  
>>> obtained.
>>> The "probationary" committers would, hopefully, get voted into  
>>> Geronimo, regardless of their projects status.  I have never  
>>> heard  of a motivated developer not getting committer access.
>>>
>>>
>>
>> I'd like to propose a slight modification.  That we give them  
>> committer access w/o a formal, restricted ACL, but a clear  
>> understanding that there's a place where they are bring brought in  
>> to  work, and if they wish to participate elsewhere, they do so  
>> via  standard engagement of working with others, learning about  
>> the area,  proposing changes on dev@ etc, until they and others  
>> are comfortable,  etc.
>>
>> Any change can be vetoed, and any change can be rolled back.  I  
>> think  we should assume a level of trust, and if broken, commit  
>> priv can be  revoked.
>>
>> Just consider for a little while.  I believe that this won't be a  
>> popular suggestion, but the risk is small, and the upside great,  
>> it  keeps things simple, and I believe leads to a more unified,  
>> richer  community. :)
>>
>
>
> I don't think that the extended privs would necessarily lead to "a  
> more unified, richer  community" but would, instead, increase the  
> burden on those Geronimo committers charged with monitoring the  
> contribution under probation.

Let me elaborate - the burden is the same.  We are responsible for  
the entire codebase.  Whether or not the new committers have an ACL  
that lets the write to modules/kernel doesn't remove our  
responsibility for the new code that was brought in.

I can picture a process where there is no probation.  We'd be saying  
that the contribution of the code is, to the PMC, reasonable  
demonstration of commitment (this is a judgement we'd have to make  
each and every time for every offered contribution), and that we are  
willing to trust that they'll work on that contribution in a "good  
way" with us.  For the other parts of the Geronimo codebase, we ask  
that they never just go jumping into anything, but work with the  
other committers to be sure that they are working in a way compatible  
with the existing community.

Anyone who violates that trust that we offered will have committer  
privs revoked.   Anyone who respects the trust offered will naturally  
blend into the rest of the committer community.

Any bad code change can be vetoed (and I think that we must become  
more comfortable with vetoing and more comfortable as accepting it in  
a non-personal, technical manner...)

I think that this is the cleanest, simplest and most elegant way.  
OTOH, I do recognize that there's a large element of trust as well as  
a real lack of exposure and experience with the new people we'd be  
bringing in.  OTOOH, there are no guarantees in life :)

geir

--
Geir Magnusson Jr                                  +1-203-665-6437
[hidden email]