Ringkasan Proses Perubahan

Spesifikasi GTFS-Realtime tidak bersifat final. Justru, ini adalah spesifikasi terbuka yang dikembangkan dan dikelola oleh komunitas perusahaan transportasi umum, developer, dan pemangku kepentingan lainnya yang menggunakan GTFS-Realtime. Komunitas produsen dan konsumen data GTFS-Realtime ini diharapkan nantinya memiliki proposal untuk memperluas spesifikasi sehingga memungkinkan adanya kemampuan baru. Untuk membantu mengelola proses tersebut, prosedur dan panduan berikut telah ditetapkan.

Proses perubahan spesifikasi

Spesifikasi, referensi, dan dokumentasi resmi ditulis dalam bahasa Inggris. Jika terjemahan ke dalam bahasa lain berbeda dari versi bahasa Inggris aslinya, versi bahasa Inggris yang akan diutamakan. Semua komunikasi dilakukan dalam bahasa Inggris.

  1. Buat git branch dengan update semua bagian file definisi protokol, spesifikasi, dan dokumentasi yang relevan (kecuali untuk terjemahan).

  2. Buat permintaan pull di https://github.com/google/transit. Permintaan pull harus berisi deskripsi patch yang lengkap. Pembuat permintaan pull menjadi advokat.

  3. Setelah terdaftar, permintaan pull harus diumumkan oleh advokatnya di milis GTFS-Realtime. Setelah diumumkan, permintaan pull dianggap sebagai proposal.

  4. Kemudian, diskusi proposal dilakukan. Komentar permintaan pull harus digunakan sebagai satu-satunya forum diskusi.

    • Diskusi dilakukan selama diperlukan oleh advokat, namun setidaknya harus berlangsung selama 7 hari kalender.
    • Advokat bertanggung jawab untuk ketepatan waktu pembaruan proposal (yaitu permintaan pull) berdasarkan komentar yang mereka setujui.
    • Advokat dapat mengklaim bahwa proposal diabaikan kapan saja.
  5. Advokat dapat meminta pemungutan suara untuk versi proposal kapan saja setelah interval 7 hari awal yang diperlukan untuk diskusi.

  6. Pemungutan suara berlangsung selama periode minimum yang cukup untuk mencakup 7 hari kalender penuh dan 5 hari kerja penuh Swiss. Pemungutan suara berakhir pada pukul 23:59:59 UTC.

    • Advokat harus mengumumkan waktu berakhir yang spesifik di awal pemungutan suara.
    • Selama pemungutan suara hanya perubahan editorial pada proposal (kesalahan ketik, susunan kata dapat diubah selama tidak mengubah artinya) yang diizinkan.
    • Setiap orang diizinkan untuk memberikan suara ya/tidak dalam bentuk komentar untuk permintaan pull, dan suara dapat diubah sampai akhir periode pemungutan suara. Jika pemilih mengubah pilihannya, sebaiknya perbarui komentar yang asli dengan mencoret pilihan dan menulis pilihan yang baru.
    • Suara yang diberikan sebelum dimulainya periode pemungutan suara tidak dihitung.
  7. Proposal diterima jika ada konsensus bulat untuk memilih ya dengan minimal 3 suara.

    • Jumlah total 3 suara ini tidak termasuk suara pemohon proposal. Misalnya, jika Pemohon proposal X membuat permintaan pull dan memberi suara ya, dan Pengguna Y dan Z memberi suara ya, berarti total suara untuk ya adalah 2.
    • Suara yang tidak setuju sebaiknya disertai alasan, dan idealnya ada masukan yang dapat ditindaklanjuti.
    • Jika pemungutan suara tersebut gagal, advokat dapat memilih untuk terus menyempurnakan proposal, atau mengabaikan proposal. Apa pun keputusan advokat darus diumumkan di milis.
    • Jika advokat memilih untuk terus menyempurnakan proposal, pemilihan suara baru dapat diminta kapan saja, tetapi tidak boleh lebih dari 30 hari kalender setelah pemilihan suara sebelumnya berakhir.
    • Jika pemungutan suara tidak diminta dalam waktu 30 hari kalender sejak proposal yang pertama atau 30 hari kalender sejak pemungutan suara sebelumnya berakhir, proposal tersebut akan diabaikan.
  8. Jika proposal diabaikan, permintaan pull yang sesuai ditutup.

  9. Jika proposal diterima:

    • Google berkomitmen untuk menggabungkan versi permintaan pull berdasarkan hasil pemungutan suara (asalkan kontributor telah menandatangani CLA), dan melakukan permintaan pull dalam waktu 5 hari kerja.
    • Google berkomitmen untuk memperbarui repositori https://github.com/google/gtfs-realtime-bindings secara tepat waktu. Komitmen terhadap gtfs-realtime-bindings yang merupakan hasil dari proposal harus merujuk kepada permintaan pull proposal.
    • Terjemahan tidak boleh disertakan ke dalam permintaan pull asli. Google pada akhirnya bertanggung jawab untuk memperbarui terjemahan yang relevan ke dalam bahasa yang didukung, tetapi terjemahan asli permintaan pull dari komunitas diperbolehkan dan akan diterima segera setelah semua komentar editorial ditangani.