This is a discussion to figure out how, if at all, we should automate the attributions of outcomes to the proposals.

The manual process would be letting the author/facilitator/administrator choose the outcome of a proposal once it is closed by using a button-based interface similar to the one used for voting.

The semi-automated way that I propose would be to set rules at the moment when we create a proposal to determine how the results of the vote will impact the outcome. These specific rules could be:
- a minimum acceptance rate: state that the proposal shall not be adopted unless a certain percentage of the audience voted “YES” to it.
- a minimum participation rate (Quorum): states that the proposal shall not be adopted unless at least a certain percentage of the audience casted their vote.
- possibly other options such as “automatically reopen for X days if quorum not reached“ etc…

One the proposal is closed, the author/facilitator/admin would either chose to go with whatever the generated outcome is, or decide to do something else with the proposal:
- reopen it: postpones the due date (and possibly change the outcome rules?)
- amend it: leaves this proposal "as is" and open a new editable copy of it, with no vote attributed.
- abandon the proposal: state that the proposal (and its generated outcome) doesn't make sense anymore

The reason for this shift is to allow more formal decision-making processes (e.g. compatible with law), more transparency for the audience, and less ambiguity amongst the diverse stakeholders.

For more insight on my reflection on this, see this document (which you are welcome to edit/comment on):
https://docs.google.com/document/d/1Zs454ok3kJ6YFPcrxh992fRmo7dudkwd7492pD3Bhi8/edit

What are your thoughts regarding the semi-automated outcome generation?

Excellent background material here.

I'm still mulling it over but a couple of points I'm pondering while thinking it through:

How would this approach deal with multiple/consecutive proposals if they're implemented?

Does implementing automation limit the possibilities in any way? Or does this limit the possibilities even if it's not automated?

And will it influence the way in which people vote on a proposal? Eg/ Am I more likely to vote No or Block near the end of a proposal to stop an automated agree if my position would be abstained otherwise?

For a consensus decision-making model, the discussion management tools in Loomio are more important than the proposal/ voting engine. When using consensus, the pie chart is a straw poll - a way of getting a visual indication of whether consensus has been reached. The actions in response to a significant number of people saying 'no', or even 'abstain', would be to carry on discussion until consensus emerges. Often a proposal can include parts that everyone agrees with, and parts that are under-developed. Breaking off the agreed part into a separate proposal and seeing that there is consensus on it does three things:
* allows people to start implementing that decision
* lifts morale and confidence that the group can find consensus with enough thought and discussion
* allows the group to drill down to specific points of dissensus, which can then be further researched, reflected on and discussed until a clear solution emerges which the group can support

Loomio tools that could help this:
* ability to branch discussions so that the various issues that are causing people to say 'no' or 'abstain' can be explored separately
* ability to split a broad proposal into a number of more specific proposals

From Nicholas' comments, it sounds like you are extending Loomio to support majority-rules groups as well, which is fine, but good to be aware of the difference. Would it be worth having an option, or a configuration engine, that allow a new Loomio instance to be set up for consensus OR majority-rules (and potentially other situations).

Wow such good input on this thread already, love it. This is rich stuff.

My concern with this proposed feature is not so much about the specifics but with the underlying process for how features get designed and prioritised.

We've been doing some work with Keong on developing a User Centric Design Methodology, which is a coherent iterative process for determining what the users want and then prioritising how we deliver those features to them. We're starting to get our head around the UCDM process, the next step is figuring out how to make it work in a distributed development environment.

There's some notes about what we've been doing here:
https://docs.google.com/document/d/19ABs8EYc5LOJwVGxykEESw0z2TvqwyTK8tujG-Tci5k/edit

From the focus group with the users there was definitely a request for clarifying the outcome of proposals, so that's got to be one of our priorities. The question is how we develop the 'outcome' feature. I love the work you've put into it Nicolas. The problem is, as you've identified with your research, that automating the outcome opens up the can of worms of decision/discussion rule sets. It is likely that this will need to happen at some point, but i'm not sure that designing this huge feature in one block is the way to go.

My suggestion for how to move forward with this is to implement the simplest possible Outcome feature. Perhaps when a Proposal closes the Author is prompted to fill in a brief summary describing the conclusion. The Decision participants would then be notified of the Outcome and it would be attached to the Proposal when it moves down the screen into Past Proposals.

This should be super easy to build and can be deployed immediately, then we can see how the users respond and develop it further one step at a time. It's likely we'll want to add some kind of status (e.g. Passed, Failed, Reopened, etc), it's likely we'll want to be able to stipulate rule-sets to automate the process, and there's plenty of other options we can imagine too.

The thing is we can't guess what the users want so it's a much more efficient use of our resources to deploy something super simple and see what they tell us.

Obviously we've got to do more work on clarifying our process and then communicating it and making it accessible for anyone to contribute to. I feel like we're going to get in a groove though.

Thanks heaps for your background work Nicolas!

I think it's going to be really important for us to develop Loomio to provide a framework for the whole Discussion>Decision>Action process, so I'm very glad we're talking about this.

My worry with automated or semi-automated judgments about the outcome of a decision, is that it feels like it would be placing an artificial framework on an organic decision-making process. I'm much more in favour of a system where the outcome is described qualitatively by participants in the discussion. I think a great first step (which also happens to be potentially the simplest/easiest to implement) is for Loomio to send an email (or for a box to pop up inside Loomio) to the person who made the proposal when it closes, asking them to describe the outcome succinctly (250 characters?), which then gets added below the Proposal. I'd love to see a 'proposal outcome' message that goes out to the other people participating in the discussion (if that's the level of notification they want) that has the outcome summary, and shows the graph.

If other group members disagree with the proposal summary, they can say so in the discussion and ask for it to be modified.

Dynamic and flexible and easy!

That's how I'd love to see the default, anyway. I absolutely agree that there will be some formalised groups who will want very clear formal parameters - would love to see a plugin enabling that sort of thing to be implemented for groups that want it. How would you feel about that Nicolas?

Thank you all for your rich reactions here!

@Paul

The automation wouldn't change the way discussions are led, it would just be a way to automatically tag a proposal as "rejected" or whatever.
I don't think it would limit possibilities if the analysis we do is optimum. But I agree with others that we're not ready to do such an analysis and that we would need some experimentation with a simple version before we head this direction.

@Rich & @Ben

I think you've got me changing my opinion here. The best solution for know is to go with a fully manual process, as simple as possible, that might satisfy most of the groups' needs.

Looking this with a long-term perspective, I quite like the idea of an option in the group settings (instead of a "plugin") to tweak the way outcomes are made (notifications, automation etc…).

But for now, I totally agree that we should go as simple and flexible as possible.