This document is focused on the decision making process to add new features in Decidim. It does not cover other technical governance aspects, like: decision making regarding technical changes (use this dependency over another one). bug priorisations. roles in the github (maintainers, reviewers, etc.)

Technological governance process in Decidim is designed on a participatory cycle, where we define:

1. Strategic Direction:  Orientation for the Decidim product development and maintenance roadmap during the year.

2. Features and Activities: With the annual strategy in mind, we will decide at least once a year on the features and activities the Decidim Association should focus on. It will substitute the current “Add a Feature” process, which will be archived. 

The bi-annual participatory process to establish strategic priorities. It is initiated by the Technical Office, who has a broader perspective on Decidim strategies and objectives.

Anyone registered on Metadecidim can participate in the participatory process, designed in a very standard way:

1. prepare: Technical office will propose 3-10 strategic priorities and open the proposal phase.

2. propose: Any registered Metadecidim user can propose additional strategic priorities. The ”proposal” phase is at least 2 weeks.

3. vote: Only members of the Decidim Association can vote on proposals. Each user has up to 5 votes to distribute.

4. decide: based on the results of the voting phase, the Technical Office will select the strategic priorities for the upcoming year and publish it in the results section on Metadecidim.  [illustration1]

Accountabilities:

Technical office (TO) MUST start a Direction Participatory Process at the beginning of the year, every two years.
TO SHOULD propose 3-10 proposals before opening the participatory process.
TO MUST select less than 10 strategic priorities for the upcoming year.
Association Members SHOULD take part in the proposal and vote phases.
Association Members MUST acknowledge the published result.

The prioritization process for features will be run by the Product Team, with the help of the Decidim Partners and other registered Metadecidim users. For this purpose, all Decidim Partners are requested to dedicate at least 5 staff hours annually to contribute to this process as outlined below. 

1/ Product Team opens the process. Metadecidim users will propose up to 2 proposals per user. Only two proposals may be submitted by members of the same organization. Each proposal may suggest a new feature to be developed by the Decidim Association OR the adoption of an existing feature/module into the Association’s ongoing maintenance responsibilities.

2/ Once a proposal is published, Decidim Partners will dedicate time to refine the proposal: asking clarifications, giving suggestions of changes to ease the production. 

3/ The Product Team evaluates each proposal and assigns an estimated implementation cost in development hours. The Product Team may split proposals or merge proposals to be able to evaluate costs. Once costs are published, each participant can vote among preferred proposals.

4/ Proposals that receive at least 10 votes are considered for implementation.

5/ Once the strategic priorities are selected and published by the Product Team, the implementation process follows these steps:

• Conversion to issues and coordination with development teams: Each selected proposal is transformed into a draft document on GitHub to refine the definition and design. During this phase, a development company and a funder organization are assigned to the proposal. Once the draft is approved, it is converted into one or more GitHub issues. The Product Team coordinates with development teams to ensure a clear implementation timeline.




• Updating proposals on Metadecidim: As issues are worked on and closed, the related proposals on Metadecidim are updated by the Product Team. Pull Requests (PRs) are linked in the comments to provide transparency on development progress.




• Next release acknowledgments: During the release cycle, the contributions of designers, developers, translators, and funding organizations are recognized in official communications, ensuring visibility and appreciation for their work.

6/ Before the beginning of a next cycle the product team publish a post with a follow up.

[Illustration2]

Accountabilities:

Product Team (PT) MUST run a feature participatory budget at least once a year.
PT MAY run a feature participatory budget many times a year. 
PT MUST evaluate the cost of proposals in a timely manner, ideally in less than two weeks. 
PT MUST publish progress of the selected proposals at least 2 weeks before starting a new participatory budget.
Association Members SHOULD take into account the chosen strategic directions when proposing and ranking new features and adoption of existing assets into the core.
Decidim Partner MUST spend at least 5 staff hours to ask questions and try to improve proposals during the “propose” phase.

Communicating on a new release can be challenging. In order to keep the community in sync with the production of a new release, the process of release communication will be as follows:
- Product Team will select with Technical office up to 5 high-value features from among the proposals to be produced.
- Technical Office will actively communicate to the community when one of these 5 high-value features moves forward in production.
- 2 weeks before an official Decidim release, Technical Office will publish in the Translator Element Channel a message to translators announcing the release.

Accountabilities:

Technical Office (TO) MUST select 1 to 5 high-values with the Product Team after a feature participatory budget selection. 
TO MUST publish in Translator Element Channel an invitation to translate an upcoming release with a 2 weeks window before publication. 
TO MUST publish updates on General Room in Element when one high–value feature will start development, and when one high-value feature is ready. 

Adding new components or new spaces add a non-negligible maintenance to the Decidim Product Team. These kinds of feature requests are thus limited, to keep a well-maintained product.

Restrictions. New Decidim Components MUST live outside the main decidim/decidim repository for at least 1 year before being a candidate to merge. ONLY Decidim Product Team, Association Members or Organizations Partners MAY propose merging components or participatory space.

Example. Decidim Product team wants to develop a new "Random Member Sortition" module. If it is selected through the Participatory Budgeting, the module will live in a decidim/decidim-member-sortitions (hosted outside decidim/decidim) for a year. Once it has been used and can demonstrate it is useful, the module can be a candidate to join others decidim/decidim modules.