django app that implements the decision finding method: "systematic consensus finding"
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
tropf 01d5ecee8d Merge pull request 'add note on unmaintained status' (#71) from note-unmaintained into master 2 months ago
deployment download external dependency css-files during deployment and serve them locally 4 months ago
moodpoll download external dependency css-files during deployment and serve them locally 4 months ago
settings fix deployment-related bugs 11 months ago
.gitignore fix deployment-related bugs 11 months ago
CONTRIBUTING.md + CONTRIBUTING.md stub 2 years ago
COPYING.agpl3 add license file (AGPL3), fix README typo, add release.py, bump version 2 years ago
LICENSE add license file (AGPL3), fix README typo, add release.py, bump version 2 years ago
README.md add note on unmaintained status 2 months ago
manage.py rename settings directory 2 years ago
requirements.txt fix deployment-related bugs 11 months ago
setup.py update setup.py 2 years ago

README.md

moodpoll

App for easy and good decision making.

Easy because creating a poll and taking part is fast and self-explaining.

Good because it becomes clear, which options raise the most support and which raise the most resistance inside the group. This insight enables wiser decisions and more focused discussions.

Testing instance: moodpoll.uber.space/.

This repository is unmaintained.
Both of us maintainers have, after serious consideration, decided to not further pursue this project at this point in time. We do not have the resources at hand to maintain moodpoll, much less to add features. The testing instance linked above will stay online for the foreseeable future. If you are able to take over this project, please get in touch.

Challenge

A group of people wants to agree on some question with more than one possible option. Naively, anybody has one or more votes, and the option with the most votes is chosen. However, there are situations when this leads to suboptimal results, e.g. if two similar options "compete" for votes letting a third one win which objectively is not wanted by most people.

General Solution

In many situations "systemic consenting" (originally in german: "Systemisches Konsensieren") is a better principle. It tries to find the option which raises the least resistance inside the group, and not the one which has the biggest homogeneous subgroup of supporters. Unfortunately it is not yet well known and derserves some explanation.

Contribution of the App moodpoll

The app enables to create a poll within a few seconds. Just type in some text. Every new line is a new option. Users can then vote by using a range-slider and thus express a differentiated opinion between maximum rejection and maximum approval. The result is also differentiated: rejecting, neutral and supporting votes are displayed separately for each option. This allows the group to apply the decision scheme which fits best for the situation at hand. Having the concrete resistance values available, it is, however, much more intuitive to apply systemic consenting. It is not even necessary to explain it beforehand. It will probably explain itself. Once the method has proven useful, it can be introduced formally much easier.

Very Simple Example:

Say Alice, Bob and Carl want to agree when they meet. Available options are:

  1. Monday
  2. Tuesday

Alice and Bob have preferences for Monday and are indifferent for Tuesday. Carl prefers Tuesday and is not available on Monday.

Counting only positive votes, Monday would win but exclude one Person. However, Tuesday raises the the least resistance. It is OK for everyone.

While in this situation (few voters, few options) "ordinary communication" would perfectly work, such communication can become quite tedious. As time and willingness to communicate constructively are precious resources, they should not be wasted.

Current status

The app is currently in minimum viable product-state. It should be applicable for the basic use case but obviously is not finished.

For planned but yet missing features see the list of issues