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, desarrolladores 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 establecieron los siguientes lineamientos y procedimientos.

Proceso de enmienda de la especificación

La especificación, la referencia y la 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 la especificación GTFS Realtime. Una vez anunciada, la solicitud se considera una propuesta.

  4. El paso siguiente es el debate sobre la propuesta. Los comentarios sobre la solicitud de extracción se deben usar como el único foro de debate.

    • El debate dura el tiempo que el proponedor lo considere necesario, pero debe ser de, al menos, 7 días calendario.
    • El proponedor es responsable de la actualización oportuna de la propuesta (es decir, la solicitud de extracción), en función de los comentarios que se aceptan en el foro.
    • El proponedor puede determinar que se abandona la propuesta en cualquier momento.
  5. El proponedor 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 proponedor 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 extracción 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 proponedor no cuenta para el total de 3 votos. Por ejemplo, si el proponedor X presenta una solicitud de extracción y vota a favor, y luego los usuarios A y B 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 proponedor puede seguir trabajando en la propuesta, o bien abandonarla. La decisión del proponedor se debe anunciar en la lista de distribución.
    • Si el proponedor 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 combinar 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-bindings 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.