fu

CONTRIBUTING.md

@@ -36,7 +36,7 @@ Examples:
 
 #### Patch bump
 
-- Fixing or improving an already existing
+- Fixing or improving an already existing calculation.
 
 #### Minor bump
 
@@ -63,22 +63,20 @@ Each change must be documented with the following elements:
 > ### 13.1.5 - [#684](https://github.com/openfisca/openfisca-france/pull/684)
 
 - The second line indicates the type of the change. The possible types are:
- - `Tax and benefit system evolution`: Calculation improvement, fix, or update. Impacts the users interested by calculations. 
+ - `Tax and benefit system evolution`: Calculation improvement, fix, or update. Impacts the users interested in calculations. 
  - `Technical improvement`: Performances improvement, installing process change, formula syntax change… Impacts the users who write legislation and/or deploy their own instance.
  - `Crash fix`: Impact all reusers.
  - `Minor change`: Refactoring, metadata… Has no impact on users.
-act sur les réutilisateurs.
 
 - In the case of a `Tax and benefit system evolution`, the following elements must then be specified:
-  - The periods impacted by the change. To avoid any ambiguity, the start and/or end day of the impacted periods must be precised. For instance, `from 01/01/2017` is correct, but `from 2017` is not, as it is ambiguous: it is not clear wheter 2017 is included or not in the impacted period.
+  - The periods impacted by the change. To avoid any ambiguity, the start day and/or the end day of the impacted periods must be precised. For instance, `from 01/01/2017` is correct, but `from 2017` is not, as it is ambiguous: it is not clear wheter 2017 is included or not in the impacted period.
   - The tax and benefit system areas impacted by the change. These areas are described by the relative paths to the modified files, without the `.py` extension. 
 
 > For instance :
 > - Impacted periods: Until 31/12/2015.
 > - Impacted areas: `benefits/healthcare/universal_coverage`
 
-- Finally, for all cases except `Minor Change`, the changes must be explicited by details given from a 
-user perspective: in which case was an error or a problem was noticed ? What is the new available feature ? Which new behaviour is adopted.
+- Finally, for all cases except `Minor Change`, the changes must be explicited by details given from a user perspective: in which case was an error or a problem was noticed ? What is the new available feature ? Which new behaviour is adopted.
 
 > For instance:
 >
@@ -92,9 +90,9 @@ user perspective: in which case was an error or a problem was noticed ? What is
 >
 > * Details :
 >  - Use OpenFisca-Core `12.0.0`
->  - Change the syntax to declare parameters:
+>  - Change the syntax used to declare parameters:
 >      - Remove "fuzzy" attribute 
 >      - Remove "end" attribute
->      - All parameters are assumed to be valid until and end date is explicitely specified with an `<END> tag`
+>      - All parameters are assumed to be valid until and end date is explicitely specified with an `<END>` tag
 
 When a Pull Request contains several disctincts changes, several paragraphs may be added to the Changelog. To be properly formatted in Markdown, these paragraphs must be separated by `<!-- -->`.