Propose new functionalities for Decidim software
#DecidimRoadmap Designing Decidim together
Most of organizations / NGOs / cooperatives that use Decidim don't need the *budgets* module, and most of the installations don't use the *sortitions* module.
They should be commented by default, as we do with *conferences* / *initaitives* / *consultations*.
Report inappropriate content
Is this content inappropriate?
8 comments
Conversation with Pau Parals
I think we lose more of what we gain. While I find it right that certain participatory spaces are not enabled (different needs) the components are the ones that give us game. It may be an administrator decides to disable budgets, and another colleague will find it useful in a particular process.
Is there a real need?
Maybe it wasn't that clear on my proposal, or that it's easier to understand by seeing the Gemfile, but with this change this modules (sortitions and budgets) will be like other modules that we have with this dynamic (consultations / initiatives). For instance: https://github.com/decidim/metadecidim/blob/e3cfcbf5ed0ffadeae81ef4094ac8887136a405b/Gemfile#L10
Regarding the need, the aim is to have a leaner default installation.
Thanks @andres to answer. I understand what are you proposing but i'm not sure if is the best option. I don't see a real need to disable the two components. For me, the mechanisms of participation can always be combined in one way or another within a participatory space. I understand that there are organizations that dn't have the need to have certain participatory spaces, but I don't see the need to disable components. However, I understand your argument to make a simple default installation.
I agree with the proposal. Being Decidim a modular software, the aim would be to go towards a minimum core that is fully functional, but that facilitates the task of installing a new instance. Besides, the expectation is to have more modules (some official and others not). It is also important to document and catalogue each of these modules.
Conversation with Oliver Valls
I find that one of the strenghts of Decidim vs other platforms is its amount of features and flexibility. If we start disabling modules by default the platform may loose its powers. We can always enable it on request, but administrators will have it harder to know this features.
As @carol says, if we disable by default we'll have to have them very documented. Maybe a new section in the Administration panel "Oficial extensions" that has the only aim to document what is officially suported but disable by default?
I agree with the discoverability issue that this change adds. Regarding docs, we should add this new section on the README (where there's all the modules listing), and also add it on the checklist.
Conversation with Ivan Vergés
I would be in favor of letting the admins choose what is active or not. This is specially relevant in multi-tenant sites, currently if you activate Initiatives (for example) all multi-tenant sites have it active whether they want it or not in that specific site. If the admin could activate or not that part in some sort of "advanced settings", or even in the system superadmin, that would be a good compromise in my opinion.
I think this would be the ideal solution, a panel with modules that can be activated (like Wordpress or Discourse), although is out of the scope of this proposal, as it's lots of work and very different comparing with what we have now.
Add your comment
Sign in with your account or sign up to add your comment.
Loading comments ...