Open Stack

Hi all - The OpenStack Foundation has already worked up at least a 
portion of this solution by allowing one or more users with an 
OpenStackID to be set as a CCLA Admin for their organization. The CCLA 
Admin can designate one or more CCLA teams for their company. And then 
each team can be comprised of multiple members. Members can be assigned 
as long as they have a Foundation Membership and have a GerritID. If 
they don't, they will be prompted to register and get a GerritID.

We also regularly run an ingest from Gerrit to retrieve Last Commit, 
Gerrit ID, based on the Foundation Member email address. It may not be 
possible, but perhaps we could offer the same check that we offer for 
Foundation Members. Just a True/False if the user is a valid CCLA member.

We are also flexible enough to add or ingest ANY info from Gerrit that 
you need to associate with a Company (CCLA Agreement #, etc...)

Just throwing this out there for discussion.

Thank you,

-- 
Jimmy McArthur / Tipit.net <http://Tipit.net>< jimmy at tipit.net 
<mailto:jimmy at tipit.net>>
m: 512.965.4846
o: 512.481.1161



Clark Boylan wrote:
> On Thu, Mar 12, 2015, at 05:41 PM, Stefano Maffulli wrote:
>> hello folks,
>>
>> We would like to provide a greater degree of freedom to individuals who
>> contribute on behalf of corporations who signed the Corporate CLA. By
>> allowing corporate managers to maintain list of their authorized
>> contributors we may be able to remove the need for every individual to
>> sign an iCLA.
>>
>> Currently, corporate managers sign the CCLA on echosign and provide a
>> list of approved contributors on the "Schedule A". That list is kept
>> only as an archived 'paperwork' since it's not machine readable. OTOH to
>> make sure that we have a track of who is authorized to commit code, we
>> require every individual to sign the iCLA whether their name is in a
>> Schedule A or not. This has been confusing a lot of people, creates
>> unnecessary manual work and duplication of information.
>>
>> How would the infra team suggest we tackle this problem?
>>
> Based on the success of projects self managing third party CI voting
> rights, I think we can solve this in a way very similar to how Gerrit
> does it for contributions to Gerrit itself.
>
> For each company that has signed a CCLA two groups would be created in
> gerrit:
> * companyname-ccla-owner, this group would be self owned and have
> membership of company representatives that decide who can push to
> Gerrit.
> * companyname-ccla-members, this group would be owned by
> companyname-ccla-owner and its membership would include those users can
> can push to Gerrit.
> Then each companyname-ccla-members would be added to the super group for
> all CCLA signers
>
> This will give companies greater tracking over who is covered by their
> CCLA and remove the need for the ICLA as a proxy for that.
>
> The one hurdle we need to get over is delegating the group creation,
> initial ownership and membership config, and addition to the super CCLA
> group to a group that isn't the Gerrit admins. I don't want to become
> the bottleneck that has to decide when a CCLA is properly signed.
>
> Options for this:
> 1. Potentially Gerrit ACLs be made rich enough to delegate these
> activities to groups other than Gerrit admins (perhaps Zaro can comment
> on this).
> 2. We could write a tool that used a serialized set of group info and
> enforced that in Gerrit. Then have a repo for this data whose core team
> was able to validate the CCLA process is complete before updating Gerrit
> via updates to this repo.
>
> Thoughts? Particularly interested in thoughts on the two options just
> above and any other ideas people may have to tackle that particular
> implementation detail.
>
> Clark
>
> _______________________________________________
> OpenStack-Infra mailing list
> OpenStack-Infra at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20150313/d57137a8/attachment.html>