Descripción general del proceso de cambio

La especificación GTFS no es definitiva. En cambio, 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. Se espera que esta comunidad de productores y consumidores de datos de GTFS tenga propuestas para extender la especificación a fin de habilitar nuevas capacidades. 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 cambios de la GTFS, junto con un vínculo a la solicitud. Una vez anunciada la solicitud, esta se considera una propuesta. La solicitud de extracción también debe incluir un vínculo al aviso en Grupos de Google para que los usuarios puedan establecer una referencia cruzada sin inconvenientes.

  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.

    • Antes de llamar a votación, al menos un productor y un consumidor de GTFS deben implementar el cambio propuesto. Se espera que los productores de GTFS incluyan el cambio en un feed GTFS de acceso público y que proporcionen un vínculo a esos datos en los comentarios de la solicitud de extracción; por otro lado, también se espera que los consumidores de GTFS proporcionen en los comentarios de la solicitud de extracción un vínculo a una aplicación que utilice el cambio de manera significativa (es decir, que el cambio permita funcionalidades nuevas o mejoradas).
  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.
    • 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.
  10. El resultado final de la solicitud de extracción (aceptada o abandonada) se debe anunciar en la misma conversación de Grupos de Google en la que se anunció originalmente la solicitud de extracción.