John Plocher wrote: > 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.... > >
No. They are non-voting, operational roles but they are defined by the OGB. We can't have each Group defining their own Roles. That would not work with the webapp. We have to specify the roles, communicate them to the community, gain consensus for the changes, vote on them, etc. This way Alan knows what the new roles are for the webapp work. Other apps have to be integrated into the Roles we specify (wiki, scm, etc). A Group may define who gets to be a Committer in a given project, but we in the OGB have to create the Role in the first place. >> (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." > I don't see any formal relationships as of yet, but that may change over time or if someone argues for it now. At least initially, anyway, I think the Groups can associate as they wish in an informal way. I think what Alan was looking for is any formal relationships that he'd have to write into the webapp. I don't see that right now. >> That's it. >> > > Not quite - Simon's proposals to create Membership and Resource > committees is part of this as well. Sure, for the entire, multi-step reorg, I agree. But the first step is to agree on the roles/categories, that's all I'm saying. Let's agree on step one, then go to step two, etc. We already know we want/need resource and membership committees, but discussion around them is not required to complete the roles/categories decisions. When we think in terms of the entire reorg, it's too much and it delays movement on small parts. > 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... > They were just placeholders (holding for Simon's resources/membership committees). The document is not set in stone. It emerges over time. The important bits for now are the roles/collectives. >> 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. > They may or may not. But they are not needed for this week. I only want to focus on what's needed to get a decision and communicate that decision. > 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. I agree. Jim -- http://blogs.sun.com/jimgris
