James Carlson wrote: > One possible way to deal with this is to require community groups to > select a "type." The "type" specifies both the general purpose of the > group as well as a definite set of processes that it will follow. > > If a group determines that the existing "types" don't match its needs, > and can put together a compelling enough case for a new "type" > (hopefully generic enough that others may re-use), then the OGB (or > perhaps the full electorate) can vote to create it. It needs to be a > conservative process in order to limit the number of different types > to a manageable level.
The new opensolaris.org membership system (https://auth.opensolaris.org) is currently configured with the following "types" which are known by the Auth app as "collective types": Community Project User Group Electorate Communities are as in the present OSO Portal application, as are Projects. User Groups are recognised by the Auth app as distinct entities, whereas in the current OSO Portal they are mapped onto Projects because that's all that is available. The roles available in Communities, Projects and User Groups are: Participant Contributor Leader The Participant role will be self-administered and it is more-or-less equivalent to 'Observer' in the current OSO Portal. The Leader and Collective roles need to be granted administratively. Leaders can assign Contributor and Leader roles to others in the same collective. Each Community, Project and User Group has an associated Electorate collective. This consists of those members of a collective that can vote. Membership of an Electorate is granted by approval of the OGB or its designates. This is not hard-coded, more collective types and roles can be added to the system if required. However it does describe how the membership data in the current OSO Portal will be mapped onto the Auth application. A beta version of the application is available at https://auth.opensolaris.org, and is repopulated nightly from the current OSO Portal. Note that some of the pages (e.g. Collectives) are still being designed and written, but the underlying data is already present in the database. -- Alan Burlison --
