Jim Grisanzio wrote:
> Also, as I explained on the call, we should focus on the information 
> that we need to move to the next step, which was asked for 10 weeks ago 
> by the infrastructure team: (1) group categories, 

They are there, proposal #1 is the group categories

> (2) roles within each group, 

Proposal #2...

Looking at this from an OGB Governance perspective, *we* don't
care about committer roles, coordinators, leaders, etc - those
are out of the OGB's scope for this discussion.

This is not to say that they are not useful or desirable roles,
or that Alan shouldn't design for them, but they have nothing
to do with community governance and everything to do with
per-group policy and operational administration.  Look at how
your descriptions are worded:

     Committer: A Participant ... who has commit rights to
                any code repositories owned by the Project.
and

     Leader: A Committer elected by a Project to lead a Project.

These sound to me like operational roles that are defined by
per-group policies....


> (3) and relationships (if any) between the groups. 

You are right, there is nothing there about relationships.  Please
add what you think is needed.  IMO, it is something like "Groups
are expected to be able to self-define many different types of
relationships between themselves and other groups.  Examples that
come to mind are 'sponsorship', 'affiliation', 'dependency' and
the like."

> That's it. 

Not quite - Simon's proposals to create Membership and Resource
committees is part of this as well.  I tried to split them out
into separate proposals and you talked at length about why you
wanted to keep everything together in one document...


> That's what we have to vote on next week. The membership 
> process/committee and the group creation process/committee are not tied 
> to the initial decisions of the first three items, so we ought to defer 
> them so we can move faster.

I don't see any reason that they would slow things down.
Nobody is arguing against them; the only unknown is the
specifics about their policies/boilerplates - which are
not really part of what we need to have to move forward.


   -John

Reply via email to