Résumé

  • Un commentaire de consultation publique doit être reçu, suivi et assorti d’une disposition ; il ne constitue ni un veto individuel ni l’approbation finale de l’organisation.
  • La majorité spéciale du comité, les déclarations d’utilisation et l’appel au consentement des membres organisationnels établissent des faits différents. Une fiche de parcours doit les laisser séparés.

Trois portes, trois questions

Le raccourci « le document a été commenté et le comité a voté, donc OASIS l’a approuvé » efface l’architecture de la procédure. Le premier moment appartient au comité technique. Pour ouvrir une consultation publique, il faut une majorité pleine des membres votants éligibles. La première période dure au moins trente jours ; une nouvelle consultation du même produit dure au moins quinze jours. Cette ouverture donne un canal défini aux personnes extérieures au comité. Elle ne leur donne pas un bulletin.

Après la clôture, le comité doit accuser réception des commentaires, les suivre et publier leur disposition. Si les réponses entraînent une modification substantielle, une nouvelle consultation est nécessaire avant qu’une spécification de comité puisse être approuvée. C’est seulement après une consultation réussie et le traitement des commentaires que le comité peut approuver une Committee Specification par majorité spéciale.

Cette spécification est le niveau le plus élevé que le comité puisse accorder seul. Elle ne devient pas pour autant une OASIS Standard. Pour poursuivre, le comité doit encore voter à la majorité spéciale afin de soumettre le texte comme candidat, réunir trois Statements of Use — dont au moins une venant d’un membre organisationnel — puis traverser une consultation de candidat d’au moins soixante jours.

Enfin, l’administrateur ouvre un appel au consentement d’au moins quatorze jours pour les membres organisationnels éligibles. Le processus ne demande donc pas trois confirmations de la même population. Il demande successivement un contrôle du texte par le comité, une trace publique des remarques, une preuve d’utilisation, puis un mécanisme d’objection organisationnel.

Un commentaire crée une trace obligatoire, pas une instruction automatique

Réduire la consultation à une boîte aux lettres est faux : chaque commentaire doit être reconnu, tracé et recevoir une disposition. Le comité doit aussi décider si une modification issue de cette consultation est substantielle. Dans ce cas, le texte retourne en consultation avant le vote de Committee Specification. Une version modifiée en profondeur ne peut donc pas se cacher derrière une consultation portant sur une version antérieure.

Mais l’autre exagération est également trompeuse. La règle ne transforme pas chaque commentaire en ordre technique. Elle ne confond pas le nombre de messages avec un référendum. Le comité peut refuser une proposition, à condition que la trace permette de voir quelle question a été posée, quelle version était visée, quelle réponse a été donnée et si le texte a changé.

Une bonne fiche conserverait le commentaire, son lien vers la version, sa disposition, l’éventuelle modification et la qualification substantielle ou non substantielle. Le seul mot « résolu » est insuffisant : un lecteur ultérieur doit pouvoir distinguer une acceptation, un refus motivé, un report ou une question devenue sans objet.

La majorité spéciale est une preuve technique bornée

Le vote de Committee Specification n’est pas un lever de main dans une réunion. Une majorité spéciale exige au moins deux tiers de oui parmi les membres votants éligibles et pas plus d’un quart de non. Les abstentions et les non-votes ne sont ni oui ni non, mais les personnes éligibles restent dans le dénominateur.

Une photographie de réunion ne prouve donc pas le résultat. Un groupe d’auteurs très visible peut ne pas atteindre le seuil. Inversement, un résultat positif prouve que le seuil précis du comité a été franchi ; il ne prouve pas l’adhésion de chaque commentateur, implémenteur ou membre organisationnel.

La fiche doit figer l’univers des votants à l’ouverture, le type de vote, les dates, les comptes oui/non/abstention/non-vote, le résultat et l’URI immuable du texte. Elle n’a pas à deviner pourquoi une personne n’a pas voté.

L’usage et le consentement ne sont pas des synonymes

Les trois Statements of Use demandées avant la candidature sont des éléments sur l’utilisation ou l’implémentation selon la procédure. Elles ne sont ni trois bulletins supplémentaires, ni une garantie universelle d’interopérabilité, ni une mesure de marché. Elles répondent à une question différente de celle du vote du comité.

L’appel au consentement répond à une autre question encore. Depuis le processus effectif au 1er décembre 2020, les membres organisationnels éligibles sont présumés consentir tant qu’ils ne déposent pas une objection valide dans l’outil de vote. L’objection doit donner un motif et/ou un remède proposé. Quinze objections valides ou plus rejettent la candidature ; en dessous de quinze, le comité entre dans la voie de réponse ou de retrait prévue.

Ce silence a une portée procédurale réelle : il signifie qu’aucun seuil d’objections organisationnelles valides n’a bloqué cette étape. Il ne signifie pas que chaque organisation a relu l’architecture technique, approuvé chaque choix rédactionnel ou atteint un consensus d’ingénierie.

Publier le reçu du cycle plutôt qu’une étiquette de prestige

Le correctif est petit. À chaque transition, OASIS pourrait publier un reçu lié à la version exacte : étape, empreinte ou URI, dates de consultation, canaux de commentaires, dispositions et matérialité ; puis dénominateur du comité et résultat ; ensuite Statements of Use et consultation du candidat ; enfin univers des membres organisationnels, dates de consentement, objections valides et statut publié.

Cette fiche ne doit pas élargir les preuves. Elle ne doit pas appeler un commentaire un vote, le vote du comité une ratification de l’organisation, une déclaration d’utilisation un soutien universel, ni le silence un accord technique. Elle rend précisément visible ce que chaque porte a établi.

Sources

  1. OASIS Technical Committee Process
  2. OASIS TC Handbook : Public Review
  3. OASIS TC Handbook : Committee Specifications
  4. OASIS TC Handbook : OASIS Standard
  5. OASIS TC Handbook : Work Product Lifecycle
  6. Lu Heng, The Multi-Stakeholder Mirage