Continuity in components

Simonas Zilinskas

Is your feature request related to a problem? Please describe.

Currently when transitioning from “proposals” to “budgets” or to “accountability”, the cards lose their link with the proposers. Proposers lose the possibility to edit/contribute to the proposals, manage info on them, report on their progress, etc. This blocks a number of interesting behaviours in participatory budgeting and other types of participatory exercises.

Describe the solution you'd like
The solution would be to produce this continuity by tying the components more closely together and maintaining the permissions of project proposers. Tracability is a core feature of Decidim and it is lacking in this regard, so we would love to stat a debate on the solution and make it happen.

Funded by
Can be in-part or fully financed by clients of OSP. We received this demand many times so we could probably collect the necessary funds. However, if you'd like to make it happen faster by co-deving it or co-financing it - let us know and let’s do it all together.

Comment

Comment details

Best rated

Recent

Older

Most discussed

You are seeing a single comment

View all comments

Pauline Bessoles

10 months

In favor

I totally agree, the idea of this proposal would be to be more bottom up and to leave more options to the users, more than the admins: for example, be able to edit a proposal after it was answered, to be able to improve a proposal, or mbe able to modify a proposal after it was imported into another proposal component (and the author kept) 😁

Xabier

10 months Edited

Hi @Pops

In general more freedom to the participants is good, but I would like to understand better the use cases for this proposal. In general Decidim has to be sensitive to the conflict between particular participants and the administration. It is important to maintain the integrity of the proposals to guarantee the resolution of such conflicts. If the participant that created a proposal can modify it after it has been rejected... how can the admins trust the participants or how can other participants trust the author of the proposal that is falsely claiming her proposal was rejected in a non-justified manner? If the participant has changed the proposal after it has been accepted... how can the administration commit to build a road whose width or route can be modified by the original proponent?

There are a number of reasons behind the current architecture of changes, phases, new components, and traceabilities. I am sure it can be improved but we need to be careful. I still don't understand this proposal sufficiently well :(

Comment moderated on 07/03/2023 15:20

Thank you for your feedbacks @xabier!

I think the integrity of the proposals could be maintained in this case by the proposal versioning. The possibility to edit the proposal after it was answered wouldn't cancel the previous forms of the proposal.
In the use case I think about, it's an administration that wants users to enhance their proposals according to the feedbacks made by the administration. So a proposal can be rejected because it's lacking some information, the admin answers it by rejecting it and explaining why, so the user can improve it by editing it, so it can be accepted in another answer pool.
I find this use case very interesting because it allows users to learn to speak the language of the administration and to continuously improve their proposals.It makes the rejection less definitive.

I also agree with the problem you raise about accepted proposals that are modified after acceptance. Acceptance seems more definitive, as the administration should be taking action after it and the proposal shouldn't evolve anymore.

May be a solution could be to add a config that enables admins to allow users to edit their proposals after they were rejected?

Antti Hukkanen

9 months

I agree very much with @Pops. I think the versioning controls are enough to trace the changes in the proposals even if they are modified after an answer (accept/reject). Most of the times it's not even a "nice to have", it's more of a "must have" for the municipalities. The proposals can change during the process when workshops are arranged, etc. And also some proposals can be accepted conditionally and their content may need to be modified when this happens, even when the admins can include the conditions within the answer.

It has also always puzzled me that the administrators cannot edit the proposals sent by the participants. I understand the thinking is much different in South Europe than in the Nordics regarding this but this has been a constant pain point as long as we've used Decidim. Therefore, it has even led us developing completely other tools to manage the idea/proposal collection to get around these limitations that the core system is posing on the administrators, i.e. making it impossible for them to perform their work.

I of course think of these issues from very technical perspective but I think the core purpose of Decidim should be to support participation and make the whole process easy on everyone. We should not concentrate on posing any imaginary limitations to administer the participation process. If the admins really want to mess up the process and break their accountability, nothing stops them modifying the content from the database. Decidim should be a flexible system that adapts to each organization's needs, not a system that poses unnecessary limitations to make the process difficult for everyone.

I understand the context where @xabier is coming from but many times it doesn't make much sense from our perspective. Sorry for the (never ending) rant about this topic, I hope this adds something valuable to the discussion as well.

Essential

Preferences

Analytics and statistics

Marketing

Continuity in components

Please log in

Cookie settings

Essential

Preferences

Analytics and statistics

Marketing

Continuity in components

Confirm

Please log in

Share