GRPC RFCS
การแนะนำ
โปรดอ่านกฎการกำกับดูแลขององค์กร GRPC และแนวทางการสนับสนุนก่อนดำเนินการ
repo นี้มีข้อเสนอการออกแบบสำหรับการเปลี่ยนแปลงคุณสมบัติที่สำคัญสำหรับ GRPC ที่ต้องได้รับการออกแบบล่วงหน้า เป้าหมายของกระบวนการออกแบบล่วงหน้าคือ:
- ให้ทัศนวิสัยที่เพิ่มขึ้นแก่ชุมชนเกี่ยวกับการเปลี่ยนแปลงที่จะเกิดขึ้นและการพิจารณาการออกแบบรอบ ๆ พวกเขา
- ให้ความสามารถในการให้เหตุผลเกี่ยวกับ“ ชุด” ที่ใหญ่กว่าของการเปลี่ยนแปลงที่ใหญ่เกินไปที่จะครอบคลุมทั้งในปัญหาหรือในการประชาสัมพันธ์
- สร้างกระบวนการที่สอดคล้องกันสำหรับการมีส่วนร่วมที่มีโครงสร้างโดยชุมชนเกี่ยวกับการเปลี่ยนแปลงครั้งใหญ่โดยเฉพาะอย่างยิ่งกระบวนการที่ส่งผลกระทบต่อการใช้งานและการใช้งานหลายครั้ง
ข้อกำหนดเบื้องต้น
กระบวนการนี้จะต้องมีการติดตามสำหรับการเปลี่ยนแปลงที่สำคัญใด ๆ กับ GRPC ที่ต้องการการออกแบบ การเปลี่ยนแปลงที่ถือว่ามีนัยสำคัญสามารถ:
- คุณสมบัติที่ต้องการการใช้งานในช่วงเวลาและภาษา
- การเปลี่ยนแปลงกระบวนการที่มีผลต่อวิธีการใช้ผลิตภัณฑ์ GRPC
- ทำลายการเปลี่ยนแปลงของ API สาธารณะ (เช่นการเปลี่ยนแปลงครั้งสำคัญของเซมิเวอร์)
กระบวนการ
- แยก repo และคัดลอกเทมเพลต grfc-template.md
- เปลี่ยนชื่อเป็น
$CategoryName-$Summary เช่น: A6-client-retries.md (ดูคำจำกัดความหมวดหมู่ด้านล่าง)- สำหรับข้อเสนอเฉพาะภาษาให้รวมชื่อของภาษา:
L##-$Language-$Summary ชื่อที่เป็นที่ยอมรับ: core , cpp , csharp , go , java , node , objc , php , python , ruby
- เขียน RFC
- ส่งคำขอดึง
- ใครบางคนจากทีม GRPC จะได้รับมอบหมายให้เป็นผู้อนุมัติซึ่งเป็นส่วนหนึ่งของการตรวจสอบนี้ เมื่อได้รับมอบหมายผู้อนุมัติแล้วเจ้าของจะต้องเริ่มการสนทนาเกี่ยวกับ GRPC-IO และอัปเดต PR ด้วยลิงก์การสนทนา หลังจากทำสิ่งนี้เสร็จแล้วเจ้าของควรอัปเดต GRFC เป็นสถานะของ
In Review คาดว่าผู้อนุมัติจะช่วยเจ้าของตลอดกระบวนการนี้ตามต้องการ - เป็นเวลาอย่างน้อยระยะเวลา 10 วันทำการ (ระยะเวลาแสดงความคิดเห็นขั้นต่ำ) คาดว่าเจ้าของจะตอบสนองต่อความคิดเห็นและทำการอัปเดต RFC เป็นใหม่ให้กับ PR ผ่านกระบวนการการสนทนาจะต้องถูกเก็บไว้ในเธรดที่กำหนดในรายชื่อผู้รับจดหมายเพื่อหลีกเลี่ยงการสนทนาที่แตก เจ้าของได้รับการสนับสนุนให้เรียกร้องข้อเสนอแนะเกี่ยวกับข้อเสนอมากที่สุดในช่วงเวลานี้ ความคิดเห็น PR ควร จำกัด อยู่ที่การจัดรูปแบบและคำศัพท์
- หากมีฉันทามติตามที่ผู้อนุมัติในช่วงระยะเวลาแสดงความคิดเห็นผู้อนุมัติจะทำเครื่องหมายข้อเสนอเป็นขั้นสุดท้ายและกำหนดหมายเลข GRFC เมื่อสิ่งนี้ได้รับมอบหมาย (เป็นส่วนหนึ่งของการปิดการสนทนา) เจ้าของจะอัปเดตสถานะของการประชาสัมพันธ์เป็นขั้นสุดท้ายและส่ง PR การกระทำจะต้องไม่ถูกบีบ ประวัติการกระทำนั้นทำหน้าที่เป็นบันทึกการเปลี่ยนแปลงที่เกิดขึ้นกับข้อเสนอ
ผู้อนุมัติ
- โดยค่าเริ่มต้น
a11r เป็นผู้อนุมัติเว้นแต่ผู้อนุมัติคนอื่นจะได้รับมอบหมายตามข้อเสนอ - หากผู้อนุมัติที่ได้รับมอบหมายและเจ้าของไม่สามารถแก้ไขปัญหาได้อย่างน่าพอใจผู้อนุมัติขั้นสุดท้ายยังคงเป็น
a11r
หมวดหมู่ข้อเสนอ
ข้อเสนอจะต้องมีหมายเลขในการเพิ่มลำดับ
-
#An - ส่งผลกระทบต่อทุกภาษา -
#Pnn - ส่งผลกระทบต่อกระบวนการเช่นกระบวนการข้อเสนอเอง -
#Lnnn - การเปลี่ยนแปลงเฉพาะภาษาของ API ภายนอกหรือการสนับสนุนแพลตฟอร์ม -
#Gnnnn - การเปลี่ยนแปลงระดับโปรโตคอล
สถานะข้อเสนอ
- ผู้สมัครข้อเสนอที่ไม่มีข้อผูกมัดทุกคนเริ่มต้นในร่าง
Draft - หลังจากได้รับการยอมรับสำหรับการตรวจสอบและโพสต์ไปยังกลุ่มแล้วมันจะเข้าสู่สถานะ
In Review - เมื่อได้รับการอนุมัติสำหรับการส่งโดยผู้ตัดสินแล้วมันจะเข้าสู่สถานะ
Final อนุญาตให้มีการเปลี่ยนแปลงเล็กน้อยเท่านั้น (สิ่งที่มีคุณสมบัติเป็นผู้เยาว์ถูกทิ้งให้ผู้อนุมัติ) - หากข้อเสนอจำเป็นต้องกลับมาอีกครั้งจะสามารถย้ายกลับไปที่
Draft หรือ In Review ได้ สิ่งนี้สามารถเกิดขึ้นได้หากมีการค้นพบปัญหาในระหว่างการดำเนินการ ณ จุดนี้กระบวนการตรวจสอบตามที่อธิบายไว้ข้างต้นจะต้องปฏิบัติตาม - เมื่อข้อเสนอเป็น
Final และหากมีการใช้งานด้วยภาษาก็สามารถอัปเดตเป็นสถานะของ Implemented กับภาษาที่ใช้งานอยู่ที่ระบุไว้ (ไม่จำเป็นต้องใช้เวอร์ชันรายชื่อ)
