Proses RFC TensorFlow

Setiap fitur TensorFlow baru dimulai sebagai Permintaan Komentar (RFC).

RFC adalah dokumen yang menjelaskan persyaratan dan usulan perubahan untuk menyelesaikannya. Secara khusus, RFC akan:

• Diformat sesuai dengan templat RFC .
• Dikirim sebagai permintaan tarik ke direktori komunitas/rfcs .
• Tunduk pada diskusi dan pertemuan peninjauan sebelum penerimaan.

Tujuan Permintaan Komentar (RFC) TensorFlow adalah untuk melibatkan komunitas TensorFlow dalam pengembangan, dengan mendapatkan masukan dari pemangku kepentingan dan pakar, dan mengkomunikasikan perubahan desain secara luas.

Cara mengirimkan RFC

1. Sebelum mengirimkan RFC, diskusikan tujuan Anda dengan kontributor dan pengelola proyek dan dapatkan masukan awal. Gunakan milis pengembang untuk proyek yang bersangkutan (developers@tensorflow.org, atau daftar untuk SIG yang relevan).

2. Draf RFC Anda.

   • Baca kriteria tinjauan desain
   • Ikuti templat RFC .
   • Beri nama file RFC Anda YYYYMMDD-descriptive-name.md , dengan YYYYMMDD adalah tanggal penyerahan, dan descriptive-name berkaitan dengan judul RFC Anda. (Misalnya, jika RFC Anda diberi judul Parallel Widgets API , Anda dapat menggunakan nama file 20180531-parallel-widgets.md .
   • Jika Anda memiliki gambar atau file tambahan lainnya, buatlah direktori dengan format YYYYMMDD-descriptive-name untuk menyimpan file tersebut.

   Setelah menulis draf RFC, dapatkan umpan balik dari pengelola dan kontributor sebelum mengirimkannya.

   Menulis kode implementasi bukanlah suatu keharusan, tetapi dapat membantu merancang diskusi.

3. Rekrut sponsor.

   • Sponsor harus menjadi pengelola proyek.
   • Identifikasi sponsor di RFC, sebelum memposting PR.

   Anda boleh memposting RFC tanpa sponsor, namun jika dalam waktu satu bulan setelah memposting PR masih belum ada sponsor, maka akan ditutup.

4. Kirimkan RFC Anda sebagai permintaan tarik ke tensorflow/community/rfcs .

   Sertakan tabel header dan konten bagian Tujuan dalam komentar permintaan penarikan Anda, menggunakan Markdown. Sebagai contoh, silakan lihat contoh RFC ini . Sertakan nama pengguna GitHub dari rekan penulis, pengulas, dan sponsor.

   Di bagian atas PR, tentukan berapa lama periode komentar. Ini harus memakan waktu minimal dua minggu sejak PR diposkan.

5. Kirim email ke milis pengembang dengan deskripsi singkat, tautan ke PR, dan permintaan peninjauan. Ikuti format surat sebelumnya, seperti yang Anda lihat di contoh ini .

6. Sponsor akan meminta diadakannya rapat komite peninjau, paling cepat dua minggu setelah PR RFC dipublikasikan. Jika diskusi berlangsung meriah, tunggulah sampai selesai sebelum melakukan tinjauan. Tujuan dari pertemuan peninjauan adalah untuk menyelesaikan masalah-masalah kecil; konsensus harus dicapai mengenai isu-isu besar sebelumnya.

7. Rapat dapat menyetujui RFC, menolaknya, atau memerlukan perubahan sebelum dapat dipertimbangkan kembali. RFC yang disetujui akan digabungkan menjadi community/rfcs , dan RFC yang ditolak akan ditutup PR-nya.

peserta RFC

Banyak orang yang terlibat dalam proses RFC:

• Penulis RFC — satu atau lebih anggota komunitas yang menulis RFC dan berkomitmen untuk memperjuangkannya melalui proses tersebut

• Sponsor RFC — pengelola yang mensponsori RFC dan akan memandunya melalui proses peninjauan RFC

• komite peninjau — sekelompok pengelola yang memiliki tanggung jawab untuk merekomendasikan penerapan RFC

• Setiap anggota komunitas dapat membantu dengan memberikan umpan balik mengenai apakah RFC akan memenuhi kebutuhan mereka.

Sponsor RFC

Sponsor adalah pengelola proyek yang bertanggung jawab memastikan hasil terbaik dari proses RFC. Ini termasuk:

• Mengadvokasi desain yang diusulkan.
• Memandu RFC untuk mematuhi konvensi desain dan gaya yang ada.
• Memandu komite peninjau untuk mencapai konsensus yang produktif.
• Jika perubahan diminta oleh komite peninjau, pastikan perubahan tersebut dilakukan dan mintalah persetujuan selanjutnya dari anggota komite.
• Jika RFC beralih ke implementasi:
  • Memastikan implementasi yang diusulkan mematuhi desain.
  • Berkoordinasi dengan pihak-pihak yang berkepentingan untuk menyukseskan pelaksanaan pertanahan.

komite peninjau RFC

Komite peninjau memutuskan berdasarkan konsensus apakah akan menyetujui, menolak, atau meminta perubahan. Mereka bertanggung jawab untuk:

• Memastikan bahwa hal-hal substantif dari masukan masyarakat telah diperhitungkan.
• Menambahkan catatan pertemuan mereka sebagai komentar pada PR.
• Memberikan alasan atas keputusan mereka.

Bentuk komite peninjau dapat berubah sesuai dengan gaya tata kelola dan kepemimpinan masing-masing proyek. Untuk TensorFlow inti, panitia akan terdiri dari kontributor proyek TensorFlow yang memiliki keahlian di bidang domain terkait.

Anggota komunitas dan proses RFC

Tujuan RFC adalah memastikan komunitas terwakili dengan baik dan dilayani oleh perubahan baru pada TensorFlow. Merupakan tanggung jawab anggota masyarakat untuk berpartisipasi dalam meninjau RFC jika mereka mempunyai kepentingan terhadap hasilnya.

Anggota komunitas yang tertarik dengan RFC harus:

• Berikan umpan balik sesegera mungkin untuk memberikan waktu yang cukup untuk pertimbangan.
• Baca RFC secara menyeluruh sebelum memberikan masukan.
• Bersikaplah sopan dan konstruktif .

Menerapkan fitur-fitur baru

Setelah RFC disetujui, implementasi dapat dimulai.

Jika Anda sedang mengerjakan kode baru untuk mengimplementasikan RFC:

• Pastikan Anda memahami fitur dan desain yang disetujui dalam RFC. Ajukan pertanyaan dan diskusikan pendekatannya sebelum mulai bekerja.
• Fitur baru harus menyertakan pengujian unit baru yang memverifikasi bahwa fitur berfungsi seperti yang diharapkan. Merupakan ide bagus untuk menulis tes ini sebelum menulis kode.
• Ikuti Panduan Gaya Kode TensorFlow
• Tambahkan atau perbarui dokumentasi API yang relevan. Referensi RFC dalam dokumentasi baru.
• Ikuti pedoman lain yang tercantum dalam file CONTRIBUTING.md di repo proyek tempat Anda berkontribusi.
• Jalankan pengujian unit sebelum mengirimkan kode Anda.
• Bekerja samalah dengan sponsor RFC agar berhasil mendapatkan kode baru.

Menjaga standar tetap tinggi

Meskipun kami mendorong dan merayakan setiap kontributor, standar penerimaan RFC sengaja dijaga tetap tinggi. Fitur baru mungkin ditolak atau memerlukan revisi signifikan pada salah satu tahapan berikut:

• Percakapan desain awal di milis yang relevan.
• Kegagalan merekrut sponsor.
• Keberatan kritis selama fase umpan balik.
• Kegagalan untuk mencapai konsensus selama tinjauan desain.
• Kekhawatiran yang muncul selama implementasi (misalnya: ketidakmampuan untuk mencapai kompatibilitas ke belakang, kekhawatiran tentang pemeliharaan).

Jika proses ini berfungsi dengan baik, RFC diperkirakan akan gagal pada tahap awal, bukan tahap selanjutnya. RFC yang disetujui tidak menjamin adanya komitmen untuk diterapkan, dan penerimaan penerapan RFC yang diusulkan masih tunduk pada proses peninjauan kode seperti biasa.

Jika Anda memiliki pertanyaan tentang proses ini, silakan bertanya di milis pengembang atau ajukan masalah di tensorflow/community .