On Fri, Jan 29, 2010 at 5:41 PM, John Plocher <john.plocher at gmail.com> wrote: > On Fri, Jan 29, 2010 at 3:28 AM, Peter Tribble <peter.tribble at gmail.com> > wrote: >> 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. > > I would like some dialog with Alan and the web team before going too > far here, which is why I started with a vision of the future and not a > recipe for getting there. ?I would like the web team to have a chance > to understand this change and come up with some suggestions... > >> Choice 1: scrap the electorate collectives for community groups, and say that >> anyone with the leader, affiliate, developer, or facilitator role in >> auth qualifies. > > Unequivocally Scrap It. ?It was poorly thought out, poorly implemented > and poorly understood, and, with the "new" constitution, completely > unnecessary.
So you have choice 2? > As for "So, either we break our principles" - what principles are > they, exactly? The principle that we don't conflate roles: specifically that we don't use the same role for operational and governance purposes. >?IMO, the reason for those "principles" was simply that > the "old, current" constitution forced everyone who was a CC to also > be a Member of the electorate. ?Breaking CGs into Governance and > NonGovernance parts (Affiliate/Leader -vs- C/CC) was only an > implementation mechanism to get us out of that forced 1:1 > correspondence. > > The "new, proposed" constitution doesn't have that 1:1 forced > connection between group contributorship/leadership and Membership in > the electorate, so we no longer need those old mechanisms. ?We solved > that "principle" problem in another way, so we can easily and safely > scrap all that stuff and go back to a simpler world, secure in the > knowledge that we won't get an electorate filled with reluctant > Members AND that we don't need to maintain two sets of rules. All this does is reverse the problem. To take a project: in the old scheme, all those with commit rights had to vote for the OGB. In the new scheme, if you think someone has contributed to the project enough to vote for the OGB, you have to give them commit rights. To give edit rights to the website, you may have to award the contributor role before the participant can contribute (initial code commits tend to be sponsored while developers gain experience). And contributions are permanent, so removing the role doesn't remove the contribution. Also, removing the group shouldn't remove the ability to vote. I can't see a viable mechanism in which you can simply use the roles to assign eligibility. You have to have a separate list of people who have contributed, that is maintained separately from and under different rules to the operational roles -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
