Setiap fitur TensorFlow baru mulai aktif sebagai Request for Comment (RFC).
RFC adalah dokumen yang menjelaskan persyaratan dan usulan perubahan yang akan menyelesaikannya. Secara khusus, RFC akan:
- Diformat sesuai dengan template RFC .
- Dikirim sebagai pull request ke direktori community / rfcs .
- Menjadi subjek diskusi dan pertemuan tinjauan sebelum penerimaan.
Tujuan TensorFlow Request for Comments (RFC) adalah untuk melibatkan komunitas TensorFlow dalam pengembangan, dengan mendapatkan masukan dari pemangku kepentingan dan pakar, dan mengomunikasikan perubahan desain secara luas.
Cara mengirimkan RFC
Sebelum mengirimkan RFC, diskusikan tujuan Anda dengan kontributor dan pengelola proyek dan dapatkan umpan balik awal. Gunakan milis pengembang untuk proyek terkait (developers@tensorflow.org, atau daftar untuk SIG yang relevan).
Buat draf RFC Anda.
- Baca kriteria tinjauan desain
- Ikuti template RFC .
- Beri nama file RFC Anda
YYYYMMDD-descriptive-name.md, denganYYYYMMDDadalah tanggal pengiriman, dandescriptive-nameberkaitan dengan judul RFC Anda. (Misalnya, jika RFC Anda berjudul API Widget Paralel , Anda dapat menggunakan nama file20180531-parallel-widgets.md. - Jika Anda memiliki gambar atau file tambahan lainnya, buat direktori dalam bentuk
YYYYMMDD-descriptive-nameuntuk 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 diskusi desain.
Rekrut sponsor.
- Seorang sponsor harus menjadi pengelola proyek.
- Identifikasi sponsor di RFC, sebelum memposting PR.
Anda boleh memposting RFC tanpa sponsor, tetapi jika dalam sebulan setelah memposting PR masih tidak ada sponsor, itu akan ditutup.
Kirimkan RFC Anda sebagai permintaan tarik ke tensorflow / community / rfcs .
Sertakan tabel header dan konten bagian Objective di komentar pull request Anda, menggunakan Markdown. Sebagai contoh, silakan lihat contoh RFC ini . Sertakan pegangan GitHub dari rekan penulis, pengulas, dan sponsor.
Di bagian atas PR mengidentifikasi berapa lama periode komentar akan berlangsung. Ini harus minimal dua minggu sejak memposting PR.
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 .
Sponsor akan meminta pertemuan komite peninjau, tidak lebih dari dua minggu setelah PR RFC diposting. Jika diskusi berlangsung hidup, tunggu sampai selesai sebelum meninjau. Tujuan dari pertemuan tinjauan adalah untuk menyelesaikan masalah-masalah kecil; konsensus harus dicapai tentang masalah utama sebelumnya.
Rapat dapat menyetujui RFC, menolaknya, atau memerlukan perubahan sebelum dapat dipertimbangkan kembali. RFC yang disetujui akan digabungkan ke dalam komunitas / rfcs , dan RFC yang ditolak akan ditutup PR-nya.
Peserta RFC
Banyak orang terlibat dalam proses RFC:
Penulis RFC - satu atau lebih anggota komunitas yang menulis RFC dan berkomitmen untuk memperjuangkannya melalui proses
Sponsor RFC - pengelola yang mensponsori RFC dan akan menggiringnya melalui proses peninjauan RFC
komite peninjau - sekelompok pengelola yang memiliki tanggung jawab untuk merekomendasikan adopsi RFC
Setiap anggota komunitas dapat membantu dengan memberikan umpan balik tentang apakah RFC akan memenuhi kebutuhan mereka.
Sponsor RFC
Sponsor adalah pengelola proyek yang bertanggung jawab untuk memastikan hasil terbaik dari proses RFC. Ini termasuk:
- Mengadvokasi desain yang diusulkan.
- Memandu RFC agar mematuhi konvensi desain dan gaya yang ada.
- Membimbing komite peninjau untuk mencapai konsensus yang produktif.
- Jika perubahan diminta oleh komite peninjau, pastikan ini dibuat dan minta persetujuan selanjutnya dari anggota komite.
- Jika RFC beralih ke implementasi:
- Memastikan implementasi yang diusulkan sesuai dengan desain.
- Berkoordinasi dengan pihak yang sesuai untuk keberhasilan pelaksanaan lahan.
Komite peninjau RFC
Komite peninjau memutuskan berdasarkan konsensus apakah akan menyetujui, menolak, atau meminta perubahan. Mereka bertanggung jawab untuk:
- Memastikan bahwa item substantif dari umpan balik publik telah dipertanggungjawabkan.
- Menambahkan catatan pertemuan mereka sebagai komentar ke PR.
- Memberikan alasan untuk keputusan mereka.
Konstitusi komite peninjau dapat berubah sesuai dengan gaya tata kelola dan kepemimpinan tertentu dari setiap proyek. Untuk TensorFlow inti, panitia akan terdiri dari kontributor proyek TensorFlow yang memiliki keahlian di area domain yang bersangkutan.
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 berkepentingan dengan 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 umpan balik.
- Bersikaplah sopan dan konstruktif .
Menerapkan 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 di RFC. Ajukan pertanyaan dan diskusikan pendekatannya sebelum mulai bekerja.
- Fitur baru harus menyertakan pengujian unit baru yang memverifikasi bahwa fitur tersebut berfungsi seperti yang diharapkan. Sebaiknya tulis pengujian ini sebelum menulis kode.
- Ikuti Panduan Gaya Kode TensorFlow
- Tambahkan atau perbarui dokumentasi API yang relevan. Referensi RFC di dokumentasi baru.
- Ikuti pedoman lain yang ada di file
CONTRIBUTING.mddi repo proyek yang Anda kontribusikan. - Jalankan pengujian unit sebelum mengirimkan kode Anda.
- Bekerja sama 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. Sebuah fitur baru mungkin ditolak atau membutuhkan revisi yang signifikan pada salah satu tahapan berikut:
- Percakapan desain awal di milis yang relevan.
- Kegagalan merekrut sponsor.
- Keberatan kritis selama fase umpan balik.
- Kegagalan 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 diharapkan gagal pada tahap yang lebih awal, bukan yang lebih baru. RFC yang disetujui bukanlah jaminan komitmen untuk diterapkan, dan penerimaan implementasi RFC yang diusulkan masih tunduk pada proses peninjauan kode yang biasa.
Jika Anda memiliki pertanyaan tentang proses ini, jangan ragu untuk bertanya di milis pengembang atau mengajukan masalah di tensorflow / komunitas .