Open MattiSG opened 3 years ago
Lors de l'échange synchrone du 02/08/2021, ainsi que sur Slack la semaine précédente, les remarque suivantes ont été portées. Ce travail de consolidation effectué par @MattiSG ne se substitue évidemment pas aux remarques portées directement par les personnes concernées dans cette discussion, et n'a pas vocation à limiter l'étendue des discussions, simplement à donner du contexte et à simplifier le suivi des échanges 🙂
@bfabre01 : se limiter à ce qui relève du choix de modélisation (hypothèses retenues…) dans le code.
Je trouve qu'un champ notes est nécessaire pour documenter les éventuels choix ou hypothèses de modélisation. En revanche, je ne pense pas qu'il faille y inclure systématiquement de descriptions de dispositifs. Pour moi, ça ne doit pas être l'objet du code, mais d'un précis de législation à part. Sinon, on risque de se retrouver avec plein de descriptions qui seront à la fois lourdes pour le code, mais aussi trop brèves pour être vraiment complètes. Quel serait le périmètre de ce champ par exemple ? L'intuition de la formule ? Le contexte de réaction ? Le contexte de suppression ? L'objectif du dispositif ? Sachant que ce dernier point est très subjectif. Après, il est possible qu'il y ait un besoin de description brèves de dispositifs dans le cadre d'une utilisation particulière. Mais dans ce cas, cela doit se faire à part selon moi, pour cette utilisation, mais pas dans le repo commun.
@MattiSG :
Je suis en défaveur d'un champ large et non normalisé comme notes . Ce genre de champ finit toujours par contenir des informations incohérentes et difficilement exploitables. Je recommande de privilégier des champs avec un objectif et un format clair et cadré, quitte à en introduire plusieurs. Dans le cas de choix de modélisation, et en l'absence de détails sur ce que cela signifie, je recommande l'usage de commentaires dans le code et non de métadonnées.
@DorineLam :
Actuellement il y a pas mal de contributeur ayant ajouté des informations en #commentaires. Pour ma part (je viens de faire ma première PR il y a 2 semaines) Ces informations en commentaires m’ont beaucoup aidé à comprendre les dispositifs.
À l'heure actuelle, il y a souvent des informations dans des commentaires (# commentaires) qui auraient leur place de manière plus explicite (et qui sont cachées à un user).
Je pense qu’il doit être rempli seulement pour mentionner une hypothèse importante sur laquelle la formule est fondée, ou un point important pour la compréhension de la formule. Mais je ne pense pas que l’on doive mettre une description systématique des dispositifs. Ça alourdirait beaucoup le code et si on met déjà le nom officiel et le ux_name, je pense que c’est suffisant pour que les utilisateurs ne connaissant pas le dispositif fasse une recherche sur le web.
ux_name
@pzuldp :
C'est un élément qu'on a déjà soulevé lors de discussions sur les barèmes ipp, et j'étais déjà pour, je suis heureux qu'il soit au programme. Ceci étant dit : quelqu'un.e avec plus de connaissances techniques que moi sera plus à même de juger, mais est-ce que c'est quelque chose qui n'est pas envisageable d'automatiser ? la date du dernier commit est-elle quelque chose de facilement mobilisable ?
@MattiSG : il s'agit de capturer une information actuellement invisible et qui a de la valeur : quelqu'un a confirmé qu'une implémentation était correcte. Actuellement, on ne voit que les cas où quelqu'un a relu et trouvé une erreur, à travers une issue et / ou une PR. Pour autant, je ne crois pas qu'une simple date de relecture apporte suffisamment. Je ne peux pas avoir plus confiance dans une simple date anonyme : ai-je confiance dans la qualité de la relecture de la personne qui a relu ? Je suis donc plus en faveur d'une « trace d'audits » où chaque entité ayant fait une relecture indique quand et sur quelle étendue.
@bfabre01 : une relecture anonyme ne semble pas appropriée, il faut prendre des responsabilités.
Dans l'espoir de faciliter la discussion, je sépare les propositions pour chaque métadonnée dans des commentaires séparés, afin que chacun·e puisse réagir avec :+1: (la proposition me convient), :-1: (la proposition ne m'est pas acceptable, je fais une contre-proposition en commentaire), ou :eyes: (j'ai lu et je n'ai pas d'avis).
Afin de participer à ce fonctionnement, qui me semble le moins mauvais qu'on puisse avoir tant qu'on utilise une issue GitHub pour prendre des décisions, merci d'utiliser déjà cette convention de réaction sur ce premier message :wink: une contre-proposition de processus est bienvenue.
reference
(métadonnée de Variable)Dans cette proposition, on restreint les références à des URLs, en supposant que les intitulés peuvent être reconstruits automatiquement par l'accès aux documents, et que leur valeur ajoutée est trop faible par rapport au coût de maintenance. Cela pose un problème à résoudre par une convention pour les cas de documents non publiquement accessibles.
reference
(métadonnée de Variable)~Cette proposition a été remplacée par la proposition 2A.
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
.
Abandonner l'ajout d'une telle métadonnée dans OpenFisca, en raison des risques soulignés dans https://github.com/openfisca/openfisca-france/issues/1618#issuecomment-891818665.
Implémenter cette métadonnée sous la forme d'un booléen associé à une Formule, en la renommant en inaccurate
afin d'inclure les cas où la formule n'est pas obsolète mais fausse, car la distinction entre une absence de mise à jour et une mauvaise prise en compte des mises à jour précédentes est impossible à faire formellement.
Les processus de validation et de traitement associés face à une formule « inaccurate » restent à définir avant que cette proposition puisse être considérée comme complète.
On stocke simplement une date de dernière revue, en s'appuyant sur les métadonnées d'auteur de commit pour savoir qui est à l'origine de la relecture (en supposant que la modification n'est pas faite par le biais d'un outil permettant l'édition anonyme, ce qui semble être le cas d'usage principal proposé par LexImpact). Les modalités de revue d'un tel changement ne sont pas définies.
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.
On stocke un dictionnaire de dates et de relecteurs pour chaque formule, afin de créer une trace d'audit.
Les modalités de revue d'un tel changement ne sont pas définies.
On enregistre la date à laquelle la ressource web a été consultée pour servir de référence à l'implémentation.
Abandonner l'ajout d'une telle métadonnée dans OpenFisca, en raison des cas d'usage limités (comment revenir en arrière sur le document pointé ? combien d'URLs de références changent réellement dans le temps ?).
Ajouter une convention dans le CONTRIBUTING.md
: si l'URL ne pointe pas vers un document stable dans le temps (par exemple lien vers service-public.fr au lieu de legifrance.gouv.fr), ajouter un commentaire indiquant la date de consultation à la fin de la ligne donnant le lien vers la référence.
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
.
Il s'agit de la Proposition 1B pour reference
.
On ajoute une métadonnée spécifique optionnelle. Ceci implique que certaines variables pourront avoir une URL mais pas de libellé, et inversement.
On s'appuie sur les reference
existantes, en restreignant désormais les références à des URLs. Cela pose un problème à résoudre par une convention pour les cas de documents non publiquement accessibles.
Il s'agit de la Proposition 1A pour reference
.
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
.
Il s'agit de la Proposition 1B pour reference
.
On ajoute une métadonnée spécifique optionnelle. Ceci implique que certaines variables pourront avoir une URL mais pas de libellé, et inversement. La métadonnée générique reference
serait retirée.
Les choix de modélisation (hypothèses retenues…) sont stockés dans une métadonnée dédiée.
Les exemples et cas d'usage donnés sont incohérents avec l'objet identifié lors de la discussion. Il faudrait donner de nouveaux exemples pour que cette proposition soit cohérente.
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) et ne décrivent pas la variable du point de vue métier / économique.
Pour le cas d'usage et exemples donnés (Afficher une infobulle au survol du nom d'une variable), passer par une base de données externe à OpenFisca, comme le fait Mes Aides pour l'affichage d'informations supplémentaires dans l'accès aux aides sociales.
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 variables ayant le même short_label
.
Les valeurs actuellement renseignées sont disponibles ci-dessous :
En l'état, on note que :
La plus longue valeur (Cotisations retraites exceptionnelle et temporaire (CET) (1997-2018)
) fait 68 caractères.
Un grand nombre de valeurs sont répétées (exemple : Taux
).
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. Cette proposition diffère de la 1A car elle rend obligatoire l'unicité du nom court utilisé.
Les valeurs actuellement renseignées sont disponibles ci-dessous :
En l'état, on note que :
La plus longue valeur (Cotisations retraites exceptionnelle et temporaire (CET) (1997-2018)
) fait 67 caractères.
Un grand nombre de valeurs sont répétées (exemple : Taux
). Toutes ces valeurs devront être changées.
Abandonner l'ajout d'une telle métadonnée dans OpenFisca, car l'information est trop spécifique à des contraintes d'affichage données.
Chaque application cliente devrait passer par une base de données externe à OpenFisca pour définir les étiquettes qu'elle souhaite afficher à ses utilisateurs, sur la base de l'identifiant de la variable dans OpenFisca.
label
(métadonnée de Variable)On conserve le fonctionnement actuel de label
, en raffinant simplement sa documentation et en introduisant une limite de caractères afin de permettre la validation automatique.
La distribution du nombre actuel de caractères des valeurs renseignées est disponible ci-dessous :
En l'état, le label
le plus long compte 412 caractères.
label
(métadonnée de Variable)Les label
restent sensiblement les mêmes, en raffinant simplement sa documentation et en introduisant une limite de caractères afin de permettre la validation automatique, mais doivent désormais être uniques dans le système socio-fiscal.
La liste des valeurs en doublon est disponible ci-dessous :
En l'état, l'immense majorité des valeurs en doublon sont dans le domaine des investissements outre-mer.
Version 1A d'une proposition pour Date du lien de l'URL de la description (métadonnée de Variable)
On enregistre la date à laquelle la ressource web a été consultée pour servir de référence à l'implémentation.
* Nom : `reference_date` * Type : date. * Objet : indiquer la date à laquelle un contributeur a lu le texte de référence qui a guidé son implémentation. * Échelle de déclaration : même que `reference` (Variable en l'état, Formule d'après la proposition actuellement retenue). * Convention : les changements ne sont autorisés que lors de la création ou la modification d'une Formule, et la valeur doit correspondre à peu de jours près à celle des commits associés. * Cas d'usage : * Tracer l'état des références utilisées lors d'une modélisation. * Exemples : * `2021-03-20` * `2000-01-01` * Lieu de documentation : openfisca.org/doc si elle est gérée dans Core, `CONTRIBUTING.md` sinon.
Je ne suis pas sûr de comprendre ce qu'apporte cette information par rapport à une date de parution au JO : la date de parution est une date "immuable" (plus stable que la "date" d'une loi, qui fait référence à la première version de la loi, qui souvent est modifié par d'autres textes, qui chacun ont une date de parution au JO spécifique). L'avantage par rapport à une autre source de référence étant que le JO est lui-même immuable. Il me semble que le seul cas d'usage est le suivant :
Version 1A d'une proposition pour UX Name (métadonnée de Variable)
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 variables ayant le mêmeshort_label
.Les valeurs actuellement renseignées sont disponibles ci-dessous :
En l'état, on note que :
* La plus longue valeur (`Cotisations retraites exceptionnelle et temporaire (CET) (1997-2018)`) fait 68 caractères. * Un grand nombre de valeurs sont répétées (exemple : `Taux`).
l'objectif ici est-il bien d'avoir un label unique au niveau du premier noeud au-dessus de chaque feuille ? (non-ambigu conditionnellement au chemin dans l'arbre emprunté jusqu'à un noeud / une feuille donnée ?)
Version 1B d'une proposition pour
reference
(métadonnée de Variable)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
.* Nom : `reference` * Type :
- texte libre, ou tableau de texte libre. + dictionnaire d'URLs.
* Objet : “a dictionary of legislative references, with legal text names as keys and URLs pointing to the relevant legislative references for this variable as values, when possible.”
- Variable. + Formule.
+ Convention : utiliser une version HTTPS, à moins que seul du HTTP soit disponible. + Convention : privilégier les URLs Légifrance, à défaut les adresses en .gouv.fr, à défaut service-public.fr, à défaut wikipédia. + Convention : utiliser les URLs ELI pour Légifrance. + Convention : utiliser les identifiants juridiques fournis par Légifrance ou le BOFIP comme clés.
* 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. + Afficher un lien vers la source légale dans l'explorateur de législation.
* ## Exemples :
- "http://bofip.impots.gouv.fr/bofip/1852-PGP" + { "BOI-IR-BASE-20-60-20": "https://bofip.impots.gouv.fr/bofip/1852-PGP" }
- reference = [ + reference = { - "Décret n°2020-371 du 30 mars 2020" - "https://www.legifrance.gouv.fr/eli/decret/2020/3/30/ECOI2007755D/jo/texte", + "Décret n°2020-371 du 30 mars 2020": "https://www.legifrance.gouv.fr/eli/decret/2020/3/30/ECOI2007755D/jo/texte", - "Ordonnance n° 2020-705 du 10 juin 2020" - "https://www.legifrance.gouv.fr/eli/ordonnance/2020/6/10/ECOI2012371R/jo/texte" + "Ordonnance n° 2020-705 du 10 juin 2020": "https://www.legifrance.gouv.fr/eli/ordonnance/2020/6/10/ECOI2012371R/jo/texte", - ] + }
* Lieu de documentation : openfisca.org/doc pour le format de données, `CONTRIBUTING.md` pour la manière de rédiger les références.
Il me semble que cette proposition pourrait inclure explicitement l'inclusion du cas d'une URL inexistante ? ce qui donnerait {"Loi n 01-12351 du 13 brumaire 1234" : NA} (où on remplacerait NA par une valeur "manquante" bien choisi ?) Ou bien est-ce qu'il s'agit d'empêcher une référence uniquement par l'intutilé de la législation ? En tout cas, il me semble qu'il y a, dans l'usage, une asymétrie : il est possible qu'un intitulé sans URL existe, mais l'inverse est plus rare.
Version 1A d'une proposition pour
Date du lien de l'URL
de la description (métadonnée de Variable)Je ne suis pas sûr de comprendre ce qu'apporte cette information par rapport à une date de parution au JO
Je suis d'accord. À mon sens il n'y a même pas d'intérêt à stocker la date de parution au JO dans la mesure où cette information peut être obtenue sur la page de destination de la reference
.
Il me semble que le seul cas d'usage est le suivant […] source "immuable" (type BO ou JO) n'est pas disponible pour une information + le contenu de la source disponible pour un paramètre donné peut potentiellement être modifié
C'est ce que je vois également.
Mais en l'état, je ne suis pas convaincu par la pertinence de l'approche. Une date seule n'apporte que peu d'information. Elle peut seulement permettre de savoir que l'information référencée est potentiellement obsolète, si l'URL de destination a une date de dernière modification.
Je serais plus en faveur de la création d'un outil qui enregistrerait dans une base de données dédiée l'intégralité des références à chaque mise à jour, et qui notifierait en cas de changement dans les pages référencées.
Version 1A d'une proposition pour UX Name (métadonnée de Variable)
l'objectif ici est-il bien d'avoir un label unique au niveau du premier noeud au-dessus de chaque feuille ?
Je ne sais pas, justement, d'où les propositions 1A et 1B qui diffèrent uniquement sur cet aspect. Je comprends que l'objectif est d'avoir un label non-ambigu dans une interface utilisateur. Cette non-ambiguité peut être obtenue par l'unicité, ou par des éléments dans l'interface. Je ne sais pas à quel point il est important de garantir la non-ambiguité au niveau du modèle ou si on peut faire l'hypothèse que l'éditorialisation côté réutilisateurs sera suffisamment bonne.
Version 1B d'une proposition pour
reference
(métadonnée de Variable)Il me semble que cette proposition pourrait inclure explicitement l'inclusion du cas d'une URL inexistante ?
Oui, c'était implicitement le cas car on peut laisser une chaîne vide, mais autant l'indiquer.
ce qui donnerait {"Loi n 01-12351 du 13 brumaire 1234" : NA} (où on remplacerait NA par une valeur "manquante" bien choisi ?)
Le plus simple serait d'avoir une chaîne vide ; on pourrait aussi imaginer une URI dédiée, mais ça me semble plus compliqué.
Ou bien est-ce qu'il s'agit d'empêcher une référence uniquement par l'intutilé de la législation ?
Non, ça me semble rarement légitime mais ça peut l'être, comme dans l'exemple que tu donnes.
il est possible qu'un intitulé sans URL existe, mais l'inverse est plus rare.
Tout à fait, d'où le choix du dictionnaire dans ce sens-là, où une clé vide ne peut pas être acceptée 🙂
Je fais une proposition v2 sur cette base, les votes respectifs pour la 1A et 1B donnant une direction claire 🙂
reference
(métadonnée de Variable)On demande systématiquement un intitulé et une URL (lorsqu'elle existe) 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
.
Le dernier commentaire demandant des clarifications date d'il y a 3 semaines, et les dernières propositions d'il y a 17 jours. Ce message tient lieu de relance avant clôture de la RFC à l'expiration du délai de 3 semaines, dans 4 jours (dimanche 05/09 à 14h34). Je vais également effectuer une relance pour participation sur le Slack 🙂
label
(métadonnée de Variable)Les label
restent les mêmes, avec deux contraintes supplémentaires : un nombre maximum de caractères et unicité dans le système socio-fiscal.
Les références seront désormais traitées de la manière suivante :
On demande systématiquement un intitulé et une URL (lorsqu'elle existe) pour chaque référence législative, par le biais d'un dictionnaire plutôt que d'un tableau.
Via les trois adoptions combinées ci-dessous.
reference
(métadonnée de Variable)⇒ 2A adoptée.
⇒ 1A adoptée.
⇒ 1B adoptée.
Les votes et discussions mènent à l'abandon de l'ajout des métadonnées suivantes.
⇒ 1A adoptée.
⇒ 1B adoptée.
⇒ 1B adoptée.
⇒ 1C (On stocke un dictionnaire de dates et de relecteurs pour chaque formule, afin de créer une trace d'audit.) est le plus consensuel, et 1B (Abandonner l'ajout d'une telle métadonnée dans OpenFisca.) le plus soutenu.
@Sasha-Laniece avait voté pour 1B et 1C et contre 1A, peut-on prévoir un échange pour déterminer une alternative convenable qui réponde à ton besoin ? 🙂 cc les autres personnes qui ont voté : @pzuldp @clallemand @benjello.
Le consensus est clairement en faveur de l'ajout de cette métadonnée, sous le nom short_label
. L'unicité de cette valeur n'est cependant pas décidée. @Sasha-Laniece peut-on prévoir un échange sur vos cas d'usage afin de déterminer si l'unicité serait utile ou non ? 🙂
Afin de faciliter la lecture de cette RFC déjà longue, et après consultation sur Slack, j'ai fait le choix d'éclater en deux parties : cette issue reste dédiée aux métadonnées des variables, et #1672 vise la normalisation des métadonnées des paramètres 🙂
En l'absence de retour de @Sasha-Laniece (relancée également sur Slack) d'ici la fin de semaine, je pense que nous arbitrerons pour privilégier les options les plus soutenues, sans ajustement particulier.
@MattiSG Je viens de voir la RFC suite à un message de relance de @Sasha-Laniece. Nous avons été pris par les développements ces dernières semaines qui s'intensifient. Cette RFC, notamment la suppression d'informations qui sont déjà présentent, nous met en risque du côté de l'interface utilisateur.
Est-il possible de décaler la date de clôture de cette RFC à après la sortie du PLF et du PLFSS ? Ou a minima de nous avertir de la date de mise en place de ces changements ?
Je suis désolée de cette réaction tardive, mais les mois d'août et septembre sont toujours hyper chargés de notre côté et je suis aussi moins présente sur github Openfisca.
Je suis désolé, cela fait déjà 7 semaines que cette RFC traîne et qu'il y a eu de nombreuses relances. La date de clôture était le 05/09. Je ne vois pas trop comment avancer si on peut rouvrir le processus de prise de décision systématiquement 😕
a minima de nous avertir de la date de mise en place de ces changements ?
Bien sûr, la version qui contiendra ces changements fera l'objet d'une version majeure et sera notifiée dans le changelog 🙂
[DRAFT]
Tout d’abord, merci pour ces RFC qui mettent au clair la situation actuelle et ce vers quoi nous nous dirigerions ensemble. Pardon pour le temps de réaction qui au-delà des contextes propres aux personnes (période estivale) ou aux équipes (pic d’activité LexImpact) est de mon point de vue en partie relié au fait que les questions des métadonnées et des RFC ont mis le doigt sur des difficultés qu’on n’a pas su expliciter à temps. En voici une ébauche de liste afin que nous puissions en discuter et qui a pour objet de partager une vision et avec l'espoir d’éviter à ce que cette situation ne se reproduise :
Plusieurs problèmes ont été traités sous le même intitulé :
Le point de départ était déjà un peu flou : openfisca-france avait un petit retard sur l’usage des metadata évoqué dans la documentation et dans les paramètres du country-template servant de base aux autres pays. Donc, le besoin de clarification des métadonnées était antérieur à l’harmonisation même s’il ne touchait qu’aux unit
et types de barèmes. Il ne semblait pas poser problème mais nécessitait une gestion des deux formats du côté d’openfisca-core ce qui aurait pu être une situation suffisante pour nous pousser à clarifier le format (Format qui diffère par ailleurs du côté de l’API Web destinée alors à d’autres usagers).
Une discussion ouverte et sur la durée sur GitHub ne vaut finalement pas RFC : L’harmonisation a appelé à la participation de tous mais cela a principalement mobilisé les deux équipes les plus concernées et cela n’a pas semblé être bloquant dans la mesure où le chantier était tel que le principe d’amélioration continue l’a emporté sur un retravail de la consultation (une formalisation en RFC comme ici ; une description de la méthode de définition de RFC a de la valeur).
Aujourd'hui, ceci qui a pour conséquence une perte potentielle d’information importante pour l’une des équipes qui a oeuvré à l’harmonisation (LexImpact en l’occurrence) sans que le risque n’ait été perçu pendant l’harmonisation où ces informations (last_review
en particulier) n’ont pas fait l’objet de rejet.
Un besoin exprimé par de multiples acteurs n’a pas été formalisé en issue + Le bilan du sondage n’a pas été partagé avec la communauté : Au-delà des équipes impliquées dans l’harmonisation, la communauté est régulièrement questionnée sur l’état de la modélisation (Est-elle complète ? Est-elle à jour ?). Cette information est aujourd’hui éparpillée dans la communauté française alors même que c’est un des points de croissance du produit identifié suite au sondage. Mea culpa à ce sujet en particulier. Le désaccord serait peut-être plus sur le format que sur le besoin de metadata.
Des caractéristiques des métadonnées ont peut-être manqué à l’appel : L’information est-elle uniformément accessible aux membres de la communauté ? Reconstituer l’information après coup est-il possible et à quel coût ? C’est du moins, me semble-il le problème posé en particulier pour last_review
et on peut néanmoins dire que la réponse à ces questions peut varier d’une métadonnée à une autre. Exemple : quel est le niveau de modélisation de l’impôt sur les plus values ? Les aides au logement sont-elles à jour ? Couvrent-elles toutes les situations ?
L’équipe LexImpact n’a au démarrage pas voté en partie parce qu’il a été pensé que :
Hello, merci pour ce retour @sandcha . Il y a plusieurs choses avec lesquelles, je ne suis pas d'accord:
Je comprends le problème que la perte de certaines informations peut causer pour l'équipe LexImpact. Mais je pense que le problème vient plus du fait d'avoir ajouté des métadonnées sans être passé par une délibération claire. Il est difficile à mon sens de soulever le fait que la suppression d'un champ ne s'est pas faite de la bonne manière, alors que ce champ n'était justement pas passé par un processus de décision collective. Pour moi, cette issue n'est certes pas parfaite, mais est une amélioration substantielle en termes de délibération.
Je ne pense pas que l'équipe LexImpact n'avait pas les moyens d'anticiper le résultat du vote, car ce résultat est clairement à l'image des commentaires et avis qui ont été exprimés durant la réunion qui avait eu lieu à ce sujet. D'une part, certains membres de LexImpact étaient présents à cette réunion. Et ont exprimé et bien insisté sur le fait que ces champs proposés voire déjà ajoutés à certains endroits n'étaient pas définitifs mais sujets à débats. Enfin, cette issue détaille bien le compte-rendu de cette réunion, de sorte qu'il était possible d'en prendre connaissance pour les absents.
Je comprends les réserves que l'on peut avoir sur le processus. Mais dans ce cas, pourquoi ne pas l'avoir dit en amont ? Plutôt que de soulever ces problèmes une fois que les votants ont pris le temps de s'exprimer ? Idem pour les contraintes de temps : je comprends qu'une équipe puisse être très prise ponctuellement et donc, non disponible pour des chantiers openfisca. Cela nous arrive fréquemment d'ailleurs côté IPP. Mais là encore, autant le dire direct. Plutôt que de laisser les choses se faire. Entre la publication de cette issue et la fin du vote, il y a eu plusieurs semaines, et des rappels sur le slack. Donc, plusieurs occasions d'exprimer cette impossibilité.
De plus, je tiens quand même à rappeler que ces débats sur les métadonnées ont été lancés en grande partie du fait des propositions côté LexImpact. Et côté IPP, on a in fine passé du temps sur ces débats, alors qu'il ne s'agissait pas du tout d'une priorité pour nous. Et nous avons nous aussi un planning chargé en ce début d'année. Donc, je trouve qu'il est paradoxal que ce soit in fine l'équipe qui amorce un chantier qui contexte un vote par manque de temps ou pour certaines raisons qu'elle n'a pas pris le temps d'exprimer.
Enfin, la décision sur les métadonnées est une chose, son implémentation (et donc ses conséquences concrètes) en est une autre. Sur ce dernier point, il ne me semble pas que des décisions aient été prises.
Pardon d'être un peu direct. Sur le fond, je ne suis pas du tout fermé sur les points à améliorer quant à nos processus de prise de décision, au contraire. Mais ce qui me gêne, c'est que j'ai l'impression que ces remarques ne sont pas tout à fait objectives, et cela me gêne. Et je pense qu'il est important quand même de souligner le travail important qui a été fait en termes de processus. On a eu une longue réunion, pas mal d'échanges, cette longue issue très détaillée, du temps pour répondre, diffusion sur Slack, etc. Même si ce process n'est pas parfait, il va clairement dans le bon sens.
Merci @sandcha de partager ces éléments de contexte et ces retours ! 🙂 Afin de s'assurer que cette issue reste focalisée sur la normalisation des métadonnées des variables, je préfère ne pas m'étendre ici sur le processus et les apprentissages associés. Il est clair que nous apprenons en marchant, et qu'il y a de nombreuses améliorations à apporter en terme de lisibilité et de predictabilité générale du processus de RFC, et ce message offre des éléments intéressants, que nous avons pu déjà expliciter en partie par des échanges en visio. Continuous à avancer !
J'ai pu ce matin échanger avec l'équipe LexImpact (@sandcha, @Sasha-Laniece et @DorineLam, en présence de @benoit-cty) sur les sujets qui restaient ouverts à ce stade, à savoir ux_name
et last_review
. Les conclusions sont les suivantes.
short_label
, pas d'unicité du nom dans le système socio-fiscal) est adoptée. Le contexte sera considéré comme suffisant pour désambiguer des termes comme « taux », pour éviter que les contributions deviennent trop créatives pour respecter une double contrainte d'unicité et de concision.short_label
et de rendre accessible à leurs utilisateurs, par exemple une infobulle ou un bouton d'aide, le label
complet car l'ambiguïté pourra subsister.short_label
sont cohérents (par exemple : « cotisation » → « cotis. » pour éviter que certains indiquent « cot. » et d'autres « cotis. »).short_label
, sur la base de son expérience avec LexImpact.last_reviewed
ne sont pas satisfaisantes : le processus de validation n'est pas établi, la valeur de confiance accordée à une telle information par les tiers n'est pas certaine, et les contre-arguments apportés dans la discussion n'ont pas été réfutés.reference
votée dans cette RFC).Je propose donc comme porte de sortie, au vu des votes en faveur de sa suppression et des votes acceptant une version plus complète, et en accord avec les personnes présentes :
last_reviewed
. Cela signifie que les métadonnées actuellement renseignées ne seront pas supprimées dans l'immédiat, mais que leur usage est découragé, que leur pérennité n'est pas garantie, qu'elles ne seront pas documentées, et que les PRs qui les modifient seront réduites au strict minimum, a priori uniquement pour les besoins de LexImpact.Afin de garantir l'effectivité de cette décision, je propose en complément :
last_reviewed
de la base de code OpenFisca, sera appliquée à défaut de meilleure solution, avec responsabilité pour l'équipe LexImpact d'extraire l'information dont elle dépend. Au vu des demandes liées aux délais (publication du PLF et PLFSS), je propose de fixer cette date au 31/12/2021, date de publication au journal officiel au plus tard.label
(métadonnée de Variable)Nous avons également échangé rapidement sur label
, le point suivant émerge : pour augmenter la découvrabilité, il serait utile de préciser que les « surnoms », ou « petits noms » des variables, devraient être inclus dans le label
. Par exemple, les exonérations « dites Fillon » ou le PFU « dit flat tax ».
L'idée d'une métadonnée dédiée a été évoquée mais écartée en raison du faible nombre de cas où elle serait remplie, et de la difficulté à l'exploiter.
Merci à toutes les personnes ayant participé à cette RFC d'une manière ou d'une autre. Comme je l'indiquais plus haut, nous apprenons tou‧te‧s comment cela fonctionne. Vous avez pu voir que j'ai pris le parti d'animer une proposition plus formelle sans donner de formation particulière, et sur un outil pas forcément le plus adapté, à savoir GitHub. Nous avons en effet à mon sens un problème de bootstrapping : comment intéresser et faire comprendre l'importance d'un tel dispositif de prise de décision, sachant que personne n'a fondamentalement envie d'y consacrer beaucoup de temps ? J'ai fait le choix de démarrer par la démonstration. Il est donc normal qu'il y ait des frictions (qui me semblent pour le moment mineures 🤞) au fur et à mesure que chacun‧e découvre l'importance de participer à ces opportunités de décision collective. Cela peut créer un peu de frustration, mais je suis convaincu que nous aurons plus d'engagement maintenant que la démonstration est faite de l'importance d'y participer et d'y consacrer un minimum de temps 🙂
Nous devons bien évidemment trouver des manières d'améliorer ce processus, et le fonctionnement actuel ne me semble pas idéal. Il comprend à ce stade de nombreuses failles et points d'incertitude (Les votes sont-ils par individu ou par entité ? Quels moyens de traçabilité des votes ? Quels délais pour quels sujets ? Quand peut-on être flexible sur les résultats d'un vote ?). J'ai de nombreuses propositions sur tout cela, mais il me semble important de garder à l'esprit que ce que nous cherchons, c'est à avancer ensemble sur OpenFisca pour fournir la meilleure modélisation possible du système socio-fiscal français, et au-delà 😃 Tant que nous pouvons déjà avancer avec ce que nous avons déjà, faisons-le !
Nous aurons bientôt l'occasion d'échanger plus avant sur le processus et les apprentissages liés à cette RFC. Je vous demanderai donc de ne pas surcharger cette issue avec ces sujets, mais plutôt de prendre des notes que nous pourrons partager lors d'un moment dédié 🙂
last_reviewed
ne fasse l'objet d'une opposition majeure, je crois que nous pouvons clore cette RFC sur la normalisation des métadonnées des variables.last_review
fera l'objet d'une décision séparée ultérieure, soit par l'ouverture d'une proposition dédiée par l'équipe LexImpact comme elle l'a suggéré, soit par la création d'un outil dédié dans les prochains mois.last_reviewed
En espérant une adoption combinée avec les métadonnées des paramètres, afin de n'opérer les changements sur OpenFisca Core, Web API et Country Template en une seule fois.
reference
en un dictionnairereference
.reference
d'OpenFisca France.label
ux_name
en short_label
short_label
.ux_name
et corriger les valeurs ne respectant pas les contraintes.A priori, last_reviewed
pour les variables n'est pas implémenté dans Core ni utilisé dans les variables de France, il n'y a donc rien à faire.
La RFC sur les métadonnées des paramètres (#1672) est complète !
RFC
Objet
Cette RFC vise à établir une liste des métadonnées à utiliser dans OpenFisca France pour les paramètres et les variables.
Livrable
Pour chacune des métadonnées, il s'agira de définir :
Cette liste sera documentée dans une documentation spécifique à OpenFisca France (et non dans la documentation d'OpenFisca Core disponible sur openfisca.org/doc).
Nécessité
Incohérence actuelle
Cette normalisation est utile car les métadonnées sont aujourd'hui renseignées de manière non-systématique et parfois incohérente. Par exemple, avec la famille de métadonnées
unit
dans les paramètres :La
reference
des variables est parfois remplie avec une URL parfois en HTTP, parfois en HTTPS, parfois avec plusieurs URL, parfois un mélange d'URL et de texte descriptif, parfois dans un seul champ de texte…Ces incohérences rendent très difficile la création d'applications consommatrices de ces métadonnées, et ne permettent pas à de nouveaux contributeurs de comprendre quelle information indiquer.
Urgence
L'urgence de cette normalisation est renforcée par les chantiers indépendants des équipes IPP et LexImpact, qui interviennent sur les métadonnées pour l'affichage d'informations complémentaires sur des applications consommant les paramètres OpenFisca : les barèmes IPP pour la première, et une application de contribution aux paramètres pour la seconde.
En l'absence de normalisation, des métadonnées arbitraires risquent d'être ajoutées pour chaque application cliente.
Processus
Historique
Catalogue des métadonnées existantes
Variables
Métadonnées déjà normalisées
Ces métadonnées sont définies sur openfisca.org/doc, normalisées dans Core et exposées dans l'API Web et l'API Python. Elles sont aujourd'hui présentées comme des « attributs » des variables et non comme des métadonnées, au même niveau que l'entité de rattachement ou la période de définition.
label
"Pensions alimentaires"
"Charges déductibles"
reference
"http://bofip.impots.gouv.fr/bofip/1852-PGP"
Métadonnées proposées par LexImpact
Last reviewed
2021-03-20
2000-01-01
Obsolète
Cette proposition est expérimentale et ne fait pas l'objet d'une demande formelle de normalisation à ce stade.
true
Date du lien de l'URL de la description
Cette proposition est expérimentale et ne fait pas l'objet d'une demande formelle de normalisation à ce stade.
2021-03-20
2000-01-01
Cette métadonnée pourrait également être utilisée avec l'usage suivant.
2021-03-20
2000-01-01
Libellé du lien de l'URL de la description
Cette proposition est expérimentale et ne fait pas l'objet d'une demande formelle de normalisation à ce stade.
"Circulaire ESRS2013435C - Annexe 7 - Taux et cumul de la bourse d'enseignement supérieur sur critères sociaux / 1 - Les taux de bourse d'enseignement supérieur sur critères sociaux"
"art. 15 de la loi 2013-1278"
Il s'agit d'une surspécification de l'attribut
reference
actuellement existant.URL de la note
Cette proposition est expérimentale et ne fait pas l'objet d'une demande formelle de normalisation à ce stade.
"https://www.legifrance.gouv.fr/eli/decret/2020/3/30/ECOI2007755D/jo/texte"
"http://impotsurlerevenu.org/definitions/215-charge-deductible.php"
Il s'agit d'une surspécification de l'attribut
reference
actuellement existant.Notes
Cette proposition est expérimentale et ne fait pas l'objet d'une demande formelle de normalisation à ce stade.
"Ces charges et ces aides sont appelées différées, car elles interviendront a posteriori, par exemple sous la forme d’un crédit d'impôt."
"Ce dispositif n'est pas à jour. LexImpact prend en compte l'ancien dispositif du CICE, initialement un crédit d'impôt. Depuis 2019, le CICE s'est transformé en allègement de cotisations sociales patronales. Ce dispositif sera mis à jour prochainement."
UX name
"Charges et aides différées"
"CICE"
Paramètres
Métadonnées déjà normalisées
Ces métadonnées sont définies sur openfisca.org/doc, normalisées dans Core et exposées dans l'API Web et l'API Python.
description
est aujourd'hui présentée comme un « attribut » des paramètres et non comme une métadonnée. Les autres sont définies comme rattachées à l'attributmetadata
.description
"Indicatrice d'imposition"
"Contribution exceptionnelle sur les hauts revenus"
metadata.reference
https://www.pole-emploi.fr/candidat/mes-droits-aux-aides-et-allocati/allocations-et-aides--les-repons/aides-financieres-aux-jeunes-dip.html
_Cette métadonnée est également souvent définie directement comme
reference
, sans passer par le nœud intermédiairemetadata
._unit
(etthreshold_unit
,rate_unit
,amount_unit
pour les barèmes)description
./1
currency
Cette métadonnée n'est pas validée automatiquement et contient des valeurs arbitraires, cf.l'introduction de cette RFC.
Métadonnées utilisées par l'IPP
reference.href
metadata.reference
d'un Paramètre.https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=LEGIARTI000028428572&cidTexte=JORFTEXT000028400921
https://www.legifrance.gouv.fr/affichTexteArticle.do?idArticle=LEGIARTI000025511700&cidTexte=JORFTEXT000025509584
Il s'agit d'une surspécification de la métadonnée
reference
actuellement existante.reference.title
metadata.reference
d'un Paramètre.Loi 2013-1279 du 29/12/2013 (LFR pour 2013), art. 60
Loi 2012-354 du 14/12/2012 (LFR pour 2012), art. 22
Il s'agit d'une surspécification de la métadonnée
reference
actuellement existante.date_parution_jo
reference:title
etreference:href
.metadata
d'un Paramètre.2019-01-01: 2018-09-06
2014-01-01: 2013-12-29; 2012-03-15
_Cette métadonnée est actuellement utilisée par l'équipe LexImpact sous le nom
official_journal_date
. Les deux sont en cours de convergence versdate_journal_officiel
._description_en
metadata
d'un Paramètre.Apprenticeship tax (tax for the financing of apprenticeship)
Other payroll and workforce taxes
documentation
metadata
d'un Paramètre.À partir de 2014, des seuils spécifiques (célibataire, couple) sont employés pour le calcul de la décote.
Métadonnées liées au chantier d'harmonisation
Ces métadonnées ont fait l'objet d'un accord dans #1519.
ux_name
metadata
d'un Paramètre.Toutes entreprises
Contribution additionnelle au développement de l'apprentissage
last_review
metadata
d'un Paramètre.1993-07-01
2014-01-01
Métadonnées historiques
Ces métadonnées ont été utilisées dans le passé mais ne sont plus aujourd'hui visibles dans la base de code OpenFisca France.
ipp_csv_id
order
Proposition
Cette partie est en cours de rédaction et fera l'objet d'un nouveau message.