Sat 30 Mar 2013 6:18PM

Allow clearence of topic with 80% Support

BMC Blaise M Crowly Public Seen by 16

We need to permit a topic to be cleared even if it not 100% supported, but should try to make it 100%. The 100% requirement is an agent of chaos, as anyone can just continue to veto every move causing the system to fail.

So we should let in movements with votes > 60%-80%(depending on number of voting members) to be cleared.


TheDentist Sun 31 Mar 2013 2:53AM

There is a need for improving the consensus process however straight away setting the clearance to 80% is bad for minorities. It seems here are our choices:
1) Set the clearance to 80% and put other protections mechanisms for minorities.
2) Improve upon the consensus process to tackle fundamentalism and to improve free thought and discussion.


kshytia ali fakr Mon 1 Apr 2013 8:13AM

we are a small group now of say 10 people. At this stage if there cannot be 100% consensus it will be difficult to achieve even 80% with the next size of group of say 100.


kshytia ali fakr Mon 1 Apr 2013 8:13AM

@Dentist - +1 for option 2


TheDentist Mon 1 Apr 2013 6:54PM

So i tried to formulate the consensus process into steps that we can perform. So here are the steps:

  1. Informal discussions will lead to the formation of a problem statement. A problem statement describes only the problem not the solution.
  2. A member initiates the process by releasing the problem statement(optional) and a proposal to the members.
  3. The proposal is said to be in discussion mode for one week. In this week, the members may ask the proposer to amend his proposal. If the proposer agrees to a member then its fine, but if not, the member may release a counter-proposal. This process continues for the week.
  4. At the end of the week, we will end up with multiple proposals given by different members. Lets say the proposals are P1, P2 and P3. The voting now commences. The process of voting is described below:
    • For each proposal a member may vote "Yes" or "No". A member may vote for multiple proposals but only once for each proposal.
    • If you think P1 is completely a better proposal than P2 then vote "yes" for P1 and "No" for P2. (even though P2 sounds fine to you)
    • If you like both P1 and P2 and are undecided between them, vote "yes" for both.
    • If you don't like both, and disagree with the problem statement itself, you can vote "No" for all the proposals.
    • If you liked some aspects of P1 and some aspects of P2 and if you can come up with a better proposal then work on the better proposal. Vote "No" for all the current proposals and submit your proposal in the next cycle. (You should have already submitted your proposal, you had a weeks time. But there is always the next time). If you dont have the resources to work on a combined proposal, then vote "yes" for both and help them stay in the race.
  5. After voting (in a meeting) the future of the proposals are decided by the following rules:
    • If the acceptance rate of the proposal is < 50% then the proposal is out of race.
    • If the acceptance rate of the proposal is >=80% then the proposal is said to be "Staged"
    • If the acceptance rate of the proposal is >=50% but <80% then the proposal is said to be "Running".
  6. This marks the end of a cycle. At the end of a cycle if there are only "Staged" proposals left (ie all proposals in the race are >80% accepted) then in the same meeting a final vote takes place where the members must choose one proposal, here majority wins (with no defined percentage). (Question: How do we break ties here?). The selected proposal is implemented, process ends.
  7. The next cycle is initiated at the end of the meeting. Same process is followed. The members have a week to prepare counter proposals. The existing proposals cannot be edited by the owner (or anybody) once it has been voted upon, the member must submit the proposal under a new code (like if you improve upon P1, then call it P4 let P1 be). The members must be open while preparing the proposals, so that others can give comments.
  8. If there are proposals at the end of the cycle that are "running" and not "staged" then it means all concerns are not met. So the process must continue.
  9. The proposal must of course abide by the constitution of India and the party. (Rights defined in CoI must not be violated).

Please comments and feedback.


TheDentist Mon 1 Apr 2013 7:07PM

For obvious reasons, loomio would be unsuitable for such a process. How about a wiki? Maybe wiki + some other tool (mail or loomio).

Frankly i thought loomio would mail the members every time there was a comment, making it an improvement on the mail list. Sadly there is no option to do that.


kshytia ali fakr Mon 1 Apr 2013 7:16PM

All this seems too complicated for non-geeks. I would suggest something like-

1) Limit the maximum size of any "unit" (ie. group, sub-group, or sub-sub-group etc.) to 10. Members are assigned to units strictly in order joining date and time.

2) Every unit must have 100% consensus within it to vote.

3) All decisions are taken by at least 90% voting consensus of units of same rank in the hierarchy when at least 90% of the units have voting capability. (This is functionally equal to 81% consensus).


TheDentist Mon 1 Apr 2013 7:46PM

May i ask where you got stuck?

We are already less in number right now. But yes, something like units will be needed in the future.

I am not sure i get you in point 3. But i think you went into constitution procedures. I was talking about right now. Right now there is no need to units we can act as one unit.
I think the process i wrote can scale up to 100+ people. When we have regional and national level hierarchy, we will of course need a different method which we will define in the constitution.


kshytia ali fakr Tue 2 Apr 2013 2:41AM

Say the party has 357 members.
Group = 357
Sub-groups = 36 (with 10 members each)
so voting takes place at Sub-group level when 32 sub-groups have 100% internal consensus, and needs 28 votes for any proposal to succeed. If 90% of the groups cannot achieve internal consensus then the proposal is a non-starter.


kshytia ali fakr Tue 2 Apr 2013 2:44AM

Amend: If 90% of the sub-groups cannot achieve internal consensus then the proposal is a non-starter.

By my proposal scheme there will have to be considerable debate before the members of a sub-group "delegate" their vote as compared to a system where individuals blindly vote.


TheDentist Tue 2 Apr 2013 3:59AM

Breaking down the discussion into groups must speed up the process.
But this method still lacks the process of giving counter-proposals.
A method to give counter-proposal, which is more in consensus, is important as it invites members to do actual work on a proposal that will be more acceptable. Otherwise it all becomes jumbled words even with a small group of 10 people (example us).
Take for instance the recent proposal if "Internet Freedom". It has not been drafted properly, not much has been defined as to what consists of Internet Freedom. If the initiating member had given a properly worded proposal, other members could have improved the wordings and given a counter proposal.
We can divide the group for discussion, but the process of counter-proposal is a must. Also this must be open so that other groups can discuss the available proposals.

Load More