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 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 GTFS, junto con un vínculo a la solicitud. Una vez anunciada, la solicitud 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 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.
    • Antes de llamar a votación, al menos, un productor y un consumidor de GTFS deben implementar el cambio propuesto. Se espera que el(los) productor(es) de GTFS incluya(n) el cambio en un feed GTFS de acceso público y que proporcione(n) un vínculo a esos datos en los comentarios de la solicitud de incorporación de cambios; por otro lado, también se espera que el(los) consumidor(es) de GTFS proporcione(n) un vínculo en los comentarios de la solicitud de incorporación de cambios 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 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.
    • Las traducciones de la propuesta no se deben incluir en la solicitud de incorporación de cambios original. Google es responsable de actualizar, eventualmente, las traducciones relevantes a los idiomas admitidos. Sin embargo, las traducciones de la solicitud de incorporación de cambios realizadas exclusivamente por la comunidad son bienvenidas 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 los Grupos de Google donde la solicitud de extracción se anunció originalmente.