Propose new functionalities for Decidim software
#DecidimRoadmap Designing Decidim together
Unfortunately the debate functionality uses plural voting only. The plan is to develop a module which uses the nominees gathered with the debate module, and conduct condorcet voting on them. The sortitions module have some similar functionalities, so modifying it is a possible way to go.
Report inappropriate content
Is this content inappropriate?
19 comments
Conversation with Xabier
This is a very nice proposal for improving Decidim. Condorcet method is very good. @mcsaba do you know how to implement? I mean at the level of interface and desing (UX).
Thanks! We also think, that using Condorcet the whole voting results can reflect better the common best. We have a team, but not very strong currently on the ux level. However, we can try to raise some interest around it.
This is really great. I think we should ask @carol and @andres if they are ok with this (which I am pretty sure they will) and see how we can help from here or github. There are quite many aspects to be discussed first. For example:
Do we want this to be a feature of process, assemblies or consultations? or all? Depending on the answer the behaviour might be different.
If I am correct the Condorcet works best with a limited number of candidates, is this correct? how many?
We already have an interface to vote in Consultations, so maybe we can re-use it at the UX-desing level. Would that be sufficient?
I figure that this would be a process component depending on the proposals module, in a similar way like the sortitions module does. People would gather the proposals, and the winning proposals would be used by the condorcet module. This way the whole Debian Resolution Process could be supported.
Yes, it is UX-wise cumbersome to vote for a lot of candidates in a preferential method. The limit depends on personal taste, I would say that it is somewhere around 5-10. This is one reason to dependon the proposals module: the proposal threshold can help to filter out irrelevant alternatives. This can be augmented with a logic which includes only the N alternatives with the highest number of proposals.
And you can use a type of cumulative UI for Condorcet, along these lines:
Likes | Candidate name | Dislike
O O O| Candidate name1|O
O O O| Candidate name2|O
O O O| Candidate name3|O
O O O| Candidate name4|O
You can place at most 6 likes and one dislike.
This can be tallied w/ Condorcet
In terms of user interface we are thinking about something similar to that of civs: https://civs.cs.cornell.edu/
The problem right now is lack of knowledge of rails and decidim internals. I could not figure out how to run the unit tests just for the sortitions module (if any. if none, then to create one).
Well it all looks quite sophisticated and complex. We should define and MVP and really think how to implement it at the level of architecture, and work the interface in parallel. The problem is that we don't have the resources to develop this feature and you don't have the knowledge! I am not sure what we can do ... Unless you have the economic resources to pay some of the developers that can do the job or you have the time to learn... On the side of the Decidim team this is a desirable feature but not a priority right now, unfortunately.
I am regarded as an experienced programmer. I have made my first kernel patch some 18 years ago, and fluently speak at least five programming languages. I am just new to rails and internals of Decidim.
I believe that onboarding help may be actually your interest, and improving on that field helps your velocity a lot in the long run.
If I could get to the point where I can clone the sortitions module in another name, run its test, and create one or two unit tests for it (as I see you do only high level integration tests), then I could handle most things for myself, and only had an occasional question from time to time.
When I mentioned CIVS, I was talking about its voting UI specifically. It is not that complex. The MVP would just provide a voting UI based on the proposals gathered in the proposals module, gather the votes, and when the vote is closed it would compute and show the result.
@magwas that's great. I just feel frustrated because I cannot help you technically. I am not a developer. The MVP you suggest seems great to me. Not sure how to handle both a more detailed definition of the module and the technical support you might need. I guess both @andres and the developer community at gitter might be able to help: https://gitter.im/decidim/decidim
Certainly being an experienced developer is of much more value than anything else. I am sure once being an experienced developer you can learn Rails and the Decidim internals pretty fast.
Hi! At the moment we don't have any financing for these kind of features. We're closing the roadmap for 2019/2020 and the idea is to stabilize/fix bugs/improve on UX based on what we have right now. We're hoping to publish the roadmap on the next few weeks.
On the other hand, Decidim has a modular design, and we're always welcoming new modules that could extend the present features and introduce new ones.
Conversation with Csaba Madarász
Hi! So in this case, do you have an already implemented way of promoting possible developments beside the roadmap? I have an assumption, that decidim could be itself a good platform to manage this - even to raise the issue in members through a process, and to find partners for certain, out of the roadmap possible features and functions. Maybe I am wrong, but looking for your input.
Hi @mcsaba!
Yes, in fact this process is the space to propose, discuss and agree on new developments (also to find possible partners). What makes them become part of the roadmap is basically that they have funding (and the review by the Product team).
Exactly. Different institutions and developers make here suggestion so as to how to improve Decidim. These are latter moved to Github for production.
Hi all,
We may be able to find some financement to improve the vote counting in consultations.
Our idea is to find a group of organizations that partner together to finance the developments in a common effort.
Maybe we can do a deeper analysis of what are the different existing vote counting algoriths, see where they can be applied and look for a transversal solution along all components with this need.
I think that the only affected components are Consultations/Questions and Proposals. I'm discarding comments but I'm not sure. Any other?
At Open Source Politics we also face these kind of demands : preferential voting, majority judgement voting. @lucas_hamani is currently exploring these possibilities maybe he can share more
I would love to hear anything about it @lucas_hamani
@mcsaba
We haven't done much yet since our clients requests are about very different use cases from one another.
So far we focused on introducing preferential voting within the budget component through a module of ours which is "Vote per project". We haven't had the chance to send this module to the master. I hope we'll correct that really really soon.
Our "Vote per project" enables the admin to shift the participant focus on the projects rather than the budget allocated to them when voting for a participatory budget. It works the following way :
Participants are asked to vote for a number projects of his choosing regardless of the budget allocated to them. The number of projects to be selected is set by the admin in the budget component back office.
Once the vote is closed, the winning projects are all the projects the most voted for within the total budget limit.
The other advantage of this vote method being it that it is much simpler to enact offline simultaneously. It is much easier for a participant to choose any number of projects among many rather than do some maths to make sure the projects he chose are within the budget limit.
Unfortunately I can't direct you to a live example since none of our clients doing a participatory budget are in the voting phase.
To introduce preferential voting through this module, we thought about adding a weight to each projects selected by a participant according to the order he selected them. The first project selected being the most wanted by the participant, the fifth one being the least wanted by the participant among his choices.
I maintain an open source library which implements the shulze voting algorithm: https://github.com/coorasse/schulze-vote. This might be useful since also decidim is in ruby. The library is already used in Agreeder (https://agreeder.com/) and Airesis (https://airesis.eu/)
Add your comment
Sign in with your account or sign up to add your comment.
Loading comments ...