Gouvernance¶
Le standard OCDS a de nombreuses parties prenantes : les gouvernements (autorités adjudicatrices, autorités de surveillance et de contrôle, gestionnaires de projets et décisionnaires), le secteur privé, et les organisations de la société civile. Les besoins et les intérêts de ces parties prenantes, en tant que producteurs et usages des données, sont variés. À mesure que le standard OCDS se développe dans le temps, avec des versions mises à jour et de nouvelles fonctionnalités, il est important qu'un groupe diversifié de parties prenantes soient impliqué dans le processus.
Ce document établit le processus de révision d'OCDS.
Direction et gouvernance¶
L'Open Contracting Partnership (OCP) a été créé comme organisation indépendante à but non lucratif début 2015 et est le principal administrateur du standard OCDS.
L'OCP est dirigé par un directeur exécutif, et est soutenu par un conseil d'administration comprenant de multiples parties prenantes, avec des représentants des gouvernements, d'organisations multilatérales, du monde universitaire, des ONG et du secteur marchand.
In the pursuit of a consensus and community-driven process, subscribers to the standard-discuss@open-contracting.org discussion list (join by sending an email to standard-discuss+subscribe@open-contracting.org) and those watching and engaging with the standard GitHub repository should be kept informed at all stages about planned revisions to OCDS, and should be offered clear and timely opportunities to input and comment.
Afin de s'assurer de la pertinence, de la qualité et d'une implémentation efficace des propositions de mise à jour du standard, les nouvelles versions sont soumises à un processus de révision par les pairs (peer review), avec des évaluateurs invités au sein des communautés de producteurs et d'utilisateurs de données, et un processus de révision ouvert.
Un petit groupe de travail sur la gouvernance du standard, constitué de représentants de l'équipe de l'OCP, du conseil d'administration et de l'équipe du développement du standard sera en charge de donner son accord final aux modifications formelles du standard, et de s'assurer que les processus édictés dans ce document ont été mis en œuvre de manière appropriée.
Dans le futur, l'Open Contracting Data Standard pourrait être soumis à un organisme de normalisation officiel, tel que le World Wide Web Consortium ou OASIS. Avant qu'une telle décision soit prise, un modèle de gouvernance piloté par la communauté doit être établi sur la base d'un processus ouvert et consensuel de mise à jour du standard.
Propriété intellectuelle¶
The Open Contracting Data Standard is the Intellectual Property of the Open Contracting Partnership. The schema is licensed under the Apache 2.0 License license, with accompanying documentation under a Creative Commons Attribution 4.0 International license where stated.
Contributors to the standard agree to transfer any copyright in their contributions to the Open Contracting Partnership through a contributor agreement process, in order that those contributions are held in trust as part of the standard.
Aucun contenu portant atteinte à des droits de propriété intellectuelle d'un tiers ne sera inclus dans le standard.
Principes de gouvernance¶
Nous soutenons les principes de l'Open Stand pour le développement de standards. Le standard OCDS sera développé avec :
Une procédure explicite. Des décisions prises de manière équitable et juste à l'égard des participants. Au travers d'une procédure ouverte pour soumettre des problèmes, des extensions et des demandes de mise à jour, aucune organisation ne domine seule le développement du standard. Toutes les procédures sont transparentes, et des opportunités existent afin de faire appel des décisions. Les procédures pour une révision et mise à jour périodique des standards sont explicitement définies dans ce document.
Un large consensus. La procédure permet à tous les avis d'être pris en considération, de sorte qu'un accord puisse être trouvé entre différents intérêts.
La transparence. Nous fournissons une notification publique, en amont, des propositions de développement des standards, de l'étendue du travail à mener, et des conditions de participation. Des registres aisément accessibles des décisions et des éléments utilisés pour prendre ces décisions sont fournis. Des périodes de commentaire public sont mises en place avant l'approbation et l'adoption finale des standards.
L'équilibre. Les activités relatives aux standards ne sont pas dominées de manière exclusive par une personne en particulier, une entreprise ou un groupe d'intérêt.
L'ouverture. Les procédures OCDS sont ouvertes à toutes les parties intéressées et informées.
Procédure de gestion des versions et de mise à jour¶
Avec le temps, il sera nécessaire d'apporter des changements au standard, en particulier d'ajouter de nouveaux codes et de nouveaux champs, et à l'occasion cela impliquera d'apporter des changements à des champs ou structures existants.
La révision du processus est conçue pour assurer :
Les conséquences pour différentes parties prenantes de tout changement sont identifiées et prises en compte ;
la raison rendant nécessaire le changement est clairement identifiée, et qu'il y a un large soutien pour les changements proposés ;
les changements sont faciles à identifier et sont transparents, et les producteurs et utilisateurs de données ainsi que les intermédiaires disposent d'une documentation claire leur permettant de mettre à jour leurs données et leurs outils ;
Les changements apportés au schéma d'OCDS seront faits de manière périodique, avec une incrémentation du numéro de version du standard pour indiquer que des changements ont été faits, et une liste des modifications tenue à jour.
Cette documentation en ligne est composée d’un contenu normatif (la partie normative d’OCDS) et d’un contenu non normatif (la partie non normative ou «descriptive» d’OCDS) tels que définis et décrits dans ce document (en anglais) Contenu normatif et non normatif et politique de modifications. Cette politique détermine quelles modifications venant de quelles parties de la documentation doivent déclencher le processus de révision décrit ci-dessous (par exemple, l'ajout de nouveaux champs au schéma de version), et quelles modifications peuvent être apportées sans le processus de révision (par exemple, la correction de fautes de frappe dans les descriptions de champs).
Versions¶
Des branches distinctes du standard sont maintenues sur Github pour chaque version.
Les branches peuvent être dans l'un de ces deux états :
Développement - indiqué par un suffixe -dev (par exemple, 1.1-dev) Le schéma et la documentation peuvent être tous deux mis à jour sur une branche de développement et peuvent être mis en œuvre à titre expérimental.
Directement - sans suffixe (par exemple 1.0) Seule la documentation peut être mise à jour directement sur une branche. Tous les changements apportés à la documentation doivent être examinés pour s’assurer qu’ils n’apportent aucune modification à la signification du standard.
Des pratiques de gestion sémantique des versions seront utilisées pour distinguer entre :
Des versions majeures qui apportent des changements rendant incompatibles avec les versions antérieures (e.g. 2.0)
Des versions mineures qui ajoutent des fonctionnalités d'une manière compatible avec les versions antérieures (e.g. 1.2)
Cela se traduit par un numéro de version au format MAJEUR.MINEUR
Processus de révision¶
Publier une nouvelle version mineure ou majeure implique un certain nombre d'étapes présentées dans le graphique ci-dessous, et décrites plus en détail dans les sections suivantes.
Principes généraux :
Publicité. Toutes les étapes du processus de révision sont annoncées via la liste de diffusion standard-discuss, et au travers d'issues Github. Ce sont les canaux formels de notification durant le processus
Consensus : Tous les procédés visent à obtenir un consensus de la communauté concernant les changements.
L'équipe de développement du standard est responsable de la production de la documentation tout au cours du processus, et est idéalement guidée par le consensus de la communauté, qui soumet toutes les décisions à discussion.
Appeal: Any party can appeal against decisions made during the process by writing to the standard governance working group, which can be reached through OCP's Director for Data & Engagement, Lindsey Marchessault. The working group has the authority to reject proposed revisions on the standard in response to appeals.
Propositions¶
N'importe qui peut proposer des changements au standard OCDS à n'importe quel moment via le issue tracker du standard, soit sous la forme de questions soumises à discussion, soit sous la forme de "pull requests" avec une description claire du changement proposé.
Les contributeurs sont encouragés à soulever une discussion avant de soumettre une pull request, de manière à rechercher le consensus sur les changements proposés.
Des changements peuvent être proposés comme :
Extensions - qui ajoutent de nouvelles fonctionnalités au standard.
Changements - tels que des définitions de champ mises à jour ou de nouveaux codes dans des listes de codes.
Si au moins deux parties prenantes manifestent un intérêt pour utiliser une extension, et suivant la discussion du projet d'extension, celle-ci peut apparaître dans la version courante de la documentation en tant que "fonctionnalité expérimentale".
Priorisation des propositions¶
L'équipe de développement du standard, en se référant aux opinions de la communauté, identifie les propositions de changement et les extensions qui devraient être prises en compte dans la prochaine version du standard, en les affectant aux jalons du suivi des bugs, lorsque ces jalons sont ouverts à la discussion.
De manière périodique, au début d'un processus de révision, une date-limite pour les propositions est annoncée, au moins deux semaines à l'avance. Après cette date, une liste des changements par ordre de priorité est produite. Toute nouvelle proposition d'extension ou de changement reçue après cette période pourra ne pas être prise en considération avant la phase de priorisation suivante.
Révision de la priorisation¶
La liste est partagée pour obtenir des retours, avec une période d'au moins deux semaines de discussion.
Sur la base de discussions, le directeur des Produits et Services de Données de l'OCP propose une liste finale avec tous les bugs et les questions restants à prendre en compte dans la suite du processus. Une proposition qui a atteint ce niveau pourrait ou non figurer dans la nouvelle version. Au fur et à mesure que la proposition est transformée en exemples concrets finaux et en modifications de schéma, d'autres problèmes peuvent survenir.
Développement¶
L'équipe de développement du standard, en collaboration avec les membres de la communauté, travaille sur une branche de développement pour préparer les mises à jour du schéma, de la documentation et des listes de codes, en accord avec la liste priorisée.
Cette étape implique une large participation de la communauté, et la discussion de décisions spécifiques au travers d'issues Github.
Au moment où tous les bugs sont correctement corrigés, la branche de développement est prête à être soumise à une évaluation par les pairs.
Évaluation par les pairs (peer-review)¶
Le schéma mis à jour, la documentation ainsi qu'un change log et la description narrative des changements sont publiés pour évaluation par les pairs.
Un groupe d'évaluateurs invités, représentant différentes parties prenantes, et comprenant des producteurs et des utilisateurs de données, est sollicité afin de réaliser une évaluation complète des changements, et de soumettre :
Un jugement permet de déterminer si la nouvelle version globale et/ou seules des modifications spécifiques doivent être acceptées, acceptées avec des modifications mineures, substantiellement révisées ou rejetées.
Des commentaires accompagnant chaque demande de révision ou de rejet.
Toutes les relectures, avec les noms des relecteurs, seront publiées. Les membres de la communauté peuvent également soumettre leurs propres relectures, de la révision complète ou d'éléments spécifiques. La période minimale d'examen par les pairs est d'un mois.
Révisions¶
L'équipe de développement du standard, en se référant au groupe de travail le cas échéant, évalue les relectures et décide si la toute nouvelle version, ou seules quelques fonctionnalités doivent être révisées, rejetées ou reportées à de futures mises à jour.
Si quelques changements mineurs seulement sont suggérés, le standard doit être renvoyée aux relecteurs pour une petite période relecture d’au moins deux semaines.
Si des changements majeurs sont nécessaires, un processus de révision d'une durée d'au moins un mois devrait être prévu.
Publication¶
Une fois que tous les commentaires du relecteur ont été traités, la version mise à jour du standard doit être soumise au groupe de travail sur la gouvernance du standard pour validation finale, qui s'accompagnera d'un bref rapport.
Suite à la validation du groupe de travail, la branche de révision peut être mise en production.
Politique de dépréciation¶
Si un terme (une définition ou un champ) doit être renommé ou supprimé de la spécification à la suite du processus de révision, la prochaine publication mineure de la spécification doit déprécier le terme dans le schéma, et la version majeure suivante doit renommer ou supprimer le terme du schéma, rendant le terme obsolète. Les implémentations d'OCDS peuvent utiliser des termes dépréciés, mais recevront des avertissements du validateur OCDS décrit ci-dessous. Les implémentations ne peuvent pas utiliser des termes obsolètes et recevront des erreurs du validateur OCDS.
Politique de traduction et de localisation¶
Le standard est traduit et localisé conformément à la dernière version de la politique de traduction et de localisation.
Politique de support¶
Un support est proposé pour une version antérieure du standard. Le support apporté à toute version antérieure à celle-ci sera terminé lorsque une nouvelle version est publiée.
Par exemple, si la version 1.1 est la plus récente, la version 1.0 est supportée dans le validateur et par les autres outils. Lorsque la version 1.2 est publiée, le support pour la 1.0 est terminé.
Les producteurs de données sont encouragés à passer en revue chaque nouvelle version lorsqu'elle est publiée, et à envisager de quelle manière ils pourraient adopter les nouvelles fonctionnalités.
Les producteurs de données doivent chercher à passer à une nouvelle version majeure dans les 18 mois suivants sa publication.
Définitions¶
Parties prenantes
N'importe quel utilisateur, actuel ou potentiel, du standard ou producteur de données du standard peut être considérée comme une partie prenante. Lors de la collaboration avec les parties prenantes, il convient de prêter attention à l'égale représentation des producteurs de données, des utilisateurs, des acteurs publics et privés et de la société civile ; ainsi que d'une large représentation géographique.
Consensus
"Le principe du consensus trouve ses origines dans le désir de parvenir à une acceptation et une application généralisées du standard dans sa sphère d'influence recherchée. Cela implique d'essayer de s'assurer que les intérêts de tous ceux qui pourraient en être affectés sont pris en compte, et que les problématiques individuelles soient méticuleusement et équitablement mis en balance avec l'intérêt commun." BSI, 2012