[sudo-discuss] [OMNI] Proposals up for consensus

Tue Jul 22 22:49:28 PDT 2014

A few more thoughts/questions:
* Isn't a block only valid if the argument can be made that it violates
some shared values/mission/purpose?  I see there is a Vision document
document for the Omni, but I don't know if a Mission statement exists;
perhaps, someone can illuminate.
* How does sudoroom choose delegates? I know Jenny is a delegate.  Is Jenny
the only sudoroom delegate? Is this a frequently rotating position? I
apologize if this is already documented, but I couldn't find it in the wiki.

On Tue, Jul 22, 2014 at 5:38 PM, Patrik D'haeseleer <patrikd at gmail.com>
wrote:

> I definitely think there is value in having something else than unanimous
> consensus for certain types of votes - whether it's N-2, 2/3 or 50%.
>
> Some routine votes need to be made in a more lightweight fashion, and it
> would be good if we could do without the built-in 1 week delay we have with
> our current model. in other cases, there may be an issue that has already
> gone through a de facto consensus process - e.g. a proposal from a working
> group that has been worked out very publicly, and on which the WG itself
> has already reached a consensus.
>
> If we do go with a % vote on certain issues, we may also want to consider
> limiting that vote to delegates-only for some of those. Otherwise, it may
> become too easy for some special interest group to stack the delegates
> meeting to reach the required percentage.
>
> Patrik
>
>
> On Tue, Jul 22, 2014 at 4:13 PM, Jeremy Entwistle <
> jwentwistle at cryptolab.net> wrote:
>
>>
>> On 07/20/2014 02:10 AM, Matthew Senate wrote:
>> > Sudo Room decided we would use various voting procedures for particular
>> > circumstances because we anticipated those issues arising and wanted to
>> > prevent our own immobility on them. I think this can be a good idea:
>> >
>> > Can you (or anyone) generate a simple list of all the types of decisions
>> > the Omni Collective may consider in which perhaps a different sort of
>> > decision procedure than consensus should be used (e.g. a vote, and
>> > therefore some type of vote such as a super majority [some value over
>> 50%]
>> > or simple majority vote [50%])?
>>
>> Yes! Here are some things that may need to happen and could be
>> threatened by a person who doesn't want it to happen, which would then
>> need a majority vote:
>>
>> * pay rent, utilities, and other liabilities to the space
>> * submit legal documentation (permits, etc)
>> * suspensions and bans (if banned from a collective)
>>
>> I think of the omni collective as those who ensure the space may be used
>> by the collectives and prevent conflicts when there's a disagreement
>> between them. I don't think of it as something that approves of
>> everything we do or resolves individual's conflicts.
>>
>> Otherwise, I think we should be using consensus. It's not about asking
>> for approval to do something, its about making decisions that improve
>> the space for everybody. I don't want to tell anybody they can't do
>> anything until approved by everybody, but rather say they can do
>> everything but these things. Some of these things might be:
>>
>> * changing the structure of the building
>> * restricting access to the space by changing access control
>> * painting common areas or removing flooring
>> * using the common areas when something has been scheduled
>>
>> I still think we should define what it means to be a collective at the
>> omni. And some of that definition should require the collectives to have
>> a code of conduct. I most definitely agree we should be very delicate
>> about how we discuss and decide resolutions for these issues, especially
>> if we're asking everybody to agree to them and feel empowered to enforce
>> the decisions.
>>
>> >
>> > I suggested in another email (did not see this reply at first) that we
>> > should consider allowing consensus to fail, and requiring we then table
>> the
>> > item for one week before a 2/3 vote (or similar) can be held,
>> encouraging
>> > clarity, accountability, feedback, and level-headedness.
>> >
>> > // Matt
>> >
>>
>> In my experience, when you have the option to wait for the majority
>> vote, that's what happens. We should enable ourselves to do things that
>> secure the space for all the collective by using a majority vote for
>> some things, but use consensus when we're creating rules that will
>> affect everybody. The bigger the majority, the more it demonstrates our
>> confidence in the decision.
>>
>> I feel how we make decisions and how those decisions are enforced is
>> what makes this different from the rest of the world. I feel it's why
>> there's so much beauty in it!
>>
>> >
>> > On Sun, Jul 20, 2014 at 7:59 AM, Jeremy Entwistle <
>> jwentwistle at cryptolab.net
>> >> wrote:
>> >
>> >> We should pay our debts to the attorney. And we should pay rent as
>> >> though it we were required to pay it.
>> >>
>> >> But for the consensus process, I think there should be limits in place
>> >> if we're going to use majority voting. If we're going to be using
>> >> majority voting, it should only be used to secure the space for the
>> >> collectives. There was an issue at another space where they needed to
>> >> get a permit to stay open, but somebody blocked consensus and used it
>> as
>> >> leverage. I think using majority voting should be used ONLY for issues
>> >> that would prevent us from using the space and that those things should
>> >> be defined as explicitly as possible. For instance, we could use
>> >> majority voting for suspensions or bans.
>> >>
>> >> Not to mention, I think the majority should be three-fourths or
>> >> four-fifths if we're really making an exception to consensus based on
>> an
>> >> individual with bad intentions. Also, I'm not sure why we would have a
>> >> consensus vote if we were to switch a majority vote afterwards--that's
>> >> just a majority vote.
>> >>
>> >> And lastly, is anybody interested in creating a proposal for a
>> >> distributed delegates for our collective? We would vote as a
>> collective,
>> >> but it would give our members the opportunity to raise concerns and
>> >> issues about a decision at the main meeting instead of waiting to hear
>> >> back from a delegate.
>> >>
>> >>
>> >> On 07/19/2014 07:53 PM, Jenny Ryan wrote:
>> >>> Hey sudo!
>> >>>
>> >>> At Thursday night's Omni delegates meeting, the following proposals
>> were
>> >>> put forth and are up for discussion over the next week, to be voted on
>> >>> at next Thursday's Omni meeting:
>> >>>
>> >>> 1. Paying Jesse
>> >>> Jesse Palmer is the Omni's lawyer and has done a phenomenal job
>> >>> helping us get to where we are now. His bill totals somewhere in the
>> >>> realm of $8500, which divided among 10 collectives means Sudo would
>> >>> contribute ~$850.
>> >>>
>> >>> 2.  Paying an additional month of rent into a reserve
>> >>> Our rent for July is free, but all collectives could pay rent for the
>> >>> month of July anyway to be put into a reserve fund. I think this is a
>> >>> great idea, and we have the funds for it (I believe we have ~$12,000
>> >>> in the bank).
>> >>>
>> >>> 3. Revision to Consensus Process:
>> >>> Thus far, the Omni Collective has made decisions using a full
>> >>> consensus model. The proposal on the table is for votes to strive for
>> >>> full consensus, but resort to a 2/3 majority vote if consensus cannot
>> >>> be achieved. This model was recommended by Jesse, who has extensive
>> >>> experience representing coops and collectives who've run into problems
>> >>> with full-consensus models for hairy decisions like banning an abusive
>> >>> individual or - as may be the case with us - removing particular
>> >>> groups/collectives from the larger collective.
>> >>>
>> >>> Proposal : New Voting Model
>> >>>
>> >>> All votes called by the Delegate Council are subject to two rounds of
>> >>> voting. The first round passes by full consensus. If after friendly
>> >>> amendments and conversation full consensus cannot be achieved, the
>> >>> vote moves to a second round which passes by 2/3 majority. If this
>> >>> second vote fails to pass, the vote does not carry.
>> >>>
>> >>> This amendment to our full consensus voting procedures is proposed in
>> >>> light of advice from radical comrades and colleagues who have seen
>> >>> groups and projects torn apart by bad-faith exploitation of full
>> >>> consensus voting. Our group's aim and aspiration will always be full
>> >>> consensus, and we will always work to make sure all voices are heard.
>> >>> In all of our work and decisionmaking together, let us always be
>> >>> guided by fairness, kindness, and justice.
>> >>>
>> >>> ----
>> >>> Please discuss any issues posed by the above proposals, make
>> >>> amendments, and feel free to attend next Thursday's meeting if you'd
>> >>> like to participate!
>> >>>
>> >>> Cheers,
>> >>> Jenny
>> >>> http://jennyryan.net
>> >>> http://thepyre.org
>> >>> http://thevirtualcampfire.org
>> >>> http://technomadic.tumblr.com
>> >>>
>> >>> `~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`
>> >>>  "Technology is the campfire around which we tell our stories."
>> >>> -Laurie Anderson
>> >>>
>> >>> "Storytelling reveals meaning without committing the error of defining
>> >> it."
>> >>>  -Hannah Arendt
>> >>>
>> >>> "To define is to kill. To suggest is to create."
>> >>> -Stéphane Mallarmé
>> >>> ~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`~`
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> sudo-discuss mailing list
>> >>> sudo-discuss at lists.sudoroom.org
>> >>> https://lists.sudoroom.org/listinfo/sudo-discuss
>> >>>
>> >> _______________________________________________
>> >> sudo-discuss mailing list
>> >> sudo-discuss at lists.sudoroom.org
>> >> https://lists.sudoroom.org/listinfo/sudo-discuss
>> >>
>> >
>> _______________________________________________
>> sudo-discuss mailing list
>> sudo-discuss at lists.sudoroom.org
>> https://lists.sudoroom.org/listinfo/sudo-discuss
>>
>
>
> _______________________________________________
> sudo-discuss mailing list
> sudo-discuss at lists.sudoroom.org
> https://lists.sudoroom.org/listinfo/sudo-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sudoroom.org/pipermail/sudo-discuss/attachments/20140722/e970413e/attachment.html>