Help

A participatory process is a sequence of participatory activities (e.g. first filling out a survey, then making proposals, discussing them in face-to-face or virtual meetings, and finally prioritizing them) with the aim of defining and making a decision on a specific topic.

Examples of participatory processes are: a process of electing committee members (where candidatures are first presented, then debated and finally a candidacy is chosen), participatory budgets (where proposals are made, valued economically and voted on with the money available), a strategic planning process, the collaborative drafting of a regulation or norm, the design of an urban space or the production of a public policy plan.

Propose new features

Designing Decidim together

About this process

Take part in this process to design Decidim democratically: you can enter and create debates or propose new features or improvements (please don't use this process to report bugs).

Who can propose improvements to Decidim?

Any member of the community can make a proposal for a new feature or the improvement of an existing one.

Proposals can receive endorsements, although these are not decisive for a proposal to be included on the roadmap. The endorsements serve as indicators of the interest of the proposal or the need it covers. The comments to the proposals are also enabled, to collectively elaborate the initial idea and bring it to a productive result.

We always encourage discussion of features and direction for current and future versions of Decidim, within the following guidelines:

A little discussion is great. However, we try to avoid having too much discussion in favor of Try it first.
In the event that there isn’t any kind of real consensus in the discussion, or significant disagreement among a minority in the discussion, the Product team reserves the right to make arbitrarily binding decisions and move forward.
In the case where it’s kind of a UI or design thing where there’s no way to have a solution that can satisfy everyone, our philosophy is:
Do the simple / clean thing whenever possible
Gather basic feedback
Try it for a while – live with it
Adjust it over time based on feedback from living with it
We reserve the right to be wrong about any of those binding decisions and revisit them at some later date.
We don't want to overload Decidim with numerous complex settings; our preference is to supply sensible default configurations which are suitable for nearly all contexts, and that can be adjusted if needed. Nonetheless, in a few distinct cases the requirements are so varied that a new setting must be implemented. This approach should only be used as a final option.
Decidim is free and open source software! Test the change you want to see, via your own module first, and then share with the community how it went.

How do we decide the acceptance of new features?

The Product team reviews new proposals on a weekly basis that have been published the previous week. In order to decide whether a proposal is accepted we ask ourselves the following questions:

Is this sufficiently well-defined?
How many different Decidim instances are complaining / asking about this?
What is the community composition of those Decidim instances? Large, small, institutional, specialist, generalist, cranky (we dislike change), progressive (we love change)? How active is the instance? Is it a massive bustling city with big city problems, or a small village?
How strongly does the team feel this would help many (or all) other Decidim instances?
How in tune with the Decidim Social Contract is this feature? Example: a priori moderation, very much not in tune; improve traceability between components, in tune.
What discussion has there been about this, if any, here on Metadecidim?
Does it have funding? This sponsor will be responsible for finding and providing the economic resources to carry out its development. In this sense, sponsors can be: public institutions, companies or members of the developer community, associations, collectives, etc.

This is ranked from strongest (1) to weakest (7). The more we see the higher numbers the more that particular thing is prioritized.

Once a proposal is accepted to be included in the backlog, there is a follow-up in the evolution of the development through different stages until it reaches the production stage. The monitoring of ongoing developments is done on 2 different but complementary platforms. One is the Metadecidim community through this same space (check out the Feature Requests Monitor tab). The other is the GitHub platform, the developers meeting space. To maintain traceability and connection of communities to each "result" the corresponding GitHub issue is linked, and vice versa.

Once the development of a new feature is finished, it is included in the next release and communicated to the community.

(click to enlarge image)

How do we elaborate the roadmap?

Despite that most of the features defined in the original roadmap have already been developed and Decidim is a mature software, improvement proposals are selected and prioritized every year.

The process is as follows:

The bulk of the development budget comes from the Barcelona City Council, which is normally allocated to specific improvements based on its planned participatory processes.
Once the scope of the contract(s) is defined (e.g., improvements to citizen initiatives), any submitted proposals from the community that might be related are reviewed for their inclusion as well.
A part of the budget is also set aside to reduce technical debt or refactors.
As Decidim is a free software project and open to collaboration, the roadmap is completed throughout the year with contributions from other organizations.

The Decidim development model: a little context

Since its inception, the development of the platform has been subject to three tensions:

Meeting the needs and schedules of the Barcelona City Council's participation processes, which often require thinking, designing and programming the application at the pace of the participation processes themselves, in a model of "extreme programming" (XP, Extreme Programming).
Open the development process itself to other citizens, other social agents and other municipalities and organizations in order to collaborate in a model that could be defined as "participatory programming".
To adapt the development system to the possibilities and procedures of public procurement, to facilitate its extension.

Finding the balance between these poles has proved extraordinarily difficult. Decidim is no longer the "Barcelona participation platform" but a framework for the democratic governance of any type of organization. However, to date, 90% of the development resources still come from City Council budget, through external public contracts. The goal is for the Decidim Association to have a well funded and stable technical team to deal with the scale leap that the project has taken.

Since the first development plan (2017-2018), both the software features and the community members have grown dramatically in numbers. And from 2019 the code governance is distributed, thanks to the agreement signed between the City Council, the Decidim Association and the Localret Consortium (link to the English translation coming soon). These three entities compose the Product team, as they are responsible for taking care of the code.