Descripción general del proceso de cambio

La especificación GTFS Realtime no es definitiva. Por el contrario, es una especificación abierta, desarrollada y mantenida por la comunidad de empresas de transporte público, programadores y otras partes interesadas que utilizan GTFS Realtime. Se espera que esta comunidad de productores y consumidores de datos de GTFS Realtime presente propuestas para extender la especificación a fin de habilitar funciones nuevas. Para ayudar a administrar ese proceso, se han establecido los siguientes lineamientos y procedimientos.

Proceso de modificación de la especificación

La especificación, referencia y documentación oficiales se escriben en inglés. Si una traducción a otro idioma difiere del original en inglés, este último tiene prioridad. Toda comunicación se realiza en inglés.

  1. Crea una rama de Git con la actualización de todas las partes relevantes correspondientes a los archivos de la documentación (excepto las traducciones), la definición del protocolo y la especificación.
  2. Crea una solicitud de extracción en https://github.com/google/transit. La solicitud de extracción debe contener una descripción detallada del parche. El creador de la solicitud de extracción se convierte en el proponedor.
  3. Una vez que se registra la solicitud de extracción, su proponedor debe anunciarla en la lista de distribución de cambios de la Especificación GTFS Realtime. Una vez anunciada la solicitud, esta se considera una propuesta.
  4. El paso siguiente es el debate sobre la propuesta. Los comentarios sobre la solicitud de incorporación de cambios se deben usar como el único foro de debate.
    • El debate dura el tiempo que el defensor considere necesario, pero debe ser de, al menos, 7 días calendario.
    • El defensor es responsable de la actualización oportuna de la propuesta (es decir, la solicitud de incorporación de cambios), en función de los comentarios que se aceptan en el foro.
    • El defensor puede determinar que se abandona la propuesta en cualquier momento.
  5. El defensor puede pedir una votación sobre una versión de la propuesta en cualquier momento, siempre que haya transcurrido el intervalo inicial de 7 días requerido para el debate.
  6. La votación dura el período mínimo suficiente para cubrir 7 días calendario completos y 5 días hábiles suizos completos. La votación finaliza a las 23:59:59, UTC.
    • El defensor debe anunciar la hora de finalización específica al comienzo de la votación.
    • Durante el período de votación, solo se permite realizar cambios editoriales a la propuesta (se pueden corregir errores tipográficos o de redacción, siempre que no se cambie el significado).
    • Cualquier persona puede votar a favor o en contra de la solicitud de incorporación de cambios mediante un comentario en el foro y los votos se pueden cambiar hasta el final del período de votación. Si un votante cambia su voto, se recomienda que lo haga actualizando el comentario del voto original. Para actualizar el comentario, se debe eliminar el voto y, luego, escribir el voto nuevo.
    • Los votos emitidos antes del comienzo del período de votación no son válidos.
  7. La propuesta se acepta si hay un consenso unánime a favor de la propuesta con, al menos, 3 votos.
    • El voto del proponente no cuenta para el total de 3 votos. Por ejemplo, si el proponente X presenta una solicitud de incorporación de cambios y, luego, vota a favor, y el usuario Y y Z también votan a favor, esto se cuenta como un total de 2 votos a favor.
    • No se debe desalentar la votación en contra ya que, por lo general, se pueden obtener comentarios prácticos de ella.
    • Si la votación falla, el defensor puede seguir trabajando en la propuesta, o bien abandonarla. La decisión del defensor se debe anunciar en la lista de distribución.
    • Si el defensor decide seguir trabajando en la propuesta, se puede pedir una votación nueva en cualquier momento, pero a más tardar a los 30 días calendario a partir de la finalización de la votación anterior.
    • Si en el plazo de 30 días calendario a partir de la propuesta original o si a los 30 días calendario desde la finalización de la votación anterior no se pidió una votación, la propuesta se abandona.
  8. Si se abandona la propuesta, se cierra la solicitud de extracción correspondiente.
  9. Si la propuesta se acepta:
    • Google se compromete a fusionar la versión de la solicitud de extracción sometida a votación (siempre que los colaboradores hayan firmado el Contrato de Licencia para Colaboradores) y a implementarla en un plazo de 5 días hábiles.
    • Google se compromete a actualizar oportunamente el repositorio https://github.com/google/gtfs-realtime-bindings. Cualquier confirmación de gtfs-realtime-bindigs que sea resultado de una propuesta debe hacer referencia a la solicitud de extracción de dicha propuesta.
    • No deben incluirse traducciones en la solicitud de extracción original. Google es responsable de actualizar, en algún momento, las traducciones relevantes a los idiomas admitidos. Sin embargo, son bienvenidas las solicitudes de extracción puras de la comunidad y se aceptarán tan pronto como se hayan abordado todos los comentarios editoriales.