Présentation du processus de modification

La spécification GTFS-realtime n'est pas figée. Il s'agit plutôt d'une spécification ouverte, développée et maintenue par la communauté des agences de transports en commun, des développeurs et d'autres parties prenantes qui utilisent GTFS-realtime. Il est prévu que cette communauté de fournisseurs et de consommateurs de données GTFS-realtime propose des solutions visant à étendre la spécification afin d'offrir de nouvelles capacités. Pour vous aider à gérer ce processus, nous avons établi les consignes et procédures suivantes.

Processus de modification des spécifications

La spécification officielle, les références et la documentation sont rédigées en anglais. Si la traduction dans une autre langue diffère de la version originale en anglais, cette dernière aura la priorité. Toutes les communications sont effectuées en anglais.

  1. Créez une branche Git avec la mise à jour de toutes les sections pertinentes de la définition du protocole, ainsi que des fichiers de spécification et de documentation (sauf pour les traductions).
  2. Créez une demande d'extraction sur https://github.com/google/transit. La demande doit contenir une description étendue du patch. Le créateur de la demande d'extraction devient le porte-parole.
  3. Une fois la demande d'extraction enregistrée, elle doit être communiquée par le porte-parole à la liste de diffusion GTFS-realtime. Une fois communiquée, la demande d'extraction est considérée comme une proposition.
  4. Le porte-parole étant un contributeur, il doit signer l'accord de licence du contributeur avant que la demande d'extraction ne puisse être acceptée.
  5. Une discussion autour de la proposition s'ensuit. Les commentaires relatifs à la demande d'extraction constituent l'unique forum de discussion.
  6. La discussion dure aussi longtemps que le porte-parole le juge nécessaire, mais pour une durée minimale de sept jours calendaires.
  7. Le porte-parole est responsable de la mise à jour au moment opportun de la proposition (c'est-à-dire de la demande d'extraction) en fonction des commentaires qui la soutiennent.
  8. À tout moment, le porte-parole peut revendiquer l'abandon de la proposition.
  9. Le porte-parole peut appeler à voter sur une version de la proposition à tout moment après les sept premiers jours de discussion obligatoires.
  10. Le vote doit s'étendre sur une période suffisante pour couvrir la période minimale de sept jours complets calendaires et de cinq jours ouvrés en Suisse. Le vote se termine à 23:59:59 UTC.
  11. Le porte-parole doit annoncer l'heure de fin spécifique au début du vote.
  12. Pendant la période de vote, seules les modifications rédactionnelles de la proposition sont autorisées (fautes de frappe, révision des termes à condition que le sens reste inchangé).
  13. Tout le monde est autorisé à voter oui ou non sous forme d'un commentaire à la demande d'extraction. Le vote peut être modifié jusqu'à la fin de la période de vote. Si un participant souhaite modifier son vote, il est recommandé de le faire en mettant à jour le commentaire original avec la saisie du nouveau vote.
  14. Les votes émis avant le début de la période de vote ne seront pas pris en compte.
  15. La proposition n'est acceptée que si un consensus unanime positif est atteint avec au moins trois votes.
  16. Le vote du demandeur ne compte pas dans le total des trois voix. Par exemple, si le demandeur X crée une demande d'extraction et vote "oui", et si deux utilisateurs Y et Z votent également "oui", seuls ces deux derniers votes seront comptabilisés.
  17. Les votes négatifs doivent être détaillés et en principe justifiés par un commentaire constructif.
  18. Si le vote échoue, le porte-parole peut choisir de continuer à travailler sur la proposition, ou bien de l'abandonner. Chaque décision du porte-parole doit être communiquée à la liste de diffusion.
  19. Si le porte-parole choisit de continuer à travailler sur la proposition, il peut à tout moment procéder à un nouveau vote, dans un délai maximal de 30 jours calendaires après le vote précédent.
  20. Si aucun vote n'est proposé dans un délai de 30 jours calendaires à partir de la proposition d'origine ou du vote précédent, la proposition est abandonnée.
  21. Si la proposition est abandonnée, la demande d'extraction correspondante sera clôturée.
  22. Si la proposition est acceptée :
  23. Google s'engage à fusionner la version votée de la demande d'extraction (à condition que les contributeurs aient signé le CLA), et à effectuer la demande d'extraction dans les cinq jours ouvrés.
  24. Google s'engage à mettre à jour en temps utile le référentiel à l'adresse https://github.com/google/gtfs-realtime-bindings. Tout engagement sur gtfs-realtime-bindigs résultant d'une proposition doit faire référence à la proposition de demande d'extraction.
  25. Les traductions ne doivent pas être incluses dans la demande d'extraction originale. Google est responsable de la mise à jour des traductions pertinentes dans les langues concernées. En revanche, les simples traductions des demandes d'extraction de la communauté sont les bienvenues et seront acceptées dès que tous les commentaires éditoriaux seront traités.