decidim 0.27.7 → 0.28.0.rc4

data/docs/modules/develop/pages/maintainers/security.adoc

@@ -0,0 +1,52 @@
+= Security
+
+This page provides an overview of the security procedures followed by the Maintainers when handling security issues. For information on our security policy, see https://github.com/decidim/decidim/blob/develop/SECURITY.md[Decidim Security Policy].
+
+. Security issues can be received by email or by the https://github.com/decidim/decidim/security/advisories/new[GitHub Security Advisories] feature.
+. We will open a GitHub Security Advisory with:
+.. an explanation of the issue, without giving much details about the vulnerability.
+.. the metadata necessary, such as affected releases and severity.
+.. we will not give a step by step explanation on how to exploit the vulnerability.
+. The issue will be handled privately (on a private fork) until a fix is ready.
+. Once the fix is ready, we will open a PR to the `develop` branch with the fix.
+. We will do the backports to the https://github.com/decidim/decidim/blob/develop/SECURITY.md[supported versions].
+. We will release a new version with the fix.
+. On the Release Notes of the versions with the fix, we will add a note about the vulnerability with a reference to the CVE or the GitHub Security Advisory ID if there is not any ID. See below the `Template for the Release Notes`.
+. We will send a notification to the Decidim Devs Matrix chat room. We will not mention the vulnerability, just that there is a new version with a security fix. See below the `Template for the Decidim Devs chat room message`
+. We will wait the grace period (2 or 4 months depending on the severity) before disclosing the vulnerability.
+. After the grace period, we will publish the Security Advisory.
+
+== Template for the Release Notes
+
+[source,markdown]
+----
+## Security fixes
+
+This release addresses several security issues, including the following:
+
+* CVE-20XXX-XXX
+* CVE-20XXX-XXX
+
+The details regarding the security vulnerability will be published on XXX 2023, which is two months after the release date of this version. For more information, please refer to our [Security Policy](https://github.com/decidim/decidim/blob/develop/SECURITY.md).
+
+We highly recommend updating to this version as soon as possible to ensure the security of your system.
+----
+
+== Template for the Decidim Devs chat room message
+
+[source,markdown]
+----
+Hi everyone! On behalf of the Decidim Maintainers Team, I would like to share the following message:
+
+We want to inform you that there are new releases with some security vulnerabilities fixes, v0.XXX.XXX [0] and v0.XXX.XXX [1]. We strongly recommend that you plan to update your installations accordingly.
+
+As per our Security policy [2], we will publish information about these vulnerabilities on XXX.
+
+Regards,
+XXX
+(from the Decidim Maintainers Team)
+
+[0] https://github.com/decidim/decidim/releases/tag/v0.XXX.XXX
+[1] https://github.com/decidim/decidim/releases/tag/v0.XXX.XXX
+[2] https://github.com/decidim/decidim/blob/develop/SECURITY.md
+----

data/docs/modules/develop/pages/managing_translations_i18n.adoc

@@ -12,8 +12,7 @@ Decidim uses https://crowdin.com/[Crowdin] to manage the translations.
 
 * Setup the new language in https://crowdin.com/project/decidim[_Crowdin's Decidim project_] (or open an issue on Github asking an admin to do that).
 * Add the locale mapping in the `crowdin.yml` file
-* Translate at least one key from every engine, so, your _yaml_ files are not empty. The easiest way to do this is to automatically translate and sync all the content. Later you'll be able to fix the content that wasn't properly translated.
-* Add https://github.com/najlepsiwebdesigner/foundation-datepicker/tree/master/js/locales[Foundation Datepicker]'s translations (https://github.com/decidim/decidim/pull/2039[PR]).
+* Translate at least one key from every engine, so, your _yaml_ files are not empty. The easiest way to do this is to automatically translate and sync all the content. Later you will be able to fix the content that was not properly translated.
 * Add the new language to `available_locales` (https://github.com/decidim/decidim/pull/1991[PR]).
 * Add the language in https://github.com/decidim/decidim/pull/5080/files#diff-9c9dc1c8c25dcecdfb8ce555d5ef5e47R15[decidim-core/spec/lib/available_locales_spec.rb].
 

data/docs/modules/develop/pages/maps.adoc

@@ -185,8 +185,9 @@ module Decidim
           # the JavaScript asset which is used to initialize the geocoding
           # autocompletion functionality in the front-end:
           class Builder < Decidim::Map::Autocomplete::Builder
-            def javascript_snippets
-              template.javascript_pack_tag("decidim/geocoding/provider/your_provider")
+            def append_assets
+              template.append_stylesheet_pack_tag("decidim/geocoding/provider/your_provider")
+              template.append_javascript_pack_tag("decidim/geocoding/provider/your_provider")
             end
           end
         end
@@ -278,7 +279,7 @@ $(document).on("ready", () => {
     // => This would print out what you returned for the `callback` as shown
     // above.
 
-    // NOTE: YOU DON'T NEED THIS IF YOUR RESPONSE OBJECTS ALREADY CONTAINED THE
+    // NOTE: YOU DO NOT NEED THIS IF YOUR RESPONSE OBJECTS ALREADY CONTAINED THE
     //       COORDINATES IN THE `coordinates` KEY OF EACH RESULT OBJECT!
     // Then, once you know the coordinates, you trigger the following event on
     // the same input (obviously, you need to query the API first):
@@ -311,7 +312,7 @@ This is not 100% necessary but it improves the accuracy of the geocoding functio
 For the dynamic map functionality, you should primarily use a service provider that is compatible with the https://leafletjs.com/[Leaflet library] that ships with Decidim.
 You can also integrate to services that are not compatible with Leaflet but it will cause you more work and is not covered by this guide.
 
-Please note that you don't necessarily even need to create your own dynamic maps utility if your service provider is already compatible with the link:/decidim-core/lib/decidim/map/provider/dynamic_map/osm.rb[`Decidim::Map::Provider::DynamicMap::Osm`] provider.
+Please note that you do not necessarily even need to create your own dynamic maps utility if your service provider is already compatible with the link:/decidim-core/lib/decidim/map/provider/dynamic_map/osm.rb[`Decidim::Map::Provider::DynamicMap::Osm`] provider.
 In order to configure your custom OSM compatible service provider take a look at the xref:services:maps.adoc#configuring-open-street-maps-based-service-providers[maps and geocoding configuration] documentation.
 
 If your service provider is not fully compatible with the default OSM provider, you can start writing your customizations by creating an empty dynamic map provider utility with the following code:
@@ -434,8 +435,8 @@ By default, this will return a link to the configured static map URL with the fo
  ** `latitude` - The value for the `latitude` option provided for the method.
  ** `longitude` - The value for the `longitude` option provided for the method.
  ** `zoom` - The value for key `:zoom` in the options hash (default: 15).
- ** `width` - The value for key `:width` in the options hash (default: 120).
- ** `height` - The value for key `:height` in the options hash (default: 120).
+ ** `width` - The value for key `:width` in the options hash (default: 300).
+ ** `height` - The value for key `:height` in the options hash (default: 300).
 * `url_params(latitude:, longitude:, options: {})` - Returns a hash of prepared URL parameters for the `url` method.
 For the default parameters, see the explanations above for the `url` method.
 * `image_data(latitude:, longitude:, options: {})` - Does a request to the URL defined by the `url` method and returns the raw binary data in the response body of that request.
@@ -475,7 +476,7 @@ When calling the `url` method with the latitude of `1.123` and longitude of `2.4
 
 [source,bash]
 ----
-https://staticmap.example.org/?latitude=1.123&longitude=2.456&zoom=15&width=120&height=120&style=bright&foo=bar
+https://staticmap.example.org/?latitude=1.123&longitude=2.456&zoom=15&width=300&height=300&style=bright&foo=bar
 ----
 
 If you want to use the dynamic map replacements for the static map images, do not configure `static` section for your maps:
@@ -490,7 +491,7 @@ config.maps = {
 ----
 
 Even if you decide to use the dynamic map replacements, you will still need to define the static map utility because it is used to generate the link where users will be pointed at when they click the map image.
-In this case, the static map utility can be empty as you won't need any customization for it to work.
+In this case, the static map utility can be empty as you will not need any customization for it to work.
 
 == Configuring your own map service provider
 

data/docs/modules/develop/pages/metrics.adoc

@@ -104,11 +104,11 @@ Relations around `decidim_metrics` table:
        |     +----->+ ParticipatorySpace +<----+    +------------+
        |     |      |                    |     |    +-------------+
        |     |      +--------------------+     +----+ Initiatives |
-       |     |                                 |    +-------------+
-       |     |                                 |
-       |     |                                 |    +---------------+
- +-----+-------+---+                           +----+ Consultations |
- |                 |                                +---------------+
+       |     |                                      +-------------+
+       |     |
+       |     |
+ +-----+-------+---+
+ |                 |
  | decidim_metrics |
  |                 |
  +--------+--------+       +----------------+

data/docs/modules/develop/pages/modules.adoc

@@ -9,11 +9,11 @@ of them. Usually, there are two ways to do that:
 The first option is ideal to start hacking with your Decidim implementation but, if you want to create something that others
 can benefit, the best is to create a module in a gem of its own that can be installed anywhere.
 
-NOTE: There's also a third possibility and create a module that is in a sub-folder of the application itself. This approach
+NOTE: There is also a third possibility and create a module that is in a sub-folder of the application itself. This approach
 simplifies a little the integration with your app and facilitates a future extraction to a proper external gem. You can
 see some examples of this in the https://github.com/AjuntamentdeBarcelona/decidim-barcelona/tree/master/decidim-census_sms?rgh-link-date=2021-07-23T09%3A19%3A08Z[Ajuntament of Barcelona]
 in the folders `decidim-census_sms`, `decidim-dataviz`, `decidim-ephemeral_participation`, or `decidim-stats`.
-However, we don't recommend this unless you are more in a testing phase and not sure if your work is going to be released
+However, we do not recommend this unless you are more in a testing phase and not sure if your work is going to be released
 more generically (most of the times this is the first approach for isolating the features). See more details about the sub-folder approach
 at xref:customize:code.adoc[Code customization].
 
@@ -22,7 +22,7 @@ The best way to proceed is to first decide what you need, then take a look at ho
 
 - Other external modules
 - Other Decidim instances, and from there extract the feature to a module
-- Decidim source code itself: take into account that Decidim is a bunch of separated modules, so there's much to be learned by looking at the code).
+- Decidim source code itself: take into account that Decidim is a bunch of separated modules, so there is much to be learned by looking at the code).
 - Other Rails applications or documentation, because yes, this is Ruby on Rails in the end.
 
 Regarding the type of features you want to develop, these are some typical cases:
@@ -31,12 +31,12 @@ Regarding the type of features you want to develop, these are some typical cases
 - Add new routes without many relations to existing features. Then just follow standard guides for creating engines for Ruby on Rails.
 - Creating a verification handler: very typical scenario. Some verification methods are worth extracting to a module as can be very standard.
 - Add content blocks. Content blocks are used currently in the homepage and processes groups, they can transform the user experience quite a lot!
-- xref:customize:views.adoc[Override existing view]: This is quite common but more delicate, it consists of creating the same app/view/some-decidim-view-file file in your module to replace the original one. It's easy but you need to define a strategy for updating your overridden file every time the original in Decidim source code is changed. Some people use the gem Deface for that too.
+- xref:customize:views.adoc[Override existing view]: This is quite common but more delicate, it consists of creating the same app/view/some-decidim-view-file file in your module to replace the original one. It is easy but you need to define a strategy for updating your overridden file every time the original in Decidim source code is changed. Some people use the gem Deface for that too.
 - xref:customize:code.adoc[Override other classes or modules in Decidim]: Similar as before, but instead of just overriding files you usually take advantage of the technique of "monkey patching", something that the Ruby language is especially well suited for. Again, you need to be careful between Decidim upgrades if the original files change.
 
 Note also that the two last ones might have conflicts with other modules, so it is worth having a nice suite of tests, both in modules and specific Decidim implementations.
 
-There's a https://decidim.org/modules/[list of modules] that it is updated from time to time, but if you are looking for technology implementations, take a look at these (please contribute to this list if you are implementing something new!):
+There is a https://decidim.org/modules/[list of modules] that it is updated from time to time, but if you are looking for technology implementations, take a look at these (please contribute to this list if you are implementing something new!):
 
 . Payment gateways: https://github.com/decidiamo/decidim-module-donations[decidiamo/decidim-module-donations]
 . Generic verification handlers:
@@ -74,7 +74,7 @@ In the case of dealing with more advanced overrides, we recommend implementing s
 
 == Recommendations
 
-First and foremost, don't be afraid to try and start hacking. Once you feel confident enough, read the recommendations
+First and foremost, do not be afraid to try and start hacking. Once you feel confident enough, read the recommendations
 and best practices below. Remember also that this is free software, so you can do whatever you want in the end.
 These are some opinions on how to improve the quality of the software, but they are not hard rules.
 
@@ -90,12 +90,12 @@ These are some opinions on how to improve the quality of the software, but they
   . steps to run the tests locally
   . how do you want to accept contributions
 * To follow our same rules regarding https://github.com/decidim/decidim/blob/develop/.rubocop.yml[code styling]
-* To have a license file that's compatible with Decidim license (GPL Affero 3)
+* To have a license file that is compatible with Decidim license (GPL Affero 3)
 * To have a valid .gemspec file
 * To follow the Decidim Social Contract
-* To have a description and other metadata (ie tags) on GitHub or another platform, so it's more discoverable
+* To have a description and other metadata (ie tags) on GitHub or another platform, so it is more discoverable
 * Has good i18 support (all the strings that could be translated are in config/locales/en.yml)
-* If you upload it to GitHub, do it with the naming *decidim-module-<engine_name>*, so it's easier to find on
+* If you upload it to GitHub, do it with the naming *decidim-module-<engine_name>*, so it is easier to find on
 the https://github.com/decidim/decidim/network/dependents[dependency graph]. See discussion at https://github.com/decidim/decidim/issues/2396[GitHub].
 * To use Decidim features and APIs when relevant:
   . Using the Admin panel
@@ -106,8 +106,8 @@ the https://github.com/decidim/decidim/network/dependents[dependency graph]. See
   . Followable
   . Embeddable
   . Notifications
-  . If it's a new space, then it should be compatible with the "Context help"
-* Upload the Gem to Rubygems.org so it's easier to deploy to other apps
+  . If it is a new space, then it should be compatible with the "Context help"
+* Upload the Gem to Rubygems.org so it is easier to deploy to other apps
 * To https://decidim.org/contact/[contact us] so we can publish it at https://decidim.org/modules/[Modules page]
 
 == Types
@@ -141,7 +141,7 @@ module Decidim
         end
 
         # This is a Dedicim::Verifications specific initializer
-        initializer "decidim.my_verifier_verification_workflow" do |_app|
+        initializer "decidim_verifications_my_verifier.verification_workflow" do |_app|
           Decidim::Verifications.register_workflow(:my_verifier) do |workflow|
             workflow.engine = Decidim::Verifications::MyVerifier::Engine
           end

data/docs/modules/develop/pages/newsletter_templates.adoc

@@ -6,7 +6,7 @@ Code-wise, they use the content blocks system internally, so xref:develop:conten
 
 == Adding a new template
 
-You'll first need to register the template as a content block, but specifying `:newsletter_template` as its scope:
+You will first need to register the template as a content block, but specifying `:newsletter_template` as its scope:
 
 [source,ruby]
 ----
@@ -34,23 +34,23 @@ Decidim.content_blocks.register(:newsletter_template, :my_template) do |content_
 end
 ----
 
-You'll need to add this into an initializer. Note that if you're adding this from a module, then you need to add it from the `engine.rb` file (check the docs for content blocks for more info).
+You will need to add this into an initializer. Note that if you are adding this from a module, then you need to add it from the `engine.rb` file (check the docs for content blocks for more info).
 
-This is the simplest template. It has a single attribute, in this case a translatable chunk of text. Let's go line by line.
+This is the simplest template. It has a single attribute, in this case a translatable chunk of text. We will analyze the example line by line.
 
-Inside the block, first we define the path of the cell we'll use to render the email publicly. This cell will receive the `Decidim::ContentBlock` object, which will contain the attributes and any image we have (one in this example). In order to render cells, please note that emails have a very picky HTML syntax, so we suggest using some specialized tools to design the template, export the layout to HTML and render that through the cell. We suggest you make this cell inherit from `Decidim::NewsletterTemplates::BaseCell` for convenience.
+Inside the block, first we define the path of the cell we will use to render the email publicly. This cell will receive the `Decidim::ContentBlock` object, which will contain the attributes and any image we have (one in this example). In order to render cells, please note that emails have a very picky HTML syntax, so we suggest using some specialized tools to design the template, export the layout to HTML and render that through the cell. We suggest you make this cell inherit from `Decidim::NewsletterTemplates::BaseCell` for convenience.
 
 Then we define the cell that will be used to render the form in the admin section. This form needs to show inputs for the attributes defined when registering the template. It will receive the `form` object to render the input fields. We suggest this cell to inherit from `Decidim::NewsletterTemplates::BaseSettingsFormCell`.
 
 In the third line inside the block we define the I18n path to the public name of the template. This name will serve as identifier for the users who write the newsletters, so be sure to make it descriptive.
 
-After that we define the images this newsletter supports. We give it a unique name, the class name of the uploader we'll use (the example one is the default one, but you might want to customize this value) and a way to preview this image. This preview image will only be used in the "Preview" page of the template, it's not a fallback. If you want a fallback, please implement it through a custom uploader (see ``carrierwave``'s docs for that). There's no limit of the amount of images you add.
+After that we define the images this newsletter supports. We give it a unique name, the class name of the uploader we will use (the example one is the default one, but you might want to customize this value) and a way to preview this image. This preview image will only be used in the "Preview" page of the template, it is not a fallback. If you want a fallback, please implement it through a custom uploader (see ``carrierwave``'s docs for that). There is no limit of the amount of images you add.
 
-Finally, we define the attributes for the newsletter. In this case we define a body attribute, which is a translatable text. Whether this text require an editor or not will be defined by the settings cell. We also have a way to preview that attribute. There's no limit on the number of attributes you define.
+Finally, we define the attributes for the newsletter. In this case we define a body attribute, which is a translatable text. Whether this text require an editor or not will be defined by the settings cell. We also have a way to preview that attribute. There is no limit on the number of attributes you define.
 
 == Interpolating the recipient name
 
-Decidim accepts `+%{name}+` as a placeholder for the recipient name. If you want your template to use it, you'll need to call `parse_interpolations` in your public cell:
+Decidim accepts `+%{name}+` as a placeholder for the recipient name. If you want your template to use it, you will need to call `parse_interpolations` in your public cell:
 
 [source,ruby]
 ----

data/docs/modules/develop/pages/notifications.adoc

@@ -49,8 +49,8 @@ Both, `EmailNotificationGenerator` and `NotificationGenerator` are use the same
 * *event*: A String with the name of the event.
 * *event_class*: A class that wraps the event.
 * *resource*: an instance of a class implementing the `Decidim::Resource` concern.
-* *followers*: a collection of Users that receive the notification because they're following it.
-* *affected_users*: a collection of Users that receive the notification because they're affected by it.
+* *followers*: a collection of Users that receive the notification because they are following it.
+* *affected_users*: a collection of Users that receive the notification because they are affected by it.
 * *force_send*: boolean indicating if EventPublisherJob should skip the `notifiable?` check it performs before notifying.
 * *extra*: a Hash with extra information to be included in the notification.
 
@@ -96,7 +96,7 @@ The keys to be used will have the translation scope corresponding to the event n
 The following are the parts of the notification email:
 
 * _email_subject_, to be customized
-* email_greeting, with a good default, usually there's no need to cusomize it
+* email_greeting, with a good default, usually there is no need to cusomize it
 * _email_intro_, to be customized
 * _resource_text_ (optional), rendered `html_safe` if present
 * _resource_url_, a link to the involved resource if resource_url and resource_title are present

data/docs/modules/develop/pages/permissions.adoc

@@ -10,23 +10,23 @@ When checking for permission to perform an action, we check this chain:
 . The participatory space permissions
 . The core permissions
 
-This way we're going from more specific to more general.
+This way we are going from more specific to more general.
 
 == Explanation
 
-We wrap the permission and its context in a `PermissionsAction` object. It also holds the state of the permission (whether it's been allowed or not).
+We wrap the permission and its context in a `PermissionsAction` object. It also holds the state of the permission (whether it has been allowed or not).
 
 Each component and space must define a `Permissions` class, inheriting from `Decidim::DefaultPermissions`. The `Permissions` class must define a `permissions` instance method. this class will receive the permission action, and the `permissions` method must return the permission action. The `Permissions` class can set the action as allowed or disallowed.
 
-There's a small limitation in the permission action state machine: once it's been disallowed it can't be reallowed. This is to avoid mischievous modules modifying permissions.
+There is a small limitation in the permission action state machine: once it has been disallowed it cannot be reallowed. This is to avoid mischievous modules modifying permissions.
 
-Permission actions have a scope. It's usually either `:public` or `:admin`, and the `Permissions` class usually handles the `:public` scope, while it delegates the `:admin` one to another specialized class.
+Permission actions have a scope. It is usually either `:public` or `:admin`, and the `Permissions` class usually handles the `:public` scope, while it delegates the `:admin` one to another specialized class.
 
 == Add a new Action
 
 === Proposals example
 
-We're going to reproduce the steps to add an action (endorse) for a proposal step by step.
+We are going to reproduce the steps to add an action (endorse) for a proposal step by step.
 
 ==== Configuring a new 'endorse' action
 
@@ -60,7 +60,7 @@ enforce_permission_to :endorse, :proposal, proposal: proposal
 
 ==== Allow to configure the related permissions at resource level
 
-Permissions settings could also be set for an specific resources appart from the full component. Actions should also be related to the resource.
+Permissions settings could also be set for an specific resources apart from the full component. Actions should also be related to the resource.
 
 . Edit decidim-proposals/lib/decidim/proposals/component.rb
 . Add the 'endorse' action into the `resource.actions` array for the `proposal` resource definition and save the file:

data/docs/modules/develop/pages/profiling.adoc

@@ -17,7 +17,7 @@ bundle exec rails s
 
 == Bullet
 
-Bullet detects N+1 queries and suggests how to fix them, although it doesn't catch them all. It's currently configured in `config/initializers/bullet.rb` to log in the regular rails log and also in its own `log/bullet.log`. You'll now see entries like the following:
+Bullet detects N+1 queries and suggests how to fix them, although it does not catch them all. It is currently configured in `config/initializers/bullet.rb` to log in the regular rails log and also in its own `log/bullet.log`. You will now see entries like the following:
 
 [source,bash]
 ----
@@ -29,13 +29,13 @@ USE eager loading detected
 Call stack
 ----
 
-It also warns you when there's an unnecessary eager load.
+It also warns you when there is an unnecessary eager load.
 
 More details: https://github.com/flyerhzm/bullet
 
 == Rack-mini-profiler
 
-This gem can analyze memory, database, and call stack with flamegraphs. It will show up in development on the top left corner and it gives you all sorts of profiling insights about that page. It'll tell you where the response time was spend on in the call stack.
+This gem can analyze memory, database, and call stack with flamegraphs. It will show up in development on the top left corner and it gives you all sorts of profiling insights about that page. It will tell you where the response time was spend on in the call stack.
 
 This gem is further enhanced with the `flamegraph`, `stackprof` and `memory_profiler` gems which provide more detailed analysis. Try out by appending `?pp=flamegraph`, `?pp=profile-gc` or `?pp=analyze-memory` to the URL. You can read more about these options at https://github.com/MiniProfiler/rack-mini-profiler#flamegraphs.
 

data/docs/modules/develop/pages/reminders.adoc

@@ -29,7 +29,7 @@ Reminders consist of the following database objects:
 
 - Reminder which holds the main reminder object that is attached to a user to be reminded about and the component for which the reminder is created for. The reminder can have many deliveries and many records to be reminded about.
 - ReminderDelivery which holds a log of all deliveries sent to the user. This may be useful in cases where we need to audit the system or solve a user support request asking why they were reminded for a specific thing at a specific time. In the backend, this also lets us do conditional logic based on how many times the user has been reminded and when the last reminder was sent.
-- ReminderRecord which holds information about the records the reminder is related to. This lets us combine reminders that are related to multiple records at a time, so that we don't need to send mulitple emails for each record. For example, the budgeting reminders will contain information about in which budgets the user has pending votes which allows us to combine this information in a single email, instead of sending one email per pending order in each budget.
+- ReminderRecord which holds information about the records the reminder is related to. This lets us combine reminders that are related to multiple records at a time, so that we do not need to send mulitple emails for each record. For example, the budgeting reminders will contain information about in which budgets the user has pending votes which allows us to combine this information in a single email, instead of sending one email per pending order in each budget.
 
 ==== ReminderRecord states
 
@@ -37,7 +37,7 @@ The ReminderRecord object holds a "state" attribute which tells whether the reco
 
 - `active` - The reminder record is active for the reminder to be sent. Only active records should be included in the reminder.
 - `pending` - The reminder record is "pending" which means that the reminder should probably be sent soon but not for sure. For example, in the budgeting reminders the reminder record is "pending" if voting has been started but it has been started just a moment before automatically sending the reminders. In this situation, we would not want to remind the user if they started the voting process two minutes before the automatic reminder sending was run on the server.
-- `deleted` - The record has been "deleted", so it will not need any further reminders. We still keep the ReminderRecord in order to preserve the backlog about when the previous reminders were sent. For example, in the budgeting reminders, the ReminderRecord is related to a budgeting "order" (or vote) which can be deleted by the user, and therefore won't need any further reminders.
+- `deleted` - The record has been "deleted", so it will not need any further reminders. We still keep the ReminderRecord in order to preserve the backlog about when the previous reminders were sent. For example, in the budgeting reminders, the ReminderRecord is related to a budgeting "order" (or vote) which can be deleted by the user, and therefore will not need any further reminders.
 - `completed` - The record has been "completed", so it will not need any further reminders. The reminders can be specific to the state of the remindable objects, so we change the ReminderRecord state to "completed" when the record will not need any further reminders. For example, in the budgeting reminders, we would not want to remind the user anymore if they completed their vote in a budget but they still have pending order in another budget that will still need further reminders. In this situation, we would want to include only the pending order in the further reminders, still keeping the backlog information about the previous reminders for the already completed budget order (vote).
 
 == Defining a reminder

data/docs/modules/develop/pages/security.adoc

@@ -5,7 +5,7 @@
 Until we have the version 1.0 we support only the last minor and major
 version with security updates.
 
-https://github.com/decidim/decidim/blob/doc/security-keyserver/SECURITY.adoc[See the last supported version].
+https://github.com/decidim/decidim/blob/develop/SECURITY.md[See the last supported version].
 
 == Reporting a Vulnerability
 

data/docs/modules/develop/pages/share_tokens.adoc

@@ -18,7 +18,7 @@ end
 
 == Set permissions
 
-You should change permissions logic for the resource to check if there's a `share_token` query parameter in the request url, and call `Decidim::ShareToken.use!` to both check if the token is valid, and if it is, to _use it_ (which increments `times_used` variable and sets `last_used_at` to current time).
+You should change permissions logic for the resource to check if there is a `share_token` query parameter in the request url, and call `Decidim::ShareToken.use!` to both check if the token is valid, and if it is, to _use it_ (which increments `times_used` variable and sets `last_used_at` to current time).
 
 It should do something similar to this:
 

data/docs/modules/develop/pages/testing.adoc

@@ -59,8 +59,8 @@ But beware, it takes a long time... :)
 
 === Running specs in parallel
 
-We've configured the https://github.com/grosser/parallel_tests[parallel_tests gem]. For
-using it, you'll need to follow these steps:
+We have configured the https://github.com/grosser/parallel_tests[parallel_tests gem]. For
+using it, you will need to follow these steps:
 
 . Configure the TEST_ENV_NUMBER environment variable with the number of processes that you want to run in parallel.
 . Run the commands to prepare the test database

data/docs/modules/develop/pages/traceable.adoc

@@ -5,15 +5,15 @@ In order to make your component compatible with the activity log, you need to fo
 . Make your model include the `Decidim::Traceable` module. This will let Decidim create versions every time your model records are changed. It uses https://github.com/airblade/paper_trail[`paper_trail`] to generate the versions.
 . Make your commands use `Decidim.traceability` to create and update records. Documentation can be found in `Decidim::Traceability`. This should set the author of the change in your record properly.
 
-That's all you need to do to get it working, really. We have a default way to present logs that Just Works™. Keep reading if you want to customize how the logs for your resources look!
+That is all you need to do to get it working, really. We have a default way to present logs that Just Works™. Keep reading if you want to customize how the logs for your resources look!
 
 == The default renderer
 
-The default renderer doesn't know many things. It knows the author, what action was done, the resource affected and the space where the resource resides. When the resource is updated it shows the diff of all the fields that have been changed, with the old and new values for each field. values are not formatted in any specific way, so you might see some weirdly formatted values on the log diff: that's how it's rendered from the database.
+The default renderer does not know many things. It knows the author, what action was done, the resource affected and the space where the resource resides. When the resource is updated it shows the diff of all the fields that have been changed, with the old and new values for each field. values are not formatted in any specific way, so you might see some weirdly formatted values on the log diff: that is how it is rendered from the database.
 
 == Customizing the logs for your resources
 
-The default presenter doesn't fulfill your needs? You might want to create your own presenter if you find yourself in one of these cases:
+The default presenter does not fulfill your needs? You might want to create your own presenter if you find yourself in one of these cases:
 
 * You want to show what type of resource is affected by the action log
 * The default renderer cannot find the correct field to render the resource name
@@ -21,9 +21,9 @@ The default presenter doesn't fulfill your needs? You might want to create your
 * You want to change the order of the factors in the log sentence
 * You want to change the format of the values in the diff
 
-Let's go ahead and see how to create your own resource presenter.
+Next, you will learn how to create your own resource presenter.
 
-Custom presenters should be named as `Decidim::<your module name>::<log name>::<your model name>Presenter`. There's currently only one log, `AdminLog`. This means that if your model is `Decidim::Accountability::Result`, then your admin log presenter is must be `Decidim::Accountability::AdminLog::ResultPresenter`. You can inherit from `Decidim::Log::BasePresenter` for simplicity:
+Custom presenters should be named as `Decidim::<your module name>::<log name>::<your model name>Presenter`. There is currently only one log, `AdminLog`. This means that if your model is `Decidim::Accountability::Result`, then your admin log presenter is must be `Decidim::Accountability::AdminLog::ResultPresenter`. You can inherit from `Decidim::Log::BasePresenter` for simplicity:
 
 [source,ruby]
 ----
@@ -71,7 +71,7 @@ This is useful to show the resource type in the sentence.
 
 By default, all changed fields are presented in the diff. In order to limit them, overwrite the `diff_fields_mapping` method in your custom presenter. It has to return a `Hash`, where keys are the name of the attributes and values are the presenters that render the attributes. *Limitations*: we can only show diffs for column fields, not dynamic methods, so the `diff_fields_mapping` only accepts column names.
 
-In this example, we're telling our presenter to only present the `start_date` as a date, the `title` as an i18n field, the `decidim_scope_id` with no particular presenter, and `progress` as a percentage:
+In this example, we are telling our presenter to only present the `start_date` as a date, the `title` as an i18n field, the `decidim_scope_id` with no particular presenter, and `progress` as a percentage:
 
 [source,ruby]
 ----
@@ -140,4 +140,4 @@ end
 
 == Multiple logs
 
-Although Decidim currently only has a log for the admin section, in the future we might need an activity log for the public part. It's easy to assume we might need to render the same data in different formats, so we need to differentiate the presenters for each log. The current system handles the case for multiple logs, although we only have one.
+Although Decidim currently only has a log for the admin section, in the future we might need an activity log for the public part. It is easy to assume we might need to render the same data in different formats, so we need to differentiate the presenters for each log. The current system handles the case for multiple logs, although we only have one.

data/docs/modules/develop/pages/troubleshooting_metrics.adoc

@@ -19,7 +19,7 @@ If somehow the metrics jobs fail to execute for a period of time, big difference
 
 If you have metrics generated for almost everyday and still see drastic changes from day to day, take into account that changing the visibility of a component or participatory space (making them private or unpublishing them) will naturally cause big differences in generated metrics.
 
-Finally, if you see that the differences in some days are multiples of a previous generated metric, meaning suddenly you have exactly the double or the triple of a calculated metric, it's very likely that you have duplicate generated metrics. We have only seen this problem with instances using Sidekiq, not Delayed Job. We do not know the cause of this, but it seems to be a known issue https://blog.francium.tech/avoiding-duplicate-jobs-in-sidekiq-dcbb1aca1e20[Avoiding duplicate jobs in Sidekiq].
+Finally, if you see that the differences in some days are multiples of a previous generated metric, meaning suddenly you have exactly the double or the triple of a calculated metric, it is very likely that you have duplicate generated metrics. We have only seen this problem with instances using Sidekiq, not Delayed Job. We do not know the cause of this, but it seems to be a known issue https://blog.francium.tech/avoiding-duplicate-jobs-in-sidekiq-dcbb1aca1e20[Avoiding duplicate jobs in Sidekiq].
 
 == Solutions
 

data/docs/modules/develop/pages/turbolinks.adoc

@@ -1,7 +1,7 @@
 = Turbolinks
 
-Decidim doesn't support `turbolinks` so it isn't included on our generated apps and it's removed for existing Rails applications which install the Decidim engine.
+Decidim does not support `turbolinks` so it is not included on our generated apps and it is removed for existing Rails applications which install the Decidim engine.
 
-The main reason is we are injecting some scripts into the body for some individual pages and Turbolinks loads the scripts in parallel. For some libraries like http://leafletjs.com/[leaflet] it's very inconvenient because its plugins extend an existing global object.
+The main reason is we are injecting some scripts into the body for some individual pages and Turbolinks loads the scripts in parallel. For some libraries like http://leafletjs.com/[leaflet] it is very inconvenient because its plugins extend an existing global object.
 
-The support of Turbolinks was dropped in https://github.com/decidim/decidim/commit/d8c7d9f63e4d75307e8f7a0360bef977fab209b6[d8c7d9f]. If you're interested in bringing turbolinks back, further discussion is welcome.
+The support of Turbolinks was dropped in https://github.com/decidim/decidim/commit/d8c7d9f63e4d75307e8f7a0360bef977fab209b6[d8c7d9f]. If you are interested in bringing turbolinks back, further discussion is welcome.

data/docs/modules/develop/pages/view_hooks.adoc

@@ -30,7 +30,7 @@ Instead of the previous example, we created the concept of "view hooks". Think o
 <%= Decidim.view_hooks.render(:highlighted_elements, deep_dup) %>
 ----
 
-We're rendering the view hooks registered as `:highlighted_elements`. The `deep_dup` parameter is a deep copy of the view context, we will analyze it later.
+We are rendering the view hooks registered as `:highlighted_elements`. The `deep_dup` parameter is a deep copy of the view context, we will analyze it later.
 
 == Registering view hooks
 
@@ -46,7 +46,7 @@ initializer "decidim_participatory_processes.view_hooks" do
 end
 ----
 
-In order to register a view hook we need the hook name and a block of Ruby code. We're registering a view hook as `:highlighted-elements`, following our example. We're passing a deep copy of the view context to the block so that we can use our views helper methods there, and we're rendering a partial. We could write `ActiveRecord` queries and pass the results to the partial as `locals` if we wanted a more complex view:
+In order to register a view hook we need the hook name and a block of Ruby code. We are registering a view hook as `:highlighted-elements`, following our example. We are passing a deep copy of the view context to the block so that we can use our views helper methods there, and we are rendering a partial. We could write `ActiveRecord` queries and pass the results to the partial as `locals` if we wanted a more complex view:
 
 [source,ruby]
 ----
@@ -61,7 +61,7 @@ initializer "decidim_participatory_processes.view_hooks" do
 end
 ----
 
-We're passing a deep copy of the view context to allow us to extend it without polluting the original view context:
+We are passing a deep copy of the view context to allow us to extend it without polluting the original view context:
 
 [source,ruby]
 ----

data/docs/modules/install/pages/checklist.adoc

@@ -5,35 +5,36 @@ As a technopolitical project, Decidim needs several things to work. This is a no
 == Technological
 
 . Choose a *domain or subdomain* for your application. Some typical names involve "Participation" or "Decision" conjugations.
-. Choose which *languages* do you want for your application. In case that your language isn't supported you should translate it on https://crowdin.com/project/decidim[Crowdin].
+. Choose which *languages* do you want for your application. In case that your language is not supported you should translate it on https://crowdin.com/project/decidim[Crowdin].
 . Customize the xref:customize:styles.adoc[*look and feel*] (colors, pictures, fonts, etc).
 . Configure *SSL*:
 .. We recommend using at least *https://letsencrypt.org/[Let's Encrypt]* for minimum security.
 .. Configure *redirection from HTTP to HTTPS* on your web server.
 .. Configure your *Certificate Authority Authorization* (CAA) DNS records
-.. Install complete *Certificate Chains* if it's needed for your provider
+.. Install complete *Certificate Chains* if it is needed for your provider
 .. Use current SSL/TLS Protocols (*TLS 1.2 or 1.3*)
 .. If you add new static files, be careful of not introducing *mixed content*
 .. Use the *https://www.ssllabs.com/ssltest/[SSL Server Test]* and follow their recommendations
 . Configure your *SMTP* server.
 . Setup the *geolocation* service. We recommend using https://developer.here.com/[Here Maps], but you can use other kind of tiling server compatible with https://www.openstreetmap.org/[Open Street Maps].
 . Setup *backup* on your server. The most important things to save are the `public/uploads` and the database.
-. Decide and implement which kind of *xref:customize:authorizations.adoc[Authorization]* you're going to use.
+. Decide and implement which kind of *xref:customize:authorizations.adoc[Authorization]* you are going to use.
 . Comply with our License (Affero GPL 3) and *publish your code* to http://github.com[GitHub] or wherever you want.
 . Review your *decidim initializer* on your application (config/initializers/decidim.rb).
 . Configure your xref:services:activejob.adoc[*ActiveJob*] background queue.
+. Configure your xref:services:activestorage.adoc[*ActiveStorage*] dynamic uploads.
 . If you want, configure your xref:services:social_providers.adoc[*social providers*] to enable login using external applications.
-. Check that you don't have any *default users, emails and passwords*, neither on the admin or on the system panel.
+. Check that you do not have any *default users, emails and passwords*, neither on the admin or on the system panel.
 . Configure xref:install:index.adoc#scheduled_tasks[scheduled tasks].
 . You should have a *staging* / preproduction environment where to test changes before deploying to production. If this environment has a copy of production database, you should disable the SMTP server and for privacy issues you should change the usernames / names / emails.
 . You should have a *exception tracking* service or gem, like https://errbit.com/[Errbit], https://github.com/smartinez87/exception_notification[Exception Notification], https://airbrake.io/[Airbrake] or https://sentry.io[Sentry].
 
 == Contents
 
-. Ideally you'll have a *Team* formed with experts on IT, Communication, Participation, Design and Law.
-. Texts for at least, *terms of use, privacy policy and frequently asked questions*. To show the "Terms and conditions" body text in the "Sign Up Form", it is a requirement that the slug of this page to be equal `terms-and-conditions`.
+. Ideally you will have a *Team* formed with experts on IT, Communication, Participation, Design and Law.
+. Texts for at least, *terms of service, privacy policy and frequently asked questions*. To show the "Terms of service" body text in the "Sign Up Form", it is a requirement that the slug of this page to be equal `terms-of-service`.
 . Comply with your current *legal requirements*, like to registrate your privacy policy with the autorities (eg LOPD on Spain).
 . Fill the *Participatory Processes Configuration Form* to prepare your Participatory Process for Decidim.
 . Read the *xref:admin:index.adoc[Administration manual]*.
-. Participate on *http://meta.decidim.org[MetaDecidim]*.
+. Participate on *http://meta.decidim.org[Metadecidim]*.
 . Read the Decidim *https://decidim.org/contract/[Social Contract]*.