Ideas: Design for multi-proposals & Loomio >> Project / Task Managament

Working with colleagues at Southwark Council in London many years ago we developed a decision making system (DMS) to let all residents of the borough make proposals for borough wide policy, and enabled all residents to debate and vote on those proposals... it wasn't brilliant but revealed various lessons:

1. it is most useful to have the debate related to a proposal directly under that proposal (unlike here, where we have 2 active proposals now, but only this one debate thread)

2. it is useful to let debaters categorise their debate. i.e. are you arguing "For" or "Against" the proposal, or are you neutral? This helps see where the decision is likely to go and also to group arguments...

3. Proposals should be (able to be) 'time bound' (i.e. to have a set amount of time before votes are called and a limited time / quorum for voting) - I think Loomio does this now...
   

   1. once a vote has been called and a decision has been made it is no use ending there, because nothing may happen! Instead "decisions on proposals" need to be able to evolve into an "implementation" phase once decisions have been made. i.e. In Loomios case, be pushed through to an interoperable Project and task management system. This would also help force people to structure Proposals better, since they would need to specify "deliverables" etc

I would guess that pretty much every group on Loomio suffers the "what do we do now?" problem once a decision has been made and wonders which Project / Task Management / Group management system to use next, to coordinate the activities based on the decision which has been made...

The final phase of the DMS we designed, after "implementation" was an "Evaluation" which enabled residents to say how well they thought the proposal had been executed... feedback from this was then encouraged to be converted into new proposals, and so the cycle continued...

Proposals >> Debate >> Decisions >> Implementation >> Evaluation >> Proposals... etc :)

On the subject of a linked / inter-operable Project / Task management system:

it would be cool if, in a proposal I propose:

Title: Build a space ship to go to the moon
Requirements: £1B, and XX full time people
Stages: Developing the space ship design - 2 years, Prototyping - 1 year, Testing - 2 months etc
etc

Then, when (if!?) the proposal gets enough votes to enter "implementation" stage it automatically gets ported to a Project & Task management System and is already pre-populated with the same "Stages" as listed above, in the proposal, plus all the people who contributed to / debated on the proposal are already "members" on the Project...

The idea being to remove the "lull" and boost the enthusiasm of people who contributed...
and to generally expedite the "decision" to "implementation" process.

I think that would be cool - and increase the efficiency of collaborative projects a lot

best
Oli

@olisb Great idea! But I think the direction to go in is embedded Loomio discussions, which have been proposed (in Loomio) several times, but not acted upon yet. Then you could embed a Loomio proposal into whever you are managing your project, whatever software, as long as the software can handle embeds.

This makes sense from an engineer POV, where you're already used to chaining lots of different kinds of software into workflows, and I agree it would be a good feature. In the council consultation use case that @olisb mentions though, the challenge is keeping the system so simple even your Granddad can use it. @olisb are you suggesting that Loomio itself be extended with some simple project management tools, or like @bobhaugen that you want Loomio to interoperate with some other existing project management tools?

In the latter case, the challenge is defining a stable API (am I using API right?) that would allow 2-way communication between Loomio and multiple platforms without Loomio devs having to build and maintain a specific bridge for every platform someone wants supported (they would probably be happy to do that if someone paid for it though eg Slack bridge). Stable APIs are hard to get right without tying the code into dependencies that make it more difficult to make other improvements. I've seen free code CMS projects really struggle with it, particularly Drupal (causing at least one fork) and Elgg (causing a core dev to quit in frustration).