Visão geral do processo de alteração

A especificação GTFS Realtime não é rígida. Em vez disso, é uma especificação aberta desenvolvida e mantida pela comunidade de agências, desenvolvedores e outras partes interessadas de transportes públicos que usam a GTFS Realtime. Espera-se que essa comunidade de produtores e consumidores de dados GTFS Realtime real tenha 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 sentido 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, a especificação e os 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 anunciada pelo defensor na lista de e-mails da GTFS Realtime. Depois de anunciada, a solicitação de envio é considerada uma proposta.
  4. A discussão da proposta prossegue. Os comentários da solicitação pull devem ser usados como o único fórum de discussão.
    • A discussão durará o tempo que o defensor julgar necessário, mas precisará ter pelo menos sete dias.
    • O defensor é responsável pela atualização da proposta em tempo hábil (ou seja, a solicitação pull) 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 completos e 5 dias úteis da Suíça completos. A votação 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 pull, e os votos podem ser alterados até o final do período de votação. Se um usuário mudar seu voto, recomenda-se fazê-lo atualizando o comentário do voto original. Para isso, deve-se formatar o voto original com tachado e escrever o novo voto.
    • Não são considerados votos anteriores ao início do período de votação.
  7. A proposta é 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 pull e vota sim, e os usuários Y e Z votam sim, 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 optar por continuar o trabalho 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 a qualquer momento até 30 dias após o final da votação anterior.
    • Se não for convocada uma votação até 30 dias corridos desde a proposta original ou 30 dias corridos desde o final 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 podem ser incluídas na solicitação de envio original. O Google é responsável por atualizar traduções relevantes dos idiomas a que oferece suporte. No entanto, solicitações de envio da comunidade que tratam apenas de traduções são bem-vindas e serão aceitas assim que todos os comentários editoriais forem abordados.