GRPC RFCS
Perkenalan
Harap baca aturan tata kelola organisasi GRPC dan pedoman kontribusi sebelum melanjutkan.
Repo ini berisi proposal desain untuk perubahan fitur substansial untuk GRPC yang perlu dirancang di muka. Tujuan dari proses desain dimuka adalah untuk:
- Berikan visibilitas yang meningkat kepada masyarakat tentang perubahan yang akan datang dan pertimbangan desain di sekitar mereka.
- Berikan kemampuan untuk beralasan tentang "set" perubahan yang lebih besar yang terlalu besar untuk dibahas baik dalam masalah atau dalam PR.
- Membangun proses yang konsisten untuk partisipasi terstruktur oleh masyarakat pada perubahan besar, terutama yang berdampak pada beberapa runtime dan implementasi.
Prasyarat
Proses ini perlu diikuti untuk setiap perubahan signifikan ke GRPC yang membutuhkan desain. Perubahan yang dianggap signifikan bisa:
- Fitur yang membutuhkan implementasi di seluruh runtimes dan bahasa.
- Perubahan proses yang memengaruhi bagaimana produk GRPC diimplementasikan.
- Memecahkan perubahan pada API publik (IE SEMVER Mayor Changes).
Proses
- Garpu repo dan salin template grfc-template.md.
- Ganti nama menjadi
$CategoryName-$Summary , mis.: A6-client-retries.md (lihat definisi kategori di bawah)- Untuk proposal khusus bahasa, sertakan nama bahasa:
L##-$Language-$Summary . Nama Canonical: core , cpp , csharp , go , java , node , objc , php , python , ruby .
- Tuliskan RFC.
- Kirimkan permintaan tarik.
- Seseorang dari tim GRPC akan ditugaskan sebagai pemberi persetujuan sebagai bagian dari ulasan ini. Setelah pemberi persetujuan ditugaskan, pemilik perlu memulai diskusi tentang GRPC-IO dan memperbarui PR dengan tautan diskusi. Setelah ini selesai, pemilik harus memperbarui GRFC ke keadaan
In Review . Diharapkan bahwa pemberi persetujuan akan membantu pemilik sepanjang proses ini sesuai kebutuhan. - Untuk setidaknya periode 10 hari kerja (periode komentar minimum), diharapkan pemilik akan menanggapi komentar dan membuat pembaruan ke RFC sebagai komitmen baru untuk PR. Melalui prosesnya, diskusi perlu disimpan ke utas yang ditunjuk dalam milis untuk menghindari percakapan pecah. Pemilik didorong untuk meminta umpan balik sebanyak mungkin pada proposal selama periode ini. Komentar PR harus terbatas pada pemformatan dan kosa kata.
- Jika ada konsensus yang dianggap oleh pemberi persetujuan selama periode komentar, pemberi persetujuan akan menandai proposal sebagai final dan menugaskannya nomor GRFC. Setelah ini ditetapkan (sebagai bagian dari penutupan diskusi), pemilik akan memperbarui keadaan PR sebagai final dan mengirimkan PR. Komitmen tidak boleh terjepit; Sejarah komit berfungsi sebagai log perubahan yang dibuat untuk proposal.
Pemberi persetujuan
- Secara default
a11r adalah pemberi persetujuan kecuali jika pemberi persetujuan lain ditugaskan berdasarkan per proposal. - Jika pemberi persetujuan yang ditugaskan dan pemilik tidak dapat menyelesaikan masalah dengan memuaskan, pemberi persetujuan akhir masih
a11r .
Kategori proposal
Proposal harus diberi nomor dalam urutan yang meningkat.
-
#An - mempengaruhi semua bahasa. -
#Pnn - mempengaruhi proses, seperti proses proposal itu sendiri. -
#Lnnn - Perubahan spesifik bahasa untuk API eksternal atau dukungan platform. -
#Gnnnn - Perubahan tingkat protokol.
Status proposal
- Setiap kandidat proposal yang tidak berkomitmen dimulai di negara
Draft . - Setelah diterima untuk ditinjau dan diposting ke grup, ia memasuki negara
In Review . - Setelah disetujui untuk diserahkan oleh Arbiter, ia masuk ke keadaan
Final . Hanya perubahan kecil yang diizinkan (yang memenuhi syarat sebagai minor yang diserahkan kepada pemberi persetujuan). - Jika suatu proposal perlu ditinjau kembali, itu dapat dipindahkan kembali ke
Draft atau In Review . Ini dapat terjadi jika masalah ditemukan selama implementasi. Pada titik mana, proses peninjauan seperti yang dijelaskan di atas harus diikuti. - Setelah proposal
Final dan jika telah diimplementasikan oleh suatu bahasa, itu dapat diperbarui ke status Implemented dengan bahasa implementasi yang terdaftar. (Versi daftar tidak diperlukan.)
