Visão geral do processo de alteração

A especificação GTFS Realtime não é inflexível. Em vez disso, é uma especificação aberta desenvolvida e mantida pela comunidade de empresas, desenvolvedores e outras partes interessadas de transporte público que usam a GTFS Realtime. Essa comunidade de produtores e consumidores de dados em tempo real da GTFS Realtime pode lançar propostas para ampliar a especificação e permitir novos recursos. Para ajudar a gerenciar esse processo, foram estabelecidos os seguintes procedimentos e orientações.

Processo de alteração da especificação

A especificação, a referência e a documentação oficiais estão escritas em inglês. Se a tradução para outro idioma tiver um sentido diferente do original em inglês, este terá prioridade. Toda a comunicação é realizada em inglês.

  1. Crie uma ramificação git com a atualização de todas as partes relevantes da definição do protocolo, da especificação e dos arquivos de documentação (exceto no caso de traduções).

  2. Crie uma solicitação de envio em https://github.com/google/transit. Ela precisa conter uma descrição detalhada do patch. O criador da solicitação de envio será o defensor.

  3. Após o registro da solicitação, ela precisa ser informada pelo defensor na lista de e-mails da GTFS Realtime. Depois, ela passará a ser considerada uma proposta.

  4. A discussão da proposta prossegue. Os comentários da solicitação devem ser usados como o único fórum de discussão.

    • A discussão durará o tempo que o defensor julgar necessário, mas a duração mínima será de sete dias.
    • O defensor é responsável pela atualização da proposta em tempo hábil (ou seja, a solicitação de envio) com base nos comentários que aceitar.
    • O defensor pode abandonar a proposta a qualquer momento.
  5. Após o intervalo inicial de discussão de sete dias, o defensor pode solicitar uma votação sobre uma versão da proposta a qualquer momento.

  6. A votação dura pelo menos sete dias corridos ou cinco dias úteis na Suíça e termina às 23:59:59 UTC.

    • O defensor precisa anunciar o horário de término específico no início da votação.
    • Durante o período de votação, a proposta pode sofrer apenas alterações editoriais (como erros de digitação e mudanças na redação que não alterem o significado).
    • Qualquer pessoa pode votar sim/não em uma formulário de comentário da solicitação de envio, e os votos podem ser alterados até o fim do período de votação. O usuário deverá atualizar o comentário do voto original se quiser mudar o parecer. Para isso, é necessário adicionar um tachado ao voto original e escrever o novo.
    • Não são considerados votos anteriores ao início do período de votação.
  7. A proposta será aceita se houver um consenso unânime positivo com pelo menos três votos.

    • O voto do proponente não é contabilizado no total de três votos. Por exemplo, se o Proponente X cria uma solicitação de envio e vota sim e os Usuários Y e Z também votam a favor, são contabilizados dois votos para o total de votos positivos.
    • Os votos contrários precisam ser justificados e, preferencialmente, incluir feedback útil.
    • Se a votação rejeitar a proposta, o defensor pode continuar defendendo ou abandoná-la. Qualquer decisão do defensor precisa ser anunciada na lista de e-mails.
    • Se o defensor continuar a trabalhar na proposta, uma nova votação poderá ser solicitada até 30 dias corridos após o fim da votação anterior.
    • Se uma votação não for convocada até 30 dias corridos desde a proposta original ou o fim da votação anterior, a proposta será abandonada.
  8. Se a proposta for abandonada, a solicitação de envio correspondente será encerrada.

  9. Se a proposta for aceita:

    • o Google se comprometerá a mesclar a versão da solicitação de envio aceita por votação (desde que os colaboradores tenham assinado o CLA) e a executá-la em até cinco dias úteis;
    • o Google compromete-se a atualizar o repositório https://github.com/google/gtfs-realtime-bindings em tempo hábil. As confirmações de gtfs-realtime-bindings resultantes de determinada proposta precisam fazer referência à solicitação de envio;
    • traduções não poderão ser incluídas na solicitação de envio original. O Google é responsável por atualizar as traduções relevantes dos idiomas a que oferece suporte. No entanto, solicitações de envio da comunidade relacionadas apenas a traduções são bem-vindas e serão aceitas assim que todos os comentários editoriais forem abordados.