[ogb-discuss] Restructuring: getting the ball rolling - roles and structure proposal writeup

[John Plocher]

Alan Burlison wrote:
> What I need from the OGB is a decision on which collective types are 
> required, and what roles people may have within those collectives.

When did we decide to use "collective types with subsidiary roles"?
Who is the "we" that decided this?  What happens if the OGB comes up
with something different?  I'm very confused.

Maybe you could give a detailed example (along the lines of the use
case I presented) that shows how you see this all working.  I get the
feeling that we are talking at cross purposes to each other, with
me seeing things at one level and you, at another.

>  As I understand it, 
> your suggestion is for a centralised repository which stores attributes 
> for all the applications that make up the opensolaris.org whole.  

I'm not sure where you get that level of implementation detail out of
what I wrote.

 From the OGB's perspective, all we are defining are three governance
related roles:

     Participant - Someone who is interacting with our community
     Contributer - Someone who has contributed something significant
                   to our community and has filed a contributer agreement
     Voter       - A Contributer who wishes to influence the
                   community as a whole.

any other "roles" (your term) or abilities or authorizations (mine)
are defined elsewhere by others, probably on a per-site, per-project
and/or per-problem-of-the-day basis.  (i.e., the list of "roles" is
not static, and probably not hierarchical, though if the system was
designed to be extensible, an initial list would be easy to draw up).

In particular, there seems to be an assumption that being a Contributer
implies that one can edit web pages, create repositories and commit
changes.  My fear is that, by hardcoding this relationship, you make
it impossible to have a Contributer who does not (or should not) have
those rights.

Maybe I'm misunderstanding something...

To Michelle's point, we *will* need a transition plan, and it is
extremely reasonable to assume that it will simply map the existing
people/roles/abilities to the new ones with some sort of formulaic
process like: Core Contributers who have web page editorship turn
into [...] in the new system...  The exact details are TBD.

> it is unsatisfactory.  Replicating it is not a sensible option.

Agreed.

> I see nothing in that which requires a centralised repository of 
> per-user attributes, as what you are describing in your use case is a 
> set of loosely coupled but cooperating systems, not a monolith.

Agreed.  Which is why I suggested "can be better explained".  Will you?

   -John