Feature toggle

[oliverbarnes]

Currently when our module is added liquidvoting overrides every instance of each voting method it's integrated with (at this point only participatory process proposal supports).

In order to allow for partial adoption (eg: smaller scale pilots within a larger instance), admins should be able to choose where to activate liquidvoting, piecemeal.

I'm thinking of a feature toggle on the overriden modules' admin interface, like Marc had suggested, rather than having an admin for liquidvoting itself - this way we bypass the overhead of componentizing the module.

[davefrey]

This also makes me think of the hypothetical case of adding the Liquidvoting module to an existing Decidim instance: any proposals that exist and have votes will need to be converted if/when an admin enables LV for that component –– like generate a LV vote for each existing Decidim vote. It might be straightforward to migrate back to Decidim voting later if they wanted to disable, that would be polite/good manners I think.

I agree with your toggle proposal. The decidim_components.settings json field has entries per participatory space and manifest (e.g. proposals, budgets, etc, and so I think the data model supports what we want. We were to piggyback on Proposal component (and then hopefully all the LV-able things have an associated component).

I can imagine two other scenarios: enabling LV per proposal rather than space+proposal (etc for budgets, ...), or enabling by default across the instance; they seem secondary but we might consider those.

[oliverbarnes]

This also makes me think of the hypothetical case of adding the Liquidvoting module to an existing Decidim instance: any proposals that exist and have votes will need to be converted if/when an admin enables LV for that component

That's you great you brought this up, the decidim.barcelona is a concrete case where this might happen. But my instinct would be we shouldn't touch closed and ongoing participatory processes, which started out non-liquid, and our module should only work for pristine ones.

I can imagine two other scenarios: enabling LV per proposal rather than space+proposal (etc for budgets, ...),

When would that be the case, could you give an example?

or enabling by default across the instance

true - which is pretty much what the module does now, for process proposals at least. Not sure how we'd go about this one - I suppose we'd need a global toggle, but then that would have to interact with the per-process toggle, for example.

In the end the scenario I'm foreseeing for the first iteration for this toggle is:

Admin for existing instance chooses to add liquidvoting a new process about to begin

And we should keep it as simple as possible.

[davefrey]

we shouldn't touch closed and ongoing participatory processes, which started out non-liquid, and our module should only work for pristine ones.

Agree. I don't see the details well enough yet to know if there is some nuance in there, or a PP decision that will be hard to generalize outside of process proposals, but already it's helpful to have an approach (don't LV-touch things that are closed or started), and then react to specifics as we encounter them.

When would that be the case, could you give an example?

Running a smaller experiment; idk if it's a real case, imagine an instance that does a lot of process proposals, and that instance wants to run a test while not (yet) affecting other day-to-day proposals.

I think this will get clearer, for me at least, when we're implementing...I still don't have a solid grasp of the workflows. In the abstract it's easy for me to see all these levels of LV on/off, and more, in the appropriate admin settings and create views:

• decidim_components.settings - existing json hash
• decidim_participatory_processes.liquidvoting_enabled - a flag, doesn't exist yet, captured when creating a process
• decidim_proposals_proposal.liquidvoting_enabled - a flag, doesn't exist yet, captured when creating a proposal, or perhaps it's defaulted and can be overridden by an admin in a later step

and it's easy to put the "render LV stuff?" decision in a view helper method.

But to be honest, this little exercise just raises more questions for me about when and where we make the "enable LV?" decisions...we should mob on it.

A global LV on/off definitely feels like something we can ignore for now, and wait until an admin wants the convenience.

[jinjagit]

I agree with the general plan here.

1. Toggle in proposal component settings when adding to a process / assembly / p. budget / etc. (available to toggle until component is published, but not beyond - I guess this is the best cut off point)
2. Maybe add more granular (per proposal), or more general (global), toggles, at a later date, if need arises. But this does not seem urgent.