rfcs
1.0.0
การเปลี่ยนแปลงหลายอย่าง รวมถึงการแก้ไขข้อบกพร่องและการปรับปรุงเอกสารสามารถนำไปใช้และตรวจสอบได้ผ่านเวิร์กโฟลว์คำขอดึง GitHub ปกติ
แม้ว่าการเปลี่ยนแปลงบางอย่างจะ "สำคัญ" และเราขอให้สิ่งเหล่านี้ผ่านกระบวนการออกแบบเล็กน้อยและสร้างฉันทามติระหว่างทีมงานหลักของ React
กระบวนการ "RFC" (ขอความคิดเห็น) มีวัตถุประสงค์เพื่อให้เส้นทางที่สอดคล้องกันและมีการควบคุมสำหรับคุณสมบัติใหม่ในการเข้าสู่โครงการ
รายการ RFC ที่ใช้งานอยู่
เพื่อที่จะยอมรับคำขอดึงของคุณ เราต้องการให้คุณส่ง CLA คุณต้องทำสิ่งนี้เพียงครั้งเดียว ดังนั้นหากคุณเคยทำสิ่งนี้กับโปรเจ็กต์โอเพ่นซอร์สของ Facebook อื่น คุณก็พร้อมแล้ว หากคุณส่งคำขอดึงข้อมูลเป็นครั้งแรก เพียงแจ้งให้เราทราบว่าคุณได้ปฏิบัติตาม CLA เรียบร้อยแล้ว และเราจะตรวจสอบอีกครั้งด้วยชื่อผู้ใช้ GitHub ของคุณ
กรอก CLA ของคุณที่นี่
คุณควรพิจารณาใช้กระบวนการนี้หากคุณต้องการทำการเปลี่ยนแปลง "สำคัญ" ใน React หรือเอกสารประกอบของกระบวนการนี้ ตัวอย่างบางส่วนที่จะได้รับประโยชน์จาก RFC ได้แก่:
คุณลักษณะใหม่ที่สร้างพื้นที่ผิว API ใหม่และจะต้องมีแฟล็กคุณลักษณะหากนำมาใช้
การลบฟีเจอร์ที่จัดส่งแล้วโดยเป็นส่วนหนึ่งของช่องทางการเผยแพร่
การแนะนำการใช้งานหรือแบบแผนสำนวนใหม่ แม้ว่าจะไม่รวมการเปลี่ยนแปลงโค้ดใน React ก็ตาม
การเปลี่ยนแปลงบางอย่างไม่จำเป็นต้องมี RFC:
การใช้ถ้อยคำใหม่ การจัดระเบียบใหม่ หรือการปรับโครงสร้างใหม่
การเพิ่มหรือการลบคำเตือน
ส่วนเพิ่มเติมที่ปรับปรุงวัตถุประสงค์ เกณฑ์คุณภาพเชิงตัวเลขอย่างเคร่งครัด (เร่งความเร็ว การสนับสนุนเบราว์เซอร์ที่ดีขึ้น)
การเพิ่มเติมมีแนวโน้มที่จะ สังเกตเห็นได้โดย ผู้ดำเนินการของ React รายอื่นเท่านั้น ซึ่งผู้ใช้ของ React จะมองไม่เห็น
เป็นการยากที่จะเขียน RFC ที่จะได้รับการยอมรับ อย่างไรก็ตาม สิ่งนี้ไม่ควรทำให้คุณท้อใจจากการเขียน
React มีพื้นที่ผิว API ที่จำกัดมากและแต่ละฟีเจอร์จำเป็นต้องทำงานร่วมกับฟีเจอร์อื่นๆ ทั้งหมดได้อย่างราบรื่น แม้กระทั่งในหมู่สมาชิกในทีมที่ทำงานเต็มเวลาใน React ทุกวัน การเพิ่มขึ้นและได้รับบริบทที่เพียงพอในการเขียน RFC ที่ดีก็ต้องใช้เวลามากกว่าหนึ่งปี
ในทางปฏิบัติ React RFC มีจุดประสงค์สองประการ:
RFC ของทีม React จะถูกส่งโดยสมาชิกทีม React หลังจากการออกแบบ การอภิปราย และการทดลองที่กว้างขวาง (บางครั้ง หลายเดือนหรือหลายปี) ในทางปฏิบัติ ประกอบด้วย RFC ส่วนใหญ่ที่รวมเข้าด้วยกันแล้ว วัตถุประสงค์ของ RFC เหล่านี้คือการดูตัวอย่างการออกแบบสำหรับชุมชน และเพื่อให้โอกาสในการแสดงความคิดเห็น เราอ่านทุกความคิดเห็นเกี่ยวกับ RFC ที่เราเผยแพร่ ตอบคำถาม และบางครั้งก็รวมข้อเสนอแนะไว้ในข้อเสนอด้วย เนื่องจากเวลาของเรามีจำกัด เราจึงไม่มีแนวโน้มที่จะเขียน RFC สำหรับฟีเจอร์ React เว้นแต่เราจะมั่นใจมากว่ามันเข้ากับการออกแบบ แม้ว่าอาจดูเหมือน React Team RFC ส่วนใหญ่จะได้รับการยอมรับอย่างง่ายดาย แต่ในทางปฏิบัติเป็นเพราะ 98% ของไอเดียถูกทิ้งไว้ที่ห้องตัด ส่วนที่เหลืออีก 2% ที่เรารู้สึกมั่นใจมากและได้รับความเห็นพ้องต้องกันจากทีมคือสิ่งที่เราประกาศเป็น RFC สำหรับคำติชมจากชุมชน
ทุกคนสามารถส่ง RFC ของชุมชน ได้ ในทางปฏิบัติ RFC ของชุมชนส่วนใหญ่ไม่ถูกรวมเข้าด้วยกัน สาเหตุที่พบบ่อยที่สุดที่เราปฏิเสธ RFC ก็คือ RFC มีช่องว่างหรือข้อบกพร่องในการออกแบบที่สำคัญ ไม่ทำงานร่วมกับคุณสมบัติอื่นๆ ทั้งหมด หรือไม่อยู่ในมุมมองของเราเกี่ยวกับขอบเขตของ React อย่างไรก็ตาม การรวมไม่ใช่เกณฑ์ความสำเร็จเพียงอย่างเดียวสำหรับ RFC แม้ว่าการออกแบบ API จะไม่ตรงกับทิศทางที่เราต้องการ แต่เราพบว่าการสนทนา RFC มีคุณค่ามากสำหรับการวิจัยและแรงบันดาลใจ เราไม่ได้ตรวจสอบ RFC ของชุมชนอย่างทันท่วงทีเสมอไป แต่เมื่อใดก็ตามที่เราเริ่มทำงานในพื้นที่ที่เกี่ยวข้อง เราจะตรวจสอบ RFC ในพื้นที่นั้น และตรวจสอบกรณีการใช้งานและข้อกังวลที่สมาชิกชุมชนได้โพสต์ เมื่อคุณส่ง RFC เป้าหมายหลักของคุณไม่จำเป็นต้องรวมเข้ากับ React ตามที่เป็นอยู่ แต่เพื่อสร้างการสนทนาที่หลากหลายกับสมาชิกชุมชน หากข้อเสนอของคุณได้รับการยอมรับในภายหลัง ก็ถือว่าดีมาก แต่ถึงแม้ไม่เป็นเช่นนั้นก็จะไม่สูญเปล่า การอภิปรายที่เกิดขึ้นมักจะแจ้งข้อเสนอถัดไปในพื้นที่ปัญหาเดียวกัน ไม่ว่าจะมาจากชุมชนหรือจากทีม React ผู้เขียนห้องสมุดหลายคนกำลังอ่านการสนทนา ดังนั้น RFC จึงมักนำไปสู่การทดลองของชุมชนและวิธีแก้ปัญหาเกี่ยวกับพื้นที่ผู้ใช้
เราใช้ความเข้มงวดในระดับเดียวกันทั้งกับ React Team RFC และ Community RFC ความแตกต่างหลักระหว่างทั้งสองอยู่ในขั้นตอนการออกแบบ: React Team RFC มีแนวโน้มที่จะถูกส่งเมื่อสิ้นสุดกระบวนการออกแบบ ในขณะที่ Community RFC มีแนวโน้มที่จะถูกส่งตั้งแต่เริ่มต้นเพื่อเป็นการเริ่มต้น
กล่าวโดยสรุป หากต้องการเพิ่มฟีเจอร์หลักให้กับ React ก่อนอื่นเราจะรวม RFC เข้ากับ RFC repo เป็นไฟล์มาร์กดาวน์ เมื่อถึงจุดนั้น RFC จะ 'ใช้งานอยู่' และอาจนำไปใช้โดยมีเป้าหมายเพื่อรวมไว้ใน React ในที่สุด
แยก repo RFC http://github.com/reactjs/rfcs
คัดลอก 0000-template.md ไปที่ text/0000-my-feature.md (โดยที่ 'my-feature' เป็นคำอธิบาย อย่าเพิ่งกำหนดหมายเลข RFC)
กรอก RFC ใส่ใจในรายละเอียด: RFC ที่ไม่แสดงแรงจูงใจที่น่าเชื่อ แสดงให้เห็นถึงความเข้าใจในผลกระทบของการออกแบบ หรือไม่จริงใจเกี่ยวกับข้อเสียหรือทางเลือกอื่นๆ มักจะได้รับการตอบรับไม่ดี
ส่งคำขอดึง ตามคำขอดึง RFC จะได้รับคำติชมการออกแบบจากชุมชนขนาดใหญ่ และผู้เขียนควรเตรียมพร้อมที่จะแก้ไขเพื่อตอบสนอง
สร้างฉันทามติและบูรณาการข้อเสนอแนะ RFC ที่ได้รับการสนับสนุนในวงกว้างมีแนวโน้มที่จะมีความคืบหน้ามากกว่า RFC ที่ไม่ได้รับความคิดเห็นใดๆ
ในที่สุดทีมงานจะตัดสินใจว่า RFC เป็นตัวเลือกที่จะรวมไว้ใน React หรือไม่ โปรดทราบว่าการตรวจสอบโดยทีมอาจใช้เวลานาน และเราขอแนะนำให้คุณขอให้สมาชิกของชุมชนตรวจสอบก่อน
RFC ที่เป็นผู้สมัครเพื่อรวมไว้ใน React จะเข้าสู่ "ช่วงแสดงความคิดเห็นขั้นสุดท้าย" เป็นเวลา 3 วันตามปฏิทิน จุดเริ่มต้นของช่วงเวลานี้จะมีการส่งสัญญาณพร้อมความคิดเห็นและแท็กในคำขอดึง RFC
RFC สามารถแก้ไขได้ตามคำติชมจากทีมและชุมชน การแก้ไขที่สำคัญอาจทำให้มีช่วงแสดงความคิดเห็นขั้นสุดท้ายใหม่
RFC อาจถูกปฏิเสธโดยทีมหลังจากการอภิปรายสาธารณะได้ยุติลง และมีการแสดงความคิดเห็นเพื่อสรุปเหตุผลในการปฏิเสธ สมาชิกในทีมควรปิดคำขอดึงที่เกี่ยวข้องกับ RFC
RFC อาจได้รับการยอมรับเมื่อสิ้นสุดช่วงแสดงความคิดเห็นขั้นสุดท้าย สมาชิกในทีมจะรวมคำขอดึงที่เกี่ยวข้องกับ RFC ซึ่ง ณ จุดนี้ RFC จะกลายเป็น 'ใช้งานอยู่'
เมื่อ RFC เปิดใช้งานแล้ว ผู้เขียนสามารถนำไปใช้งานและส่งคุณสมบัติเป็นคำขอดึงไปยัง React repo การเป็น 'ใช้งานอยู่' ไม่ใช่ตรายาง และโดยเฉพาะอย่างยิ่งยังไม่ได้หมายความว่าคุณลักษณะนี้จะถูกรวมเข้าด้วยกันในท้ายที่สุด หมายความว่าทีมงานหลักได้ตกลงในหลักการแล้วและสามารถรวมเข้าด้วยกันได้
นอกจากนี้ ข้อเท็จจริงที่ว่า RFC ที่กำหนดได้รับการยอมรับและ 'ใช้งานอยู่' ไม่ได้ไม่ได้หมายความว่าอะไรเกี่ยวกับลำดับความสำคัญที่กำหนดให้กับการใช้งาน หรือไม่ว่าจะมีใครกำลังทำงานอยู่หรือไม่ก็ตาม
การปรับเปลี่ยน RFC ที่ใช้งานอยู่สามารถทำได้ในการติดตามผล PR เรามุ่งมั่นที่จะเขียน RFC แต่ละรายการในลักษณะที่จะสะท้อนถึงการออกแบบขั้นสุดท้ายของคุณสมบัติ แต่ลักษณะของกระบวนการหมายความว่าเราไม่สามารถคาดหวังทุก RFC ที่รวมเข้าด้วยกันเพื่อสะท้อนถึงผลลัพธ์สุดท้ายที่จะเป็นอย่างไรในเวลาของการเปิดตัวหลักครั้งถัดไป ดังนั้นเราจึงพยายามทำให้เอกสาร RFC แต่ละฉบับค่อนข้างซิงค์กับคุณลักษณะภาษาตามที่วางแผนไว้ โดยติดตามการเปลี่ยนแปลงดังกล่าวผ่านการร้องขอการติดตามผลไปยังเอกสาร
ผู้เขียน RFC ไม่มีภาระผูกพันในการดำเนินการ แน่นอนว่าผู้เขียน RFC (เช่นเดียวกับนักพัฒนาอื่นๆ) สามารถโพสต์การใช้งานเพื่อตรวจสอบได้หลังจากที่ RFC ได้รับการยอมรับแล้ว
หากคุณสนใจที่จะใช้งาน RFC ที่ 'ใช้งานอยู่' แต่ไม่สามารถระบุได้ว่ามีคนอื่นกำลังดำเนินการอยู่หรือไม่ อย่าลังเลที่จะถาม (เช่น แสดงความคิดเห็นเกี่ยวกับปัญหาที่เกี่ยวข้อง)
ในปัจจุบัน ทีม React ไม่สามารถดำเนินการตรวจสอบ RFC ได้ทันเวลา เมื่อคุณส่ง RFC เป้าหมายหลักของคุณควรเป็นการขอความคิดเห็นจากชุมชนและสร้างการสนทนาที่หลากหลาย ทีม React จะประเมินรายการโครงการและลำดับความสำคัญในปัจจุบันอีกครั้งทุกๆ หลายเดือน แม้ว่า RFC จะได้รับการออกแบบมาอย่างดี แต่เราก็มักจะไม่สามารถดำเนินการบูรณาการได้ทันที อย่างไรก็ตาม เราพบว่าการกลับมาดู RFC ที่เปิดอยู่ทุกๆ สองสามเดือนอีกครั้ง และดูว่ามีสิ่งใดที่ดึงดูดสายตาเราหรือไม่ เมื่อใดก็ตามที่เราเริ่มทำงานในพื้นที่ปัญหาใหม่ เรายังต้องแน่ใจว่าได้ตรวจสอบงานก่อนหน้าและการสนทนาใน RFC ที่เกี่ยวข้อง และมีส่วนร่วมกับพวกเขา
เราอ่าน RFC ทั้งหมดภายในไม่กี่สัปดาห์หลังจากส่ง หากเราคิดว่าการออกแบบนั้นเหมาะกับ React เป็นอย่างดี และหากเราพร้อมที่จะประเมิน เราจะพยายามตรวจสอบให้เร็วขึ้น หากเราลังเลเกี่ยวกับการออกแบบหรือมีข้อมูลไม่เพียงพอที่จะประเมิน เราจะปล่อยให้มันเปิดทิ้งไว้จนกว่าจะได้รับคำติชมจากชุมชนเพียงพอ เราทราบดีว่าเป็นเรื่องน่าหงุดหงิดที่ไม่ได้รับการตรวจสอบอย่างทันท่วงที แต่คุณสามารถมั่นใจได้ว่างานที่คุณทุ่มเทให้กับ RFC นั้นไม่สูญเปล่า
กระบวนการ RFC ของ React เป็นแรงบันดาลใจมาจากกระบวนการ Yarn RFC กระบวนการ Rust RFC และกระบวนการ Ember RFC
เราได้เปลี่ยนแปลงไปแล้วในอดีตเพื่อตอบสนองต่อคำติชม และเรายินดีที่จะเปลี่ยนแปลงอีกครั้งหากจำเป็น
