On Wed, Jan 27, 2010 at 1:25 AM, John Plocher <john.plocher at gmail.com> wrote: > The OGB Electorate Membership Process document has been updated to > reflect today's discussion (including taking inspiration from the > GNOME foundation's process...) > > See > http://wiki.genunix.org:8080/wiki/index.php/OGB_Electorate_Membership_Process
In the Mechanics section, it says: In the best of all worlds, ... However, we're not in that world, and what's missing is a description of how that world works and what we need to change to get there. The auth app doesn't currently cover constitutional roles. It has operational roles. (Apart from the electorate collectives for community groups, which were special-cased at our request, and which are needed to paper over the cracks between the new infrastructure and the old constitution.) So, either we break our principles and say that all governance is driven by the operational roles in auth, or we have to say that there exists a completely parallel set of governance roles. Choice 1: scrap the electorate collectives for community groups, and say that anyone with the leader, affiliate, developer, or facilitator role in auth qualifies. Choice 2: extend the electorate collectives so that there's one for every project and user group, and use those to store contributions. Which one of those is going to be adopted? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
