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 de l’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.

Depuis février 2016, l’OCP est hébergé fiscalement par le Fund for the City of New York (FCNY). Selon les termes de cet accord, la propriété intellectuelle appartient au FNCY, au nom de l’OCP, mais sera transférée à toute entité juridique future qui hébergera l’OCP.

L’équipe technique d’OCDS travaille sous contrat avec OCP, sous la direction du responsable Data & Engagement d’OCP. L’équipe fournit un service d’assistance technique et est responsable de la gestion quotidienne de la documentation du standard et des outils de validation. L’équipe technique peut être contactée via ‘mailto:data@open-contracting.org’.

Dans la recherche d’un consensus général et d’un processus mené par la communauté, tous les abonnés de la liste de diffusion standard-discuss@open-contracting.org (vous pouvez la rejoindre en envoyant un email à standard-discuss+subscribe@open-contracting.org) et toutes les personnes qui gardent un oeil ou interagissent avec le dépôt GitHub du standard sont tenues informées de toutes les étapes de révision d’OCDS planifiées, et à travers ces moyens de communication, peuvent créer des occasions clairement identifiées pour contribuer ou commenter.

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 technique 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.

Propriété intellectuelle

Le standard OCDS est la propriété intellectuelle de l’Open Contracting Partnership. Le schéma est placé sous la licence Apache 2.0, et la documentation qui l’accompagne sous une licence Creative Commons Attribution 4.0 International license lorsque cela est indiqué.

Les contributeurs au standard acceptent de transférer tout droit d’auteur sur leur contribution à l’Open Contracting Partnership (via son sponsor fiscal) au moyen d’un processus d’accord de contribution, de sorte que ces contributions puissent être considérées comme faisant partie intégrante du 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 de l’OCDS sont ouvertes à toutes les parties intéressées et informées.

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.

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 modifications apportées au standard OCDS doivent être effectuées périodiquement, avec le numéro de version du standard incrémenté, pour indiquer que des modifications ont été apportées, ainsi qu’un journal des modifications mis à 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 l’API incompatibles avec les versions antérieures

  • Des versions mineures qui ajoutent des fonctionnalités d’une manière compatible avec les versions antérieures

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.

image alt text

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 technique 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.

  • Appel : Toute partie peut faire appel des décisions prises au cours du processus en écrivant au groupe de travail sur la gouvernance, qui peut être contacté par l’intermédiaire de Lindsey Marchessault ‘mailto:lmarchessault@open-contracting.org’. Le groupe de travail a le pouvoir de rejeter les révisions proposées au standard en réponse aux appels.

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 technique, 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, l’équipe technique 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 et documentation

L’équipe technique, 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 technique, 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 classe ou une propriété) 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 de l’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 et procédures

Parties prenantes

Toute personne se définissant comme éditeur ou utilisateur 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 éditeurs, 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