Normalisation des métadonnées des paramètres #1672

MattiSG · 2021-09-09T15:10:09Z

RFC : normalisation des métadonnées des paramètres

Objet

Cette RFC vise à établir une liste des métadonnées à utiliser dans OpenFisca France pour les paramètres.

Contexte, Nécessité, Processus…

Cette issue est le résultat d'un éclatement de #1618 opéré afin de faciliter la lecture. Tout le contexte, ainsi que le catalogue des métadonnées à traiter, est donc donné dans #1618 (comment). Il s'agit ici de continuer la conversation, uniquement sur les paramètres, en s'appuyant sur les résultats déjà obtenus pour les variables.

MattiSG · 2021-09-09T15:11:26Z

Version 0 d'une proposition pour `description` (métadonnée de Paramètre)

Fonctionnement actuel, sans changement.

Nom : description
Type : texte libre.
Objet : donner un nom lisible au paramètre.
Échelle de déclaration : Paramètre.
Convention : contenir le nom de l'ensemble des nœuds traversés avec une expansion des abréviations et les abréviations entre parenthèses.
Cas d'usage :
- Désambiguer un paramètre dont le nom est une abréviation.
- Rechercher et afficher un paramètre dans l'explorateur de législation.
Exemples :
- "Indicatrice d'imposition"
- "Contribution exceptionnelle sur les hauts revenus"
Lieu de documentation : openfisca.org/doc pour le format de données, CONTRIBUTING.md pour les conventions.

MattiSG · 2021-09-09T15:12:07Z

Version 1A d'une proposition pour `description` (métadonnée de Paramètre)

Renommage en label, ajout d'une limite de caractères et d'une contrainte d'unicité dans le système socio-fiscal.

Il s'agit d'une adaptation de la proposition 2B pour label (Variable), qui a été adoptée.

La liste des valeurs en doublon est disponible ci-dessous :

Nombre d'occurrences	Texte
47	Taux
23	Plafond
12	Indice majoré plafond
8	Maximum
7	Seuil
6	Cotisations et taxes des indépendants artisans-commerçants
5	Seuil de non versement
5	Plafond de ressources
5	'Taxes sur les salaires
4	Taux pour 2 enfants
4	Majoration du plafond pour les 2 premiers enfants
4	Majoration du plafond à partir du 3ème enfant
3	Taux pour une 3e personne
3	Taux pour une 2nde personne
3	Taux pour 2 adultes
3	Taux pour 1 enfant
3	Taux pour 1 adulte
3	Taux par personne supplémentaire
3	Taux de l'abattement
3	Taux 22%
3	Minimum
3	Limite d'âge des enfants comptés à charge
3	Effort à la construction
3	Cotisations syndicales
2	Zone 3 - couple
2	Zone 3 - Majoration par personne à charge supplémentaire
2	Zone 3 - Famille avec 1 personne à charge
2	Zone 3 - 1 adulte
2	Zone 2 - couple
2	Zone 2 - Majoration par personne à charge supplémentaire
2	Zone 2 - Famille avec 1 personne à charge
2	Zone 2 - 1 adulte
2	Zone 1 - couple
2	Zone 1 - Majoration par personne à charge supplémentaire
2	Zone 1 - Famille avec 1 personne à charge
2	Zone 1 - 1 adulte
2	Versement forfaitaire sur les salaires (1949-1967)
2	Taux pour les activités de ventes
2	Taux pour les activités de prestations et de services
2	Taux pour 4 enfants
2	Taux pour 3 enfants
2	Taux par enfants supplémentaires
2	Taux employé (de moins de 65 ans, en Alsace-Moselle) des cotisations de sécurité sociale (SS) des journalistes pigistes pour les assurances sociales avant 1967, sous le plafond de la sécurité sociale (PSS)
2	Taux de la majoration du RSA socle pour une femme enceinte sans enfant
2	Taux de la décote
2	Taux de la Contribution Sociale Généralisée (CSG) sur les revenus du capital (produits de placement)
2	Taux de la Contribution Sociale Généralisée (CSG) imposable sur les revenus d'activité
2	Taux de la Contribution Sociale Généralisée (CSG) déductible sur les revenus du capital (produits de placement)
2	Taux d'intérêt forfaitaire appliqué à l'épargne générant des revenus non imposables
2	Taux biens ruraux
2	Taux 30%
2	Taux 25%
2	Taux 2
2	Taux 18%
2	Taux 15%
2	Taux 1
2	Taux (WL)
2	Seuil de la décote pour un couple
2	Seuil de la décote pour un célibataire
2	Seuil de RFR à partir duquel un foyer ayant bénéficié d'un éco-prêt à taux zéro ne peut pas bénéficier du crédit d'impôt
2	Sécurité sociale/ Maladie, maternité
2	Sécurité sociale/ Indemnités journalières
2	Second plafond de ressources pour un enfant
2	Rsa socle
2	Revenus liés au patrimoine
2	Retraite de base
2	Retraite complémentaire
2	Report des excédents 2011
2	Réduction du temps de travail de 10%, allègements Robien (1996-2005) des cotisations de Sécurité sociale (SS)
2	Réduction d'impôt exceptionnelle
2	Prime de solidarité active
2	Premier taux
2	Pourcentage du RSA socle pour une personne (pour une personne)
2	Pourcentage du RSA socle pour trois personnes (pour trois et plus personnes)
2	Pourcentage du RSA socle pour deux personnes (pour deux personnes)
2	Plafond des dépenses
2	Plafond de ressources de base pour PAJE à taux plein
2	Plafond de ressources de base pour PAJE à taux partiel
2	Plafond de référence pour l'échelon 3, pour une famille avec un enfant,
2	Plafond de référence pour l'échelon 3, pour une famille avec 8 enfants
2	Plafond de référence pour l'échelon 3, pour une famille avec 7 enfants,
2	Plafond de référence pour l'échelon 3, pour une famille avec 6 enfants,
2	Plafond de référence pour l'échelon 3, pour une famille avec 5 enfants,
2	Plafond de référence pour l'échelon 3, pour une famille avec 4 enfants,
2	Plafond de référence pour l'échelon 3, pour une famille avec 3 enfants,
2	Plafond de référence pour l'échelon 3, pour une famille avec 2 enfants,
2	Plafond de référence pour l'échelon 2, pour une famille avec un enfant,
2	Plafond de référence pour l'échelon 2, pour une famille avec 8 enfants
2	Plafond de référence pour l'échelon 2, pour une famille avec 7 enfants,
2	Plafond de référence pour l'échelon 2, pour une famille avec 6 enfants,
2	Plafond de référence pour l'échelon 2, pour une famille avec 5 enfants,
2	Plafond de référence pour l'échelon 2, pour une famille avec 4 enfants,
2	Plafond de référence pour l'échelon 2, pour une famille avec 3 enfants,
2	Plafond de référence pour l'échelon 2, pour une famille avec 2 enfants,
2	Plafond de référence pour l'échelon 1, pour une famille avec un enfant,
2	Plafond de référence pour l'échelon 1, pour une famille avec 8 enfants
2	Plafond de référence pour l'échelon 1, pour une famille avec 7 enfants,
2	Plafond de référence pour l'échelon 1, pour une famille avec 6 enfants,
2	Plafond de référence pour l'échelon 1, pour une famille avec 5 enfants,
2	Plafond de référence pour l'échelon 1, pour une famille avec 4 enfants,
2	Plafond de référence pour l'échelon 1, pour une famille avec 3 enfants,
2	Plafond de référence pour l'échelon 1, pour une famille avec 2 enfants,
2	Pente du RSA
2	Participation des employeurs à la formation professionnelle continue (PEFPC), moins de 11 salariés
2	Par enfant à charge
2	Orphelin (de père et de mère), ou situation assimilée
2	Non mariés ou non PACS
2	Montant plafond par part pour les deux premières parts
2	Maximum par personne
2	Majoration pour biactifs et isolés, pour plafond taux plein
2	Majoration pour biactifs et isolés, pour plafond taux partiel
2	Majoration pour biactifs et isolés
2	Majoration du seuil par demi-part supplémentaire
2	Majoration du plafond pour le 1er enfant
2	Majoration du plafond pour biactifs ou isolé
2	Majoration du plafond par enfant supplémentaire
2	Majoration du plafond par enfant
2	Majoration du RSA socle pour parent isolé
2	Majoration du RSA socle par enfant supplémentaire (en pourcentage du
2	Loyer minimum lo
2	Limite de x % du revenu
2	Investissements locatifs intermédiaires
2	Investissements dans les DOM-TOM dans le cadre d'une entreprise
2	Invalidité, décès
2	Formation professionnelle
2	Forfait logement pour 3 personnes ou plus
2	Forfait logement pour 2 personnes
2	Forfait logement
2	Forfait annuel des cotisations pour l'association pour l'emploi des cades (APEC), régimes complémentaires de retraite (secteur privé)
2	Forfait Allocation de Soutien Familial
2	Fofait logement pour 1 personne (en % du rsa_socle)
2	Durée minimale de titre du séjour permettant de bénéficier du RSA
2	Cotisations salariales pour l'Association pour la gestion de la structure financière, ou cotisation ASF (1984-2001)
2	Cotisations retraite spécifiques à la fonction publique
2	Cotisations et taxes des professions libérales
2	Cotisations employeur de contribution au régime de garantie des salaires (AGS)
2	Cotisations de sécurité sociale (SS) pour les accidents du travail et les maladies professionnelles (AT-MP)
2	Cotisations de sécurité sociale (SS) des journalistes pigistes (1964-1974) pour les accidents du travail
2	Cotisations au régime de l'assurance chômage
2	Catégorie 1 / Autres régions - Plafonds de ressources annuelles imposables
2	Case XG
2	Case GU
2	Barème salarié des cotisations pour l'association pour l'emploi des cades (APEC), régimes complémentaires de retraite (secteur privé)
2	Allocation de base
2	Âge limite inférieur
2	Âge limite du benjamin pour un versement sans condition de durée
2	Âge de début de la 2ème majoration
2	Âge de début de la 1ere majoration
2	Activité de type BNC
2	Activité de type BIC
2	Activité de type Achat-Revente
2	Abattement maximum
2	Abattement appliqué sur la valeur locative des terrains non loués
2	Abattement appliqué sur la valeur locative des biens immobiliers non
2	1ère majoration pour âge
2	'Orphelin de père ou de mère (un seul parent manquant) ou situation assimilée
2	'Note 4
2	'Note 3
2	'Indemnité de résidence
2	"Indicatrice d'imposition"

Ces valeurs ont été obtenues par l'exécution de grep --no-filename -R 'label =' openfisca_france | cut -d '=' -f 2 | sort | uniq -c | sort .

En l'état, l'immense majorité des valeurs en doublon sont des termes génériques (« taux », « plafond »…).

En l'état, la description la plus longue compte 354 caractères.

Nom :

- `description`
+ `label`

Type :

- texte libre.
+ langage naturel limité à 420 caractères, sur une seule ligne, sans espace en début ni fin, unique dans le système socio-fiscal.

Objet : donner un nom lisible au paramètre.
Échelle de déclaration : Paramètre.
Convention : contenir le nom de l'ensemble des nœuds traversés avec une expansion des abréviations et les abréviations entre parenthèses.
Cas d'usage :
- Désambiguer un paramètre dont le nom est une abréviation.
- Rechercher et afficher un paramètre dans l'explorateur de législation.
Exemples :
- "Indicatrice d'imposition"
- "Contribution exceptionnelle sur les hauts revenus"
Lieu de documentation : openfisca.org/doc pour le format de données, CONTRIBUTING.md pour les conventions.

MattiSG · 2021-09-09T15:12:55Z

Version 1A d'une proposition pour `reference` (métadonnée de Paramètre)

On demande systématiquement un intitulé et une URL pour chaque référence législative, par le biais d'un dictionnaire plutôt que d'un tableau. Ceci a l'inconvénient d'alourdir la déclaration et suppose de normaliser la manière de référencer les URLs (i.e. de définir les clés du dictionnaire), et a l'avantage de traiter à la fois le cas d'usage pour le titre et l'URL de la reference.

Toutes les déclarations faites au niveau du nœud metadata sont déplacées vers le nœud parent (au même niveau que description, unit…)

Il s'agit d'une adaptation d'une série de propositions pour reference (Variable), qui a été adoptée.

Nom : reference
Type :

- texte libre, ou tableau de texte libre.
+ tableau associatif dont les clés sont des noms de textes légaux et les valeurs sont des URLs publiquement accessibles ou des chaînes vides.

Objet : référence légale, identifier la loi de laquelle provient le paramètre.
Échelle de déclaration : Paramètre.
Cas d'usage :
- Vérifier la validité d'une formule en consultant son origine légale.
- Afficher l'intitulé de la source légale dans l'explorateur de législation.
Exemples :

- https://www.pole-emploi.fr/candidat/mes-droits-aux-aides-et-allocati/allocations-et-aides--les-repons/aides-financieres-aux-jeunes-dip.html
+   "Site Pôle Emploi": "https://www.pole-emploi.fr/candidat/mes-droits-aux-aides-et-allocati/allocations-et-aides--les-repons/aides-financieres-aux-jeunes-dip.html"

-    - "Décret n°2020-519 du 5 mai 2020: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000041849630/"
-    - "Décret n°2020-769 du 24 juin 2020: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042032514"
-    - "Décret n°2020-1453 du 27 novembre 2020: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042574431"
+    Décret n°2020-519 du 5 mai 2020: "https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000041849630/"
+    Décret n°2020-769 du 24 juin 2020: "https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042032514"
+    Décret n°2020-1453 du 27 novembre 2020: "https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042574431"

MattiSG · 2021-09-09T15:13:19Z

Version 1A d'une proposition pour `reference.href` (métadonnée de Paramètre)

Plutôt qu'un nœud supplémentaire, on demande systématiquement un intitulé et une URL pour chaque référence législative, par le biais d'un dictionnaire. Ceci a l'avantage de traiter à la fois le cas d'usage pour le titre et l'URL de la reference.

Toutes les déclarations faites au niveau du nœud metadata sont déplacées vers le nœud parent (au même niveau que description, unit…) et transformées en reference tel que décrit dans la proposition 1A pour reference.

Il s'agit d'une adaptation d'une série de propositions pour reference (Variable), qui a été adoptée.

MattiSG · 2021-09-09T15:13:36Z

Version 1A d'une proposition pour `reference.title` (métadonnée de Paramètre)

Plutôt qu'un nœud supplémentaire, on demande systématiquement un intitulé et une URL pour chaque référence législative, par le biais d'un dictionnaire. Ceci a l'avantage de traiter à la fois le cas d'usage pour le titre et l'URL de la reference.

Toutes les déclarations faites au niveau du nœud metadata sont déplacées vers le nœud parent (au même niveau que description, unit…) et transformées en reference tel que décrit dans la proposition 1A pour reference.

Il s'agit d'une adaptation d'une série de propositions pour reference (Variable), qui a été adoptée.

MattiSG · 2021-09-09T15:14:53Z

Version 1A d'une proposition pour `documentation` (métadonnée de Paramètre)

Conserver la métadonnée telle quelle.

Type : texte libre.
Objet : explications générales, extension des acronymes, références législatives plus larges que des valeurs spécifiques.
Échelle de déclaration : nœud metadata d'un Paramètre.
Cas d'usage :
- Ajouter une note en bas de chaque fichier Excel des barèmes IPP.
Exemples :
- À partir de 2014, des seuils spécifiques (célibataire, couple) sont employés pour le calcul de la décote.

Notes :
(i) La taxe d'apprentissage est créée par la Loi de finances du 13 juillet 1925.
La loi 77-704 du 05/07/1977créé une cotisation supplémentaire de 0,2% pour financer la formation en alternance; elle doit être versée de manière exceptionnelle en 1977.
Elle a été maintenue par la LFR pour 1978.
En 1990, la contribution supplémentaire de 0,10% est remplacée par une cotisation pérenne de 0,10% pour la formation en alternance.
(ii) Une incertitude subsiste sur le taux applicable en Alsace-Lorraine entre 1973 et 1978 inclus.
(iii) "La date d'effet correspond à la période de versement de la taxe. La taxe d'apprentissage et la CSA sont dues en N aux taux en vigueur en N sur les rémunérations versées en N.""
(iv) A l'heure actuelle (taxe payable en 2016, sur les rémunérations de 2015):
La taxe d'apprentissage et la CDA sont payées par toutes les entreprises assujetties à l'IR ou à l'IS; celles employant des apprentis en sont exonérées.
La CSA est due par les entreprises qui emploient moins d'un nombre-cible de "jeunes" et de travailleurs en alternance.
Le taux de CSA applicable varie à la fois avec la taille de l'entreprise et avec le pourcentage de salariés en alternance dans l'effectif annuel moyen de l'entreprise. Nous reportons ici uniquement le taux pour les entreprises de moins de 2000 salariés, dont les alternants, VIE et contrats CIFRE représentent moins de 1 % de l'effectif total de l'entreprise.
   Les autres taux sont, en 2019, de (art. 1609 quinvicies du CGI) :
   0,6 % (0,312 % en Alsace-Moselle) si le nombre de salariés titulaires d'un contrat de professionnalisation ou d’apprentissage et de jeunes accomplissant un VIE ou bénéficiant d'une CIFRE est inférieur à 1 % de l'effectif annuel moyen et si l'effectif total est supérieur à 2000 salariés ;
   0,2 % (0,104 % en Alsace-Moselle) si le nombre de salariés et de jeunes appartenant aux catégories susvisées est compris entre 1 et 2 % de l’effectif annuel moyen ;
   0,1 % (0,052 % en Alsace-Moselle) si le nombre de salariés et de jeunes appartenant aux catégories susvisées est compris entre 2 et 3 % de l’effectif annuel moyen ;
   0,05 % (0,026 % en Alsace-Moselle) si le nombre de salariés et de jeunes appartenant aux catégories susvisées est compris entre 3 et 5 % de l’effectif annuel moyen.
Sources :
Taxe d'apprentissage : CGI, art. 224 et s. et art. 140 A et s. de l'annexe I ; pour l'Alsace-Moselle, art. 1599 ter J.
CSA : CGI, art. 230 H puis (à partir de 2014, cf. Décret 2014-549, JO 2014-05-29) 1609 quinvicies

MattiSG · 2021-09-09T15:15:13Z

Version 1B d'une proposition pour `documentation` (métadonnée de Paramètre)

Abandonner l'ajout d'une telle métadonnée dans OpenFisca et privilégier l'usage des commentaires plutôt que d'une métadonnée dédiée pour les hypothèses d'implémentation, car celles-ci sont associées à l'implémentation (au code).

Pour le cas d'usage et exemples donnés (insérer une note dans les barèmes IPP), soit passer par une base de données externe à OpenFisca, soit générer les notes par l'extraction des commentaires, comme le permet par exemple ruamel.yaml.

Il s'agit de la proposition 1B pour Notes (métadonnée de variable), qui a été adoptée.

Sasha-Laniece · 2021-09-14T12:41:31Z

Bonjour @MattiSG , je ne vois pas les champs ux_name et last_review qui ont déjà été votés au printemps ? Tu confirmes que c'est parce qu'ils sont déjà acquis ?
@sandcha @DorineLam @benoit-cty @benjello

MattiSG · 2021-09-14T13:18:57Z

Sont encore en attente de rédaction :

date_parution_jo
unit (et threshold_unit, rate_unit, amount_unit pour les barèmes)
description_en
ux_name
last_review

Sasha-Laniece · 2021-09-20T17:23:44Z

Hello à tous,
Pour rassembler tous les éléments sur cette issue, et notamment les motivations des premières décisions, voici le lien de la toute première RFC du printemps (celle que vous avez vue à l'époque sur Slack #france-system): #1519
Le débat en cours ici est maintenant bien plus avancé, et clairement sur la forme c'était pas top, à l'époque on avait grandement besoin des compétences de @MattiSG ^^

MattiSG · 2021-10-11T12:16:23Z

Version 1A d'une proposition pour `date_parution_jo` (métadonnée de Paramètre)

Renommer les occurrences de official_journal_date en dates_journal_officiel, en les laissant dans le nœud metadata. Transformer les valeurs en un tableau de dates afin de gérer les références multiples.

Cela implique que l'ordre des références est signifiant. Cela semble pouvoir être garanti en chargeant le YAML avec Python. Cela implique également une charge cognitive car l'ordre de déclaration des références doit correspondre à l'index des dates_journal_officiel. Ceci est contre-intuitif pour un dictionnaire.

Nom :

- official_journal_date
- date_parution_jo
+ dates_journal_officiel

Type :

- date
+ tableau de dates

Objet :

- date de publication au JO (et non date d'effet) du ou des textes de loi référencés dans `reference:title` et `reference:href`.
+ dates de publication au JO (et non date d'effet) des textes de loi de la `reference`.

Échelle de déclaration : nœud metadata d'un Paramètre.
Cas d'usage :
- Identifier la loi de laquelle provient le paramètre.
Exemples :

- 2019-01-01: 2018-09-06
+ dates_journal_officiel: [ 2018-09-06 ]
- 2014-01-01: 2013-12-29; 2012-03-15
+ dates_journal_officiel: [ 2013-12-29, 2012-03-15 ]

Lieu de documentation : CONTRIBUTING.md (pas de normalisation dans Core).

MattiSG · 2021-10-11T12:17:41Z

Version 1B d'une proposition pour `date_parution_jo` (métadonnée de Paramètre)

Renommer les occurrences de official_journal_date en parutions_journal_officiel, en les laissant dans le nœud metadata. Le terme « date » n'a pas à apparaître dans le nom de la métadonnée puisque le type de valeur permet de l'inférer. Transformer les valeurs en un dictionnaire de dates dont les clés doivent correspondre aux clés de reference afin de gérer les références multiples.

Cela implique la duplication des clés dans reference et dans parutions_journal_officiel. Un validateur automatique de l'identité entre les deux groupes de clé pourra aider.

Nom :

- official_journal_date
- date_parution_jo
+ parutions_journal_officiel

Type :

- date
+ dictionnaire dont les clés sont les mêmes que celles de la `reference`, et les valeurs sont des dates

Objet :

- date de publication au JO (et non date d'effet) du ou des textes de loi référencés dans `reference:title` et `reference:href`.
+ dates de publication au JO (et non date d'effet) des textes de loi de la `reference`.

Échelle de déclaration : nœud metadata d'un Paramètre.
Cas d'usage :
- Identifier la loi de laquelle provient le paramètre.
Exemples :

- 2019-01-01: 2018-09-06
+ parutions_journal_officiel:
+   Décret du 6 septembre 2018: 2018-09-06
- 2014-01-01: 2013-12-29; 2012-03-15
+ parutions_journal_officiel:
+   Circulaire ministérielle du 29 décembre 2013: 2013-12-29
+   Loi Mirlade: 2012-03-15

Lieu de documentation : CONTRIBUTING.md (pas de normalisation dans Core).

MattiSG · 2021-10-11T12:19:08Z

Version 1C d'une proposition pour `date_parution_jo` (métadonnée de Paramètre)

Abandonner l'ajout d'une telle métadonnée dans OpenFisca, car l'information de date de publication peut être stockée dans l'intitulé de reference et obtenue automatiquement depuis l'URL de reference, et que la valeur ajoutée pour désambiguer n'est pas claire. En particulier, la gestion des reference multiples ajoute une complexité significative à date_parution_jo.

MattiSG · 2021-10-11T12:24:28Z

Version 1A d'une proposition pour `description_en` (métadonnée de Paramètre)

Renommage en label_en, ajout d'une limite de caractères et d'une contrainte d'unicité dans le système socio-fiscal.

Nom :

- description_en
+ label_en

Type :

- texte libre (anglais)
+ langage naturel en anglais limité à 420 caractères, sur une seule ligne, sans espace en début ni fin

Objet : nom du paramètre en anglais.
Échelle de déclaration : nœud metadata d'un Paramètre.
Cas d'usage :
- Générer la version anglaise du site de l'IPP.
Exemples :
- Apprenticeship tax (tax for the financing of apprenticeship)
- Other payroll and workforce taxes
Lieu de documentation : CONTRIBUTING.md (pas de normalisation dans Core).

MattiSG · 2021-10-11T12:25:58Z

Version 1B d'une proposition pour `description_en` (métadonnée de Paramètre)

Gestion multilingue optionnelle des label : la clé label peut être un dictionnaire qui contient pour clé un code ISO de langue et pour valeur la description du paramètre dans la langue désignée. Une valeur par défaut est définie à l'échelle du système socio-fiscal, qui est attribuée en l'absence de clé explicite. Une limite de caractères et une contrainte d'unicité dans le système socio-fiscal sont ajoutées pour toutes les langues.

Nom :

- description_en
+ label

Type :

- texte libre (anglais)
+ dictionnaire dont les clé sont des codes ISO régionaux, et les valeurs sont des chaînes de caractère en langage naturel dans la langue indiquée par la clé, limitées à 420 caractères, sur une seule ligne, sans espace en début ni fin

Objet :

- nom du paramètre en anglais.
+ nom du paramètre dans une autre langue.

Échelle de déclaration :

- nœud `metadata` d'un Paramètre
+ Paramètre

Cas d'usage :
- Générer la version anglaise du site de l'IPP.
Exemples :

- Apprenticeship tax (tax for the financing of apprenticeship)
+ label:
+   fr: Taxe d'apprentissage
+   en: Apprenticeship tax (tax for the financing of apprenticeship)

- Other payroll and workforce taxes
+ label:
+   fr: Taxes et participations
+   en: Other payroll and workforce taxes

Lieu de documentation : Core.

MattiSG · 2021-10-11T12:26:13Z

Version 1C d'une proposition pour `description_en` (métadonnée de Paramètre)

Abandonner l'ajout d'une telle métadonnée dans OpenFisca, car les cas d'usage sont trop spécifiques. Les implémenteurs peuvent constituer leur propre base de traduction en dehors d'OpenFisca, en associant le nom du Paramètre avec ses traductions dans les langues souhaitées.

MattiSG · 2021-10-11T12:28:05Z

Version 1A d'une proposition pour `last_reviewed` (métadonnée de Paramètre)

Abandonner l'ajout d'une telle métadonnée dans OpenFisca, en raison de l'impossibilité de donner du sens à une date de revue.

Les informations de relecture pourraient faire l'objet d'un traitement dans un outil tiers, qui associerait un identifiant OpenFisca à un nombre arbitraire d'auditeurs qui pourraient indiquer leur validation de l'identifiant, la date, et le numéro de version du système socio-fiscal qui a fait l'objet de la validation.

Il s'agit d'une adaptation de la proposition 1B pour last_reviewed (Variable), qui a été adoptée.

MattiSG · 2021-10-11T12:30:30Z

Version 1A d'une proposition pour `ux_name` (métadonnée de Paramètre)

On introduit une métadonnée dédiée short_label en considérant que le besoin d'un nom non-ambigu avec un nombre connu de caractères est suffisamment répandu. On suppose qu'un contexte de présentation permettra de différencier entre deux paramètres ayant le même short_label.

Il s'agit d'une adaptation de la proposition 1A pour ux_name (Variable), qui a été adoptée.

Nom :

- ux_name
+ short_label

Type :

- texte libre avec un nombre court de caractères.
+ langage naturel limité à 70 caractères, sur une seule ligne, sans espace en début ni fin.

Objet : nom court du paramètre, autorisant les abréviations les plus connues.
Échelle de déclaration :

- nœud `metadata` d'un Paramètre
+ Paramètre

Cas d'usage :
- Afficher un nom reconnaissable par une personne non experte du modèle OpenFisca dans un espace d'affichage connu d'avance.
- Faciliter la construction d'interfaces graphiques en ayant une contrainte connue de taille d'affichage.
Exemples :
- Taxes et participations
- Fonds national d'aide au logement (FNAL)
Lieu de documentation : openfisca.org/doc (les cas d'usage mentionnés nécessitent d'exposer cette information dans l'API web, il faudra donc modifier Core). Afin de supporter des langues différentes, le nombre et le type de caractères autorisés pourra faire l'objet d'une spécification par pays. La limite sera donc documentée dans CONTRIBUTING.md. Les conventions de rédaction (quels acronymes étendre…) seront documentées dans le CONTRIBUTING.md.

MattiSG · 2021-10-11T15:10:40Z

Version 1A d'une proposition pour `unit` (métadonnée de Paramètre)

On normalise les valeurs possibles pour cette métadonnée, et on la bascule dans le nœud metadata dans la mesure où il n'y a à ce stade aucun impact fonctionnel à son remplissage.
Les valeurs possibles sont décrites à la fois dans Core (currency, percentage…) et dans France (SMIC, PSS…).

Comme aujourd'hui, les changements d'unité dans un seul paramètre ne sont pas permis : en cas de changement de monnaie, par exemple, deux paramètres distincts devront être introduits.

Nom : unit
Type :

- texte libre
+ enum

Objet : décrire l'unité dans laquelle doit être interprétée la valeur déclarée.
Échelle de déclaration :

- Paramètre
+ nœud `metadata` d'un Paramètre

Cas d'usage :
- Afficher l'unité dans l'explorateur de législation.
- Éviter d'indiquer l'unité en texte libre dans le champ description.
Exemples :

- unit: currency
+ metadata:
+   unit: currency

- unit: /1
+ metadata:
+   unit: percentage

Lieu de documentation : openfisca.org/doc pour l'usage et la liste des types de base. Afin de supporter des unités spécifiques (valeur du SMIC, montant du plafond de la sécurité sociale…), les types spécifiques à la France seront déclarés dans OF-France.

MattiSG · 2021-10-11T15:11:40Z

Version 1B d'une proposition pour `unit` (métadonnée de Paramètre)

On normalise les valeurs possibles pour cette métadonnée, et on la bascule au même niveau que value pour permettre les changements d'unité dans une seule déclaration de paramètre.
Les valeurs possibles sont décrites à la fois dans Core (currency, percentage…) et dans France (SMIC, PSS…).

Cette proposition permet de gérer les changements d'unité, un cas connu étant le changement de monnaie (FRF → EUR), au prix d'une forte répétition de la déclaration des unités.

Nom : unit
Type :

- texte libre
+ enum

Objet : décrire l'unité dans laquelle doit être interprétée la valeur déclarée.
Échelle de déclaration :

- Paramètre
+ nœud de date de valeur d'un Paramètre

Cas d'usage :
- Afficher l'unité dans l'explorateur de législation.
- Éviter d'indiquer l'unité en texte libre dans le champ description.
Exemples :

- unit: currency
+ values:
+   2019-01-01:
+     unit: currency

- unit: /1
+ values:
+   2019-01-01:
+     unit: percentage

Lieu de documentation : openfisca.org/doc pour l'usage et la liste des types de base. Afin de supporter des unités spécifiques (valeur du SMIC, montant du plafond de la sécurité sociale…), les types spécifiques à la France seront déclarés dans OF-France.

MattiSG · 2021-10-11T15:11:56Z

Version 1C d'une proposition pour `unit` (métadonnée de Paramètre)

Abandonner l'ajout d'une telle métadonnée, car elle n'a toujours pas à ce stade trouvé d'usage fonctionnel. Si l'interprétation est ambigüe, il est toujours possible de l'indiquer par un commentaire dans le code ou dans la description du Paramètre. C'est d'ailleurs le plus souvent déjà le cas aujourd'hui.

MattiSG · 2021-10-11T15:13:04Z

Version 1A d'une proposition pour `threshold_unit` (métadonnée de Paramètre)

On normalise les valeurs possibles pour cette métadonnée. Les valeurs possibles sont décrites à la fois dans Core (currency, percentage…) et dans France (SMIC, PSS…), et sont les mêmes que pour la métadonnée unit.

Comme aujourd'hui, les changements d'unité dans un seul paramètre ne sont pas permis : en cas de changement de monnaie, par exemple, deux paramètres distincts devront être introduits.

Nom : threshold_unit
Type :

- texte libre
+ enum

Objet : décrire l'unité dans laquelle doit être interprétée la valeur déclarée.
Échelle de déclaration :

- Paramètre
+ nœud `metadata` d'un Paramètre

Cas d'usage :
- Afficher l'unité dans l'explorateur de législation.
- Éviter d'indiquer l'unité en texte libre dans le champ description.
Exemples :
- threshold_unit: currency

- threshold_unit: /1
+ threshold_unit: percentage

Lieu de documentation : openfisca.org/doc pour l'usage et la liste des types de base. Afin de supporter des unités spécifiques (valeur du SMIC, montant du plafond de la sécurité sociale…), les types spécifiques à la France seront déclarés dans OF-France.

MattiSG · 2021-10-11T15:13:35Z

Version 1B d'une proposition pour `threshold_unit` (métadonnée de Paramètre)

On normalise les valeurs possibles pour cette métadonnée, et on la bascule au même niveau que value pour permettre les changements d'unité dans une seule déclaration de paramètre. Elle est de fait renommée en unit puisque le contexte d'interprétation (threshold ou rate) peut être lu dans la hiérarchie de déclaration.
Les valeurs possibles sont décrites à la fois dans Core (currency, percentage…) et dans France (SMIC, PSS…), et sont les mêmes que pour la métadonnée unit.

Nom :

- threshold_unit
+ unit

Type :

- texte libre
+ enum

Objet : décrire l'unité dans laquelle doit être interprétée la valeur déclarée.
Échelle de déclaration :

- nœud metadata d'un Paramètre
+ nœud de date de valeur d'un threshold de barème d'un Paramètre

Cas d'usage :
- Afficher l'unité dans l'explorateur de législation.
- Éviter d'indiquer l'unité en texte libre dans le champ description.
Exemples :

- metadata:
-   threshold_unit: SMIC
+ threshold:
+    1967-10-01:
+      unit: SMIC

- metadata:
-   threshold_unit: /1
+ threshold:
+   1984-04-01:
+     unit: percentage

Lieu de documentation : openfisca.org/doc pour l'usage et la liste des types de base. Afin de supporter des unités spécifiques (valeur du SMIC, montant du plafond de la sécurité sociale…), les types spécifiques à la France seront déclarés dans OF-France.

MattiSG · 2021-10-11T15:13:54Z

Version 1C d'une proposition pour `threshold_unit` (métadonnée de Paramètre)

Abandonner l'ajout d'une telle métadonnée, car elle n'a toujours pas à ce stade trouvé d'usage fonctionnel et est peu renseignée dans la base de code actuelle. Si l'interprétation est ambigüe, il est toujours possible de l'indiquer par un commentaire dans le code ou dans la description du Paramètre. C'est d'ailleurs le plus souvent déjà le cas aujourd'hui.

MattiSG · 2021-11-23T21:45:32Z

Point d'étape

À la suite de la discussion synchrone du 23/11/2021, voici un point d'étape sur la RFC, les zones de consensus et celles de dissensus.

État des propositions

Consensus émergent

`description`

Consensus clair sur 1A :

Renommage en label, ajout d'une limite de caractères et d'une contrainte d'unicité dans le système socio-fiscal.

`date_parution_jo`

Consensus pour la suppression.

`ux_name`

Soutien fort pour l'ajout, notamment par mimétisme avec les Variables.
Les cas d'usage ayant été explicités ce matin, @bfabre01, souhaites-tu mettre à jour ton vote ? 🙂

Consensus sur une approche, spécificités à arbitrer

`reference` / `reference.href` / `reference.title`

Consensus clair sur le passage à un dictionnaire dans reference, sur le modèle des Variables.

Reste à arbitrer les niveaux auxquels une déclaration de reference est valide :

1A : racine du paramètre.
1B : racine du paramètre ou value.
1C me semble être, sauf erreur de ma part, un doublon de 1B. @bfabre01 peux-tu confirmer cela s'il-te-plaît ? 🙂
1D : racine du paramètre ou value ou n'importe quel nœud parent dans l'arbre du paramètre.

`unit` (et `threshold_unit` et `rate_unit` pour les barèmes)

Soutien pour le maintien, avec déplacement dans le nœud metadata et en normalisant les valeurs possibles.

Point principal de surprise pour moi : un dissensus sur le renommage de rate_unit en unit (proposition 1C). @sandcha peux-tu nous expliquer ta position sur le sujet ? 🙂

Consensus limité

`documentation`

Pas de consensus clair. Le cas d'usage principal connu semble être pour l'IPP, mais les upvotes pour la conservation semblent provenir d'autres contributeurices. Merci de mettre à jour vos votes si vous soutenez la conservation sur la base d'hypothèses de besoin de l'IPP plutôt que sur vos propres besoins 😉
Si vous êtes neutres (i.e. ne voulez pas bloquer le maintien pour ne pas impacter négativement l'« harmonisation » mais n'avez pas d'usage propre), je vous recommande d'exprimer cette neutralité avec 👀 plutôt qu'avec 👍.

`description_en`

Pas de consensus clair. Le cas d'usage principal connu semble être pour l'IPP, mais les upvotes pour la conservation semblent provenir d'autres contributeurices. Merci de mettre à jour vos votes si vous soutenez la conservation sur la base d'hypothèses de besoin de l'IPP plutôt que sur vos propres besoins 😉
Si vous êtes neutres (i.e. ne voulez pas bloquer le maintien pour ne pas impacter négativement l'« harmonisation » mais n'avez pas d'usage propre), je vous recommande d'exprimer cette neutralité avec 👀 plutôt qu'avec 👍.

`last_review`

Ces propositions ne sont plus soutenues par leurs auteurs, qui souhaitent les remplacer par last_value_still_valid_on. @Sasha-Laniece @DorineLam @benoit-cty pouvez-vous mettre à jour vos votes svp ? 🙂

`last_value_still_valid_on`

Cette proposition est récente, la discussion reste à mener.

Suite

Trois pistes ont été évoquées en discussion synchrone pour avancer sur la normalisation des métadonnées des paramètres :

@bfabre01 : Finaliser la RFC telle quelle.
@Sasha-Laniece : L'éclater en ouvrant une RFC sur les propositions sur lesquelles un consensus n'a pas encore été clairement obtenu. En l'état, cela donnerait last_value_still_valid_on, les niveaux de déclaration de reference, le maintien de documentation et le maintien de description_en.
@eraviart : Laisser le champ libre à l'expérimentation et revenir sur ce sujet dans quelques mois, une fois l'« harmonisation » terminée.

Pour ma part, vu l'énergie déjà investie, le temps déjà écoulé, le besoin de clarté pour la création d'outils (validateurs et réutilisations), et la nécessité de trouver un fonctionnement qui puisse être répliqué pour d'autres contributeurices, je suis clairement en faveur de finaliser cette RFC afin de pouvoir avancer sur tous les autres points qui en découleront, et qui sont nombreux.

Je propose donc de :

Retrouver les délais d'expiration prévus initialement, soit 14 jours à partir du moment où le jeu de propositions est stable (i.e. pas de nouvelle proposition). En l'état, cette RFC serait donc close le jeudi 2 décembre.
D'ici-là, que chaque contributeurice mette à jour ses votes si la discussion synchrone l'a fait changer d'avis.
De continuer la discussion sur last_value_still_valid_on si un consensus clair ne se dégage pas à travers les votes. Les échanges asynchrones sont bienvenus, et je peux aussi faciliter une telle discussion synchrone si le besoin s'en fait sentir 🙂

En l'état, chaque implémenteur / réutilisateur est libre de commencer à baser son travail sur les points consensuels ou d'attendre la clôture de la RFC pour avoir plus de certitude.

Niveau d'obligation

Comme @sandcha l'a fait remarquer, toutes les propositions listées ici n'indiquent pas si la métadonnée qu'elles représentent doit obligatoirement être remplie ou non.

Dans tous les cas, on distinguera le traitement du flux (les nouvelles contributions) du traitement du stock (la base de données existante). Vu le taux de remplissage du stock, il me semble irréaliste de demander un remplissage systématique même pour les métadonnées « obligatoires ». Je propose que l'on utilise la définition ci-dessous de « obligatoire ».

Rendre une métadonnée obligatoire implique de :

Changer les règles d'acceptation des PR ajoutant des paramètres (on n'accepte que les ajouts de paramètres qui ont ces métadonnées renseignées). Cette validation peut être faite automatiquement en CI.
Pour des raisons techniques de mise en œuvre de la validation automatique, et afin d'améliorer progressivement la base, les PR qui modifient des paramètres doivent également renseigner toutes les métadonnées obligatoires.
Toute PR ajoutant des métadonnées obligatoires sans autre changement fonctionnel sont bienvenues.

Cela devrait mener à une hausse progressive mais systématique du taux de remplissage de ces métadonnées.

reference : obligatoire
unit, threshold_unit, rate_unit : optionnel
last_value_still_valid_on : optionnel
documentation : au mieux de ma compréhension, par définition optionnel
date_parution_jo : au mieux de ma compréhension, par définition obligatoire
description : indéterminé
description_en : indéterminé
short_label : indéterminé

Afin de conserver un mode de prise de décision unique, je prévois de créer pour chaque proposition dont le statut d'obligation est indéterminé une variante la rendant obligatoire, et les votes pourront se répartir en fonction.
Toute personne ayant une compréhension différente de la mienne de ce qui est « par définition » optionnel ou obligatoire est bienvenue pour créer des variantes précisant ce statut 👍

Merci à tou‧te‧s pour votre participation à ce processus un peu long mais profondément utile pour la pérennité de nos efforts communs ☺️

MattiSG · 2021-11-23T21:45:51Z

Version 2A d'une proposition pour `description` (métadonnée de Paramètre)

Renommage en label, ajout d'une limite de caractères et d'une contrainte d'unicité dans le système socio-fiscal, présence obligatoire.

Il s'agit de la proposition 1A, avec pour seul changement la présence obligatoire.

Le taux de remplissage actuel de cette métadonnée est de 60,7%.

Cette valeur est obtenue par :

curl 'https://api.fr.openfisca.org/latest/parameters' > parameters-fr.json
node

const params = Object.entries(require('./parameters-fr.json')).map(pair => pair[1])
params.filter(entry => entry.description).length / params.length

MattiSG · 2021-11-23T21:46:06Z

Version 2A d'une proposition pour `description_en` (métadonnée de Paramètre)

Renommage en label_en, ajout d'une limite de caractères, d'une contrainte d'unicité dans le système socio-fiscal et d'une obligation de présence.

Il s'agit de la proposition 1A, avec pour seul changement la présence obligatoire.

Le taux de remplissage actuel de cette métadonnée est d'environ 19%.

Cette valeur est obtenue par :

grep --no-filename -R 'description_en' openfisca_france/parameters/ | wc -l  # 410, nombre total = 2155

MattiSG · 2021-11-23T21:46:22Z

Version 2A d'une proposition pour `ux_name` (métadonnée de Paramètre)

On introduit une métadonnée obligatoire dédiée short_label en considérant que le besoin d'un nom non-ambigu avec un nombre connu de caractères est suffisamment répandu. On suppose qu'un contexte de présentation permettra de différencier entre deux paramètres ayant le même short_label.

Il s'agit de la proposition 1A, avec pour seul changement la présence obligatoire.

Le taux de remplissage actuel de cette métadonnée est d'environ 20,6%.

Cette valeur est obtenue par :

grep --no-filename -R 'ux_name' openfisca_france/parameters/ | wc -l  # 444, nombre total = 2155

Sasha-Laniece · 2021-11-29T08:53:09Z

Hello ! Petite remarque suite au récap ci-dessus, je crois qu'il y a eu une lecture un peu rapide pour date_parution_jo : il n'y a pas de consensus pour la suppression. Pour l'instant (avant la 2e serie de votes), on est à 2 contre 1.

De plus, puisqu'il a été convenu que notre objectif final est d'harmoniser, nous n'avons pas encore défini si nous pouvions supprimer ce champ définitivement, et si ce n'est pas le cas, quelles seraient les modalités mises en place pour le remplacer (pipeline?) sans arrêter net cet effort de convergence.

sandcha · 2021-12-01T16:25:42Z

En réponse au commentaire de point d'étape cc @MattiSG :

Point principal de surprise pour moi : un dissensus sur le renommage de rate_unit en unit (proposition 1C). @sandcha peux-tu nous expliquer ta position sur le sujet ? 🙂

On évoque le renommage de la clef rate_unit en unit dans le contexte d'un barème et il me semble que cela introduit un risque de confusion pour deux raisons :

les barèmes couvrent un mécanisme de calcul et on peut se demander si unit n'est pas l'unité du résultat de l'application du barème là où rate_unit est explicite,
il y a aussi des barèmes à montant qui ont un amount_unit et je comprends que si on supprime rate_ à rate_unit, on supprimera par cohérence aussi amount_ à amount_unit. Or ce mot me semble faciliter la compréhension de l'unité. En son absence, il faut déduire cette information du type du barème.

Les amount scales ont été évoqués ici puis omis dans la RFC mais il me semble que ce qui vaut pour les "rate scales" vaut pour les "amount scales".

Ce dernier message me fait réaliser que le champ type des barèmes manque à l'appel. Il permet de distinguer entre les barèmes simples/marginaux + à taux/à montants [la doc est exhaustive à ce sujet]. Je ne crois pas que ce champ pose question à ce jour mais c'est une information nécessaire à l'identification des barèmes marginaux donc nous ne voudrions pas la perdre.

Sasha-Laniece · 2021-12-01T16:37:48Z

Hello ! Suite aux discussions de mardi, nous proposons au vote les nouvelles options dont il a été question :

Sasha-Laniece · 2021-12-01T16:38:22Z

Version 2A d'une proposition pour `unit` (métadonnée de Paramètre)

On normalise les valeurs possibles pour cette métadonnée, et on la bascule dans le nœud metadata.
On autorise un format de dictionnaire si l’unité change avec le temps pour ce paramètre.

Cela concernait alors tous les champs de type unit, y compris ceux des barèmes.

Nom : unit

- Objet : décrire l'unité dans laquelle doit être interprétée la valeur déclarée.
- Échelle de déclaration :
```diff
- Paramètre
+ nœud `metadata` d'un Paramètre

Cas d'usage :
- Afficher l'unité dans l'explorateur de législation ou autres produits.
- Éviter d'indiquer l'unité en texte libre dans le champ description.
Exemples :

- unit: /1
+ metadata:
+   unit: percentage

- unit: currency
+ metadata:
+   unit: 
+      0001-01-01 : currency-fr
+      2001-01-01 : currency-eur

Lieu de documentation : openfisca.org/doc pour l'usage et la liste des types de base. Afin de supporter des unités spécifiques (valeur du SMIC, montant du plafond de la sécurité sociale…), les types spécifiques à la France seront déclarés dans OF-France.

Sasha-Laniece · 2021-12-01T16:38:31Z

Version 2A d'une proposition pour `threshold_unit` (métadonnée de Paramètre)

Tout comme la proposition 2A de unit : normalisation, nœud metadata, possibilité d’un dictionnaire pour gérer les changements d’unité.

Sasha-Laniece · 2021-12-01T16:39:34Z

Version 2A d'une proposition pour `reference` (métadonnée de Paramètre)

On demande systématiquement un intitulé et une URL pour chaque référence législative, par le biais d'un dictionnaire plutôt que d'un tableau.
La référence minimale obligatoire est celle qui renvoie à la valeur du paramètre en un clic (Article). On peut ajouter en plus des arrêtés ou des décrets.
Toutes les déclarations sont faites au niveau du nœud value/date. Cette proposition s’associe à la proposition 2A pour official_journal_date

Nom : reference
Type :

- texte libre, ou tableau de texte libre.
+ tableau associatif dont les clés sont des noms de textes légaux et les valeurs sont des URLs publiquement accessibles ou des chaînes vides.

Objet : référence légale, identifier la loi de laquelle provient le paramètre.
Échelle de déclaration : Value.
Cas d'usage :
- Vérifier la validité d'une formule en consultant son origine légale.
- Afficher l'intitulé de la source légale dans l'explorateur de législation.
Exemples :

- metadata :
- reference :
-  2021-01-01 :
-   title : Décret n°2020-769 du 24 juin 2020
-   href : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042032514

+ values :
+ 2021-01-01 :
+  value : 200
+  reference :
+    - "Article 2 du Décret n°2020-769 du 24 juin 2020: https://www.legifrance.gouv.fr/jorf/article_jo/JORFARTI000042032526/"
+      - "Décret n°2020-769 du 24 juin 2020: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042032514"

Sasha-Laniece · 2021-12-01T16:39:50Z

Version 2A d'une proposition pour `official_journal_date` (métadonnée de Paramètre)

On garde le nom official_journal_date pour éviter que ce soit le seul champ qui ne soit pas en anglais. On déplace les date dans le noeud value pour éviter les répétitions des clefs (et donc le risque d’erreur). S’il y a plusieurs publications par dates, on fait un tableau [2019-01-01, 2019-01-04].
Ce champ n’est pas obligatoire.
Cette proposition s’associe à la proposition 2A pour reference

Nom : official_journal_date
Objet : date de la publication dans le journal officiel
Échelle de déclaration : Value.
Cas d'usage :
- Pouvoir retrouver la publication dans le journal officiel
  Permettre l’harmonisation avec l'IPP
Exemples :

- metadata :
- official_journal_date :
-  2021-01-01 : 2020-12-21, 2020-12-01

+ values :
+ 2021-01-01 :
+  value : 200
+  reference :
+    - "Article 2 du Décret n°2020-769 du 24 juin 2020: https://www.legifrance.gouv.fr/jorf/article_jo/JORFARTI000042032526/"
+     - "Décret n°2020-769 du 24 juin 2020: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042032514”
+  official_journal_date : 2020-12-21
+ 2018-10-01 :
+  value : 190
+  reference :
+    - "Article 2 du Décret n°2020-769 du 24 juin 2018: https://www.legifrance.gouv.fr/jorf/article_jo/JORFARTI000042032526/"
+      - "Décret n°2020-769 du 24 juin 2020: https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000042032514”
+  official_journal_date : [2018-06-04, 2018-08-02]

Sasha-Laniece · 2021-12-01T16:41:10Z

De plus, pour régler la question des commentaires éparpillés dans les yaml, nous proposons 2 actions:

1 - De supprimer tous les commentaires

Car, pour permettre les scripts automatiques, il ne faut plus de commentaires dans les YAML
et....

Sasha-Laniece · 2021-12-01T17:03:58Z

...
2 - pour ne pas perdre l'information existante, on propose de mettre le contenu des commentaires actuels dans le champ notes

bfabre01 · 2021-12-02T11:07:51Z

@MattiSG : pour reference, en effet, 1B et 1C semblent être redondantes. Merci pour la remarque.

eraviart · 2023-01-19T10:56:49Z

Version 1A d'une proposition pour `documentation` et `notes` (métadonnée de Paramètre)

Le champ documentation est un texte libre, qui n'est pas lié à une date, qui peut être mis sur un nœud ou une feuille de l'arbre des paramètres. Il peut correspondre à une description du paramètre ou une définition ou une information métier. Pour éviter de dupliquer une documentation dans plusieurs paramètres, il est préférable de la mettre dans le parent commun.

Le champ notes est un texte libre qui est lié à une date et qui donc ne peut être mis que sur une feuille de l'arbre des paramètres. C'est une documentation en rapport avec une date de valeur.

Si une note concerne plusieurs paramètres elle doit être dupliquée pour chacun de ces paramètres.

Ces champs servent aussi à ne pas perdre ce qui était mis en commentaire dans les fichiers YAML, car maintenant les commentaires sont supprimés dans les phases de validation/conversion.

DorineLam · 2023-01-19T11:03:11Z

Version Journée de Contribution d'une proposition pour `description` (métadonnée de Paramètre) et pour `ux_name`

Description est renommé en label - Présence obligatoire
ux_name est renommé en short_label - Présence facultative

=> Il faut mettre la période quand il y a ambiguité, exemple "par mois"

Cas du `label` :

Objectif : Donner un nom au paramètre qui permet de comprendre rapidement ce qu'est le paramètre sans avoir forcément une vue du contexte.

Contraintes d'écriture :

Mettre le contexte du paramètre, le dispositif dans lequel il intervient, dispositif parent le plus connu.
Inutile de remonter à un parent trop général (exemple : impôt ou prélèvements sociaux)
Lors d'acronyme, toujours mettre le nom avant l'acronyme entre parenthèse.

Exemple : Taux de la contribution sociale généralisée (CSG)
Exemple : Montant de l'allocation d'adoption (AA)

Cas du `short_label` :

Le contexte est donné et donc c'est le label le plus court possible. Pas besoin de l'unité qui est déjà dans unit
Besoin de la période si elle n'est pas explicite.

Exemple : taux
Exemple d'exception :
Base mensuelle des allocations familiales (BMAF)

sandcha · 2023-01-19T11:21:09Z

Le bilan de l'atelier de contribution du jour sur le champ last_review revient à la proposition 1C de cette RFC.

DorineLam · 2023-01-19T14:55:36Z

Une issue de clôture de cette RFC est disponible ici. Elle fait suite à l'atelier de la journée de contribution OpenFisca France du 19 janvier 2023.

Sasha-Laniece · 2023-01-23T09:01:46Z

Je ferme cette issue car tout a été voté. Les actions de mise en place se poursuivent ici:

Partie non votée ici (les références) : Débat sur le formatage des références #2002
Clôture : Clôture de la RFC des paramètres #1998
Mise en place : L'Odyssée de la RFC 1672 #2001

MattiSG added the policy:RFC Request For Comments: chime in! label Sep 9, 2021

MattiSG self-assigned this Sep 9, 2021

MattiSG mentioned this issue Sep 9, 2021

Normalisation des métadonnées des variables #1618

Open

MattiSG mentioned this issue Sep 9, 2021

Corrections paramètres (unités des barèmes) #1664

Merged

7 tasks

sandcha mentioned this issue Sep 29, 2021

Ajoute l'allègement de cotisation maladie en place du CICE #1654

Merged

7 tasks

bfabre01 mentioned this issue Oct 6, 2021

Ajoute references et last_review pour la CSG et CRDS #1688

Merged

Sasha-Laniece mentioned this issue Dec 9, 2021

Réforme de l'ASI 2020 #1717

Merged

This was referenced Feb 3, 2022

Harmonisation - Prestations Sociales - minima_sociaux - RSA & RMI (Partie 8) #1784

Merged

Add label: str to allowed parameter attributes openfisca/openfisca-core#1100

Open

This was referenced May 5, 2022

Include bracket rates and thresholds in scale descendants openfisca/openfisca-core#1113

Open

Add metadata field for stocks/flows openfisca/openfisca-core#1104

Open

DorineLam mentioned this issue Jan 19, 2023

Clôture de la RFC des paramètres #1998

Open

Sasha-Laniece mentioned this issue Jan 19, 2023

L'Odyssée de la RFC 1672 #2001

Merged

Sasha-Laniece closed this as completed Jan 23, 2023

Sasha-Laniece reopened this Jan 23, 2023

Sasha-Laniece closed this as completed Jan 23, 2023

Sasha-Laniece mentioned this issue Jan 23, 2023

Bilan Studieuse 2023-01 #2003

Open

Normalisation des métadonnées des paramètres #1672

Normalisation des métadonnées des paramètres #1672

Comments

MattiSG commented Sep 9, 2021

RFC : normalisation des métadonnées des paramètres

Objet

Contexte, Nécessité, Processus…

MattiSG commented Sep 9, 2021

Version 0 d'une proposition pour description (métadonnée de Paramètre)

MattiSG commented Sep 9, 2021

Version 1A d'une proposition pour description (métadonnée de Paramètre)

MattiSG commented Sep 9, 2021 • edited Loading

Version 1A d'une proposition pour reference (métadonnée de Paramètre)

MattiSG commented Sep 9, 2021

Version 1A d'une proposition pour reference.href (métadonnée de Paramètre)

MattiSG commented Sep 9, 2021

Version 1A d'une proposition pour reference.title (métadonnée de Paramètre)

MattiSG commented Sep 9, 2021

Version 1A d'une proposition pour documentation (métadonnée de Paramètre)

MattiSG commented Sep 9, 2021

Version 1B d'une proposition pour documentation (métadonnée de Paramètre)

Sasha-Laniece commented Sep 14, 2021 • edited Loading

MattiSG commented Sep 14, 2021

Sasha-Laniece commented Sep 20, 2021

MattiSG commented Oct 11, 2021

Version 1A d'une proposition pour date_parution_jo (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021 • edited Loading

Version 1B d'une proposition pour date_parution_jo (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021

Version 1C d'une proposition pour date_parution_jo (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021

Version 1A d'une proposition pour description_en (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021

Version 1B d'une proposition pour description_en (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021

Version 1C d'une proposition pour description_en (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021

Version 1A d'une proposition pour last_reviewed (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021 • edited Loading

Version 1A d'une proposition pour ux_name (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021

Version 1A d'une proposition pour unit (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021

Version 1B d'une proposition pour unit (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021

Version 1C d'une proposition pour unit (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021

Version 1A d'une proposition pour threshold_unit (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021

Version 1B d'une proposition pour threshold_unit (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021

Version 1C d'une proposition pour threshold_unit (métadonnée de Paramètre)

MattiSG commented Nov 23, 2021

Point d'étape

État des propositions

Consensus émergent

description

date_parution_jo

ux_name

Consensus sur une approche, spécificités à arbitrer

reference / reference.href / reference.title

unit (et threshold_unit et rate_unit pour les barèmes)

Consensus limité

documentation

description_en

last_review

last_value_still_valid_on

Suite

Niveau d'obligation

MattiSG commented Nov 23, 2021

Version 2A d'une proposition pour description (métadonnée de Paramètre)

MattiSG commented Nov 23, 2021

Version 2A d'une proposition pour description_en (métadonnée de Paramètre)

MattiSG commented Nov 23, 2021

Version 2A d'une proposition pour ux_name (métadonnée de Paramètre)

Sasha-Laniece commented Nov 29, 2021

sandcha commented Dec 1, 2021 • edited Loading

Sasha-Laniece commented Dec 1, 2021

Sasha-Laniece commented Dec 1, 2021 • edited Loading

Version 2A d'une proposition pour unit (métadonnée de Paramètre)

Version 0 d'une proposition pour `description` (métadonnée de Paramètre)

Version 1A d'une proposition pour `description` (métadonnée de Paramètre)

MattiSG commented Sep 9, 2021 •

edited

Loading

Version 1A d'une proposition pour `reference` (métadonnée de Paramètre)

Version 1A d'une proposition pour `reference.href` (métadonnée de Paramètre)

Version 1A d'une proposition pour `reference.title` (métadonnée de Paramètre)

Version 1A d'une proposition pour `documentation` (métadonnée de Paramètre)

Version 1B d'une proposition pour `documentation` (métadonnée de Paramètre)

Sasha-Laniece commented Sep 14, 2021 •

edited

Loading

Version 1A d'une proposition pour `date_parution_jo` (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021 •

edited

Loading

Version 1B d'une proposition pour `date_parution_jo` (métadonnée de Paramètre)

Version 1C d'une proposition pour `date_parution_jo` (métadonnée de Paramètre)

Version 1A d'une proposition pour `description_en` (métadonnée de Paramètre)

Version 1B d'une proposition pour `description_en` (métadonnée de Paramètre)

Version 1C d'une proposition pour `description_en` (métadonnée de Paramètre)

Version 1A d'une proposition pour `last_reviewed` (métadonnée de Paramètre)

MattiSG commented Oct 11, 2021 •

edited

Loading

Version 1A d'une proposition pour `ux_name` (métadonnée de Paramètre)

Version 1A d'une proposition pour `unit` (métadonnée de Paramètre)

Version 1B d'une proposition pour `unit` (métadonnée de Paramètre)

Version 1C d'une proposition pour `unit` (métadonnée de Paramètre)

Version 1A d'une proposition pour `threshold_unit` (métadonnée de Paramètre)

Version 1B d'une proposition pour `threshold_unit` (métadonnée de Paramètre)

Version 1C d'une proposition pour `threshold_unit` (métadonnée de Paramètre)

`description`

`date_parution_jo`

`ux_name`

`reference` / `reference.href` / `reference.title`

`unit` (et `threshold_unit` et `rate_unit` pour les barèmes)

`documentation`

`description_en`

`last_review`

`last_value_still_valid_on`

Version 2A d'une proposition pour `description` (métadonnée de Paramètre)

Version 2A d'une proposition pour `description_en` (métadonnée de Paramètre)

Version 2A d'une proposition pour `ux_name` (métadonnée de Paramètre)

sandcha commented Dec 1, 2021 •

edited

Loading

Sasha-Laniece commented Dec 1, 2021 •

edited

Loading

Version 2A d'une proposition pour `unit` (métadonnée de Paramètre)

Version 2A d'une proposition pour `threshold_unit` (métadonnée de Paramètre)

Version 2A d'une proposition pour `reference` (métadonnée de Paramètre)

Version 2A d'une proposition pour `official_journal_date` (métadonnée de Paramètre)

Sasha-Laniece commented Dec 1, 2021 •

edited

Loading

Version 1A d'une proposition pour `documentation` et `notes` (métadonnée de Paramètre)

DorineLam commented Jan 19, 2023 •

edited

Loading

Version Journée de Contribution d'une proposition pour `description` (métadonnée de Paramètre) et pour `ux_name`

Cas du `label` :

Cas du `short_label` :

Sasha-Laniece commented Jan 23, 2023 •

edited

Loading