Skip to content

Commit

Permalink
New translations general-description.adoc (French)
Browse files Browse the repository at this point in the history
  • Loading branch information
decidim-bot committed Mar 6, 2024
1 parent 8ff9f78 commit bb213b7
Showing 1 changed file with 63 additions and 0 deletions.
63 changes: 63 additions & 0 deletions docs/fr/modules/features/pages/general-description.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,63 @@
= General description and introduction to how Decidim works
:page-partial:

http://decidim.org[Decidim], from the Catalan for "let's decide", is a digital infrastructure for participatory democracy, built entirely and collaboratively as free software. More specifically, Decidim is a web environment (a _framework_) produced in _Ruby on Rails_ that allows users to create and configure a website platform or portal, to be used in the form of a social network, for democratic participation. The portal allows any organization (local city council, association, university, NGO,trade union, neighborhood or cooperative) to create massive democratic processes for strategic planning, participatory budgeting, collaborative regulatory design, urban spaces design and elections. It also enables the organization of in-person meetings, signing up for them, the publication of minutes, proposing points for the agenda and receiving notifications of the results. Decidim can also help organizing governing bodies, councils or assemblies, the convening of consultations and referendums or channeling citizen or member initiatives to impact different decision making processes. All together Decidim makes possible to digitally structure a complete system of participatory democratic governance for any organization.

To understand in detail how Decidim operates, a distinction must be made between participatory _spaces_ and _components_ (see <<functional-architecture-fig>>).

[#functional-architecture-fig]
._Summary diagram of Decidim's functional architecture showing a combination of components in participatory spaces. The "Vote*" component allows a variety of voting systems, expressions of support or allegiance for a proposal._
image::functional-architecture-en.svg[width=2000]

* *Participatory spaces.* These are the frameworks that define how participation will be carried out, the _channels_ or means through which citizens or members of an organization can process requests or coordinate proposals and make decisions. _Initiatives_, _Processes_, _Assemblies_ and _Consultations are all participatory spaces. Specific examples of each of these include: a citizen initiative for directly changing a regulation (_Initiative_); a general assembly or workers’ council (_Assembly_); a participatory budgeting, strategic planning, or electoral process (_Processes_); a referendum or a call to vote “Yes” or “No” to change the name of an organization (_Consultation_).
* *Participatory components.* These are the participatory _mechanisms_ that allow a series of operations and interactions between the platform users within each of the participatory spaces. The following are participatory components: _comments, proposals, amendments, votes, results, debates, surveys, sortitions, pages, blogs, newsletters_ and _meetings_. Other components that build on top of basic components are: _participatory texts_, _accountability_ and _conferences_.
[#spaces-components-fig]
._Decidim displays participatory spaces on the top menu (dark) and components are displayed on the bottom menu (white)._
image::spaces-components.png[]

The ways in which spaces and components interact is the following. Users of the platform (participants) interact through participatory mechanisms known as components which afford a variety of features for the various participatory _spaces_. In other words, participatory _spaces_ such as _Initiatives_, _Assemblies_, _Processes_ and _Consultations_ have components at their disposal which work together as participatory mechanisms. The more notable components include in-person _meetings_, _surveys_, _proposals_, _debates_, _results_ and _comments_. So, for example, the various phases of a participatory budgeting process can combine components in the following way: at an early phase public meetings can be opened for citizens to analyze different needs classified by districts. In turn these meetings can lead to the design of a survey. The survey results can then be used to define a set of categories for projects to be proposed. The proposal component can then be activated for participants to create and publish their projects as solutions to the identified needs. These proposals can then be commented and, after two weeks of deliberation, voting can be activated to select among the projects with a budget-expenditure system. Participants can then be called to a public meeting to evaluate the results, and an assessment survey can be launched afterwards for those who could not attend the meeting. Finally, the accountability component may be activated to monitor the degree of execution of the selected projects, and people can comment on it. What makes Decidim particularly powerful is this combination of components within spaces, which provides an organization with a complete toolkit to easily design and deploy a democratic system and adapt it to the organization's needs.

Decidim's top navigation bar displays the different types of active *spaces* of the platform. *Processes* is a space that allows to create, activate/deactivate, and manage various participatory processes. These are distinguished from other spaces by being structured in different phases within which all of the components can be incorporated. Examples of participatory processes are: an election process for members of a committee, participatory budgeting, a strategic planning process, the collaborative writing of a regulation or norm, the design of an urban space or the production of a public policy plan. *Assemblies* is a space that offers the possibility of setting decision-making bodies or groups (councils, working groups, committees, etc.) that meet up periodically, detailing their composition, listing and geolocating their meetings, and allowing to take part in them (for instance: attending if the seating capacity and nature of the assembly so permits, adding items to the agenda, or commenting on the proposals and decisions taken by that body). *Consultations* is a space that makes it possible to coordinate referendums, trigger discussions and debates, get voting results published; it can be connected to a secure e-voting system. *Initiatives* is a space that allows participants to collaboratively create initiatives, define their trajectory and goals, gather endorsements, discuss, debate and disseminate initiatives and define meeting points where signatures can be collected from attendees or debates opened to other members of the organization. Initiatives is a special kind of space by which members of the organization can trigger actions that are generally restricted to elected bodies or platform administrators, by collecting (digital) signatures. The organization can define the types of initiatives and set up the number of signatures that are required to trigger the expected result (e.g. to call for a consultation).

The *components* (also called features) are displayed as a second level menu with white background within spaces (as displayed in <<spaces-components-fig>>). The *collaborative draft* for proposals facilitates the collaborative creation of proposals as well as the monitoring and control of changes throughout the process. The *proposals* component allows a user to create a proposal using a creation wizard, compare it with existing ones, publish it in the platform and include additional information like geolocation or attached documents and images. This component also makes possible to navigate, filter and interact with a set of proposals. The proposal component has plenty of configuration options, and different features can be activated or de-activated in time. One such feature is *voting* or *support*: it offers organizations the possibility of activating different voting or support systems around proposals: unlimited, limited to a given threshold, weighted, cost-based, etc. Proposals can also be imported to a new phase, so they can be re-written or elaborated in different stages, where they can also be subject to *amends* which can be voted separately, accepted and merged or rejected, to improve proposals democratically. The *results* component is used to turn proposals into results and give official responses concerning their acceptance or rejection, merging various proposals into a single result or creating different results related to the same original proposal. The *accountability* component offers the possibility of subdividing results into projects, defining and applying progress statuses around their implementation, as well as displaying the extent of the results’ implementation grouped by categories and scopes. In this sense the accountability component works like a project management system built into the platform. The *surveys* component can be used to design and publish surveys and to display and download their results. The *sortition* component allows to select a number of proposals (e.g. candidates for a jury) with random, yet reproducible, procedures that guarantees non-biased and uniform distributions. The *comments* component enables users to add comments, to identify the comment as being in favor, against or neutral in relation to the commented object, to vote comments, respond to them and to receive notifications about responses. The *participatory texts* component can be used to convert lengthy text documents into various proposals or results and, vice versa, to compose and display a unified text based on a collection of proposals or results. This makes possible to work with a full document as continuous text in participatory manner. The *pages* component is used to create informative pages with rich text formatting, embedded pictures and videos. The *blog* component makes possible the creation of posts or news, and to navigate them chronologically. The *meeting* component offers organizations and participants the opportunity to convene meetings, determine their location and time, registration and management of attendees, to define the structure and content of the meeting as well as publishing the minutes, and the resulting proposals. The *conference* component allows an organization to create a website for a big event by joining up a series predefined meetings (chats, workshops etc.), putting together a unified program and managing attendees. The *newsletter* component makes possible to send emails to everyone registered in the platform or, more selectively, to those who participate in a specific space.

Participants can carry on different *types of actions* within the platform:

[start=0]
. They can *navigate* and search for information
. They can *create* contents of different types (e.g. proposals and debates).
. They can *vote, support or sign* all three modes allow for participants to aggregate their preference or will for a specific consultation question, proposal or initiative respectively (the difference between these three types of actions involve different levels of security and anonymity: signatures can be audited and attributed to a participant, supports cannot, in order to prevent coercion, while votes involve higher cryptographic guarantees than supports).
. They can *comment* on any object of the platform (proposals, debates, results, sortitions, etc.).
. They can *endorse* any content, meaning that they can publicly declare they support it or find it relevant, with the participants following it then receiving notifications.
. They can *follow* other participants, a participatory process, an initiative, a specific proposal, etc. and receive notifications.
. They can *sign up* for a meeting.
. They can also *share* and *embed* content out of the platform, sharing the link to other social networks and embedding content on other sites.

Component items (e.g. a proposal, a blog post, a meeting) have their individual page but are also displayed as *cards* throughout the platform, cards being a major design interface to interact with components. <<card-anatomy-fig>> displays a proposal card with the different types of data and interactions identified within the card.

[#card-anatomy-fig]
._Decidim's proposal card anatomy._
image::card-anatomy.png[]

The users who participate in Decidim can be grouped into three different categories:

* *Visitors* have access to all of the platform's content without having to sign up or provide any information.
* *Registered* participants can create content and comments, sign-up for meetings, endorse content, follow other participants and objects of the platform, customize their profile and receive notifications, mentions and private messages. By choosing a username and password, accepting the user agreement, and providing an email account (or using an account for several social networks) participants become registered. Registered participants can also have their account officialized (meaning their username is accompanied by a special symbol indicating they really are who they claim they are on their profile).
* *Verified* participants can make decisions. In order to fall under this category they must first be verified as members of the organization, citizens of the municipality, or constituents of the decision-making group (an association, community, collective etc.). Decidim offers different ways to carry out this verification. Once verified, participants will be able to take decisions by supporting proposals, signing initiatives and voting in consultations.
Administrators can *manage permissions* for registered or verified users selectively. For example proposal creation can be activated for both registered and verified users but supports to proposals only for verified users. It is also possible (although rarely recommended) to consider all registered users as verified and to grant them decision making powers.

There are different types of administrators: *administrators* of the whole platform or of specific spaces and components, they can also be *moderators* (with the exclusive power of moderating proposals, comments or debates) or *collaborators* that can read unpublished content, create notes and responses to proposals.

Participants can register as an *individual* or as a *collective* (associations, working groups, etc. within the main organization). User *groups* might also be created so that individuals can be associated to a *group*. Decidim allows participants belonging to such a group to express or act individually or embodying the group identity: when an action is carried the platform prompts the participant to choose wether they want to act as themselves or as the group they belong to.

Participants can not only navigate the content of Decidim through the top menu and move down the architectural hierarchy, from a space to its different components; they can also get information through the *search engine*, or via *notifications*. Participants can also talk to each other by internal messaging or *chat*.

The participant's *profile* makes possible to read notifications, manage followers, and monitor different gamification and engagement badges.

The *home page* of the platform is fully customizable: it can display different types of banners, call-to-action buttons, it can also display statistics and interactive visualizations, activity streams, and maps with the upcoming meetings.

The content of the platform can be classified by different criteria. A participatory space and its contents (e.g. a participatory process or the proposals within) can be (independently) assigned a *scope*. Scopes are defined for the whole platform, and they can be thematic or territorial (for example, an assembly can be assigned to a specific theme or subject, like "ecology", and to a specific territory, like a district within a city). Content within a space-instance can be assigned to a *category* or sub-category (e.g. topics) that are specific for such a space-instance. For example, the categories "sport facilities", "parks" and "schools" can be created for a participatory budgeting process, and proposals will be assigned to these categories. *Hashtags* can also be freely created and introduced in the body text almost anywhere in the platform (proposals, debates, comments, process description, etc), both by participants and administrators, to classify content and make it searchable.

Unlike other existing platforms, Decidim’s architecture is *modular*, *scalable*, easy to *configure*, and *integrated* with other tools or apps (data analysis, maps, SMS, mail, social networks, etc.). The platform has been designed in such a way that processes, assemblies and mechanisms can be set up easily and deployed from an administration panel. No knowledge of programming is required to install, configure and activate it. The participatory spaces and components can be developed, activated and deactivated independently.

0 comments on commit bb213b7

Please sign in to comment.