The TC39 Process
TC39 หรือชื่อเต็มว่า Ecma Technical Committee 39 คือกลุ่มคนที่ดูแลและพัฒนาภาษา ECMAScript รวมถึงเป็นคนเขียน specification อย่างเป็นทางการของภาษา ภาษา JavaScript ที่เราใช้กันทุกวันนี้ก็พัฒนามาจากที่นี่แหละ กลุ่มนี้ทำงานกันด้วยระบบ “เห็นพ้องต้องกัน” (consensus) และมีสิทธิ์ปรับเปลี่ยน spec ได้ตามที่เห็นว่าเหมาะสม
แต่โดยทั่วไปแล้ว การจะเปลี่ยนแปลงอะไรใน spec ก็มีกระบวนการที่ชัดเจนอยู่เหมือนกัน
เรื่องของ Stages
เวลาจะเพิ่ม feature ใหม่ ๆ ให้ภาษานี้ เค้าจะมีขั้นตอนให้ไอเดียค่อย ๆ เติบโต ตั้งแต่เป็นแค่แนวคิด จนกลายเป็น feature จริงที่มี spec ครบ มี test พร้อม และมีคน implement แล้วหลายเจ้า
กระบวนการนี้แบ่งออกเป็น 6 ขั้น เริ่มจากขั้น strawperson (เหมือนเป็นเวทีให้เสนอไอเดียเบื้องต้น) แล้วต่อด้วยอีก 5 ขั้นที่เรียกว่า maturity stages หรือก็คือขั้นที่ค่อย ๆ พัฒนาให้ feature นั้นสมบูรณ์ขึ้นไปเรื่อย ๆ โดยทุกครั้งที่จะเลื่อนไปขั้นถัดไป จะต้องผ่านความเห็นชอบจาก committee ก่อนเสมอ
ตั้งแต่ Stage 1 ขึ้นไป ข้อเสนอนั้นจะถือว่าเป็นของ committee อย่างเป็นทางการแล้ว และถ้ามี repository ที่อยู่ภายนอก ก็ต้องโอนมายังระบบของ committee ตามขั้นตอน onboarding ที่กำหนดไว้ด้วย
แน่นอนครับ ต่อไปนี้คือคำแปลของ ภาพตาราง Proposal Stages (ที่คุณส่งมาก่อนหน้านี้) ใน สไตล์ภาษาพูด ไม่เป็นทางการ แบบเดียวกับที่คุณต้องการ:
สรุปขั้นตอนของ Proposal ใน TC39
| ขั้น | สถานะ | ต้องมีอะไรถึงจะไปขั้นนี้ได้ | ขั้นนี้ทำไปเพื่ออะไร |
|---|---|---|---|
| 0 | ยังไม่เข้าระบบ เป็นไอเดียลอย ๆ | ไม่ต้องมีอะไรเลย ใครจะเสนออะไรก็ได้ ขอแค่มีไอเดีย | ใช้เปิดประเด็นหรือชวนคุยก่อนว่าอยากเพิ่มอะไร มีปัญหาอะไร แล้วแนวทางแก้จะหน้าตาประมาณไหน เคยมีใครทำอะไรคล้ายกันมาก่อนมั้ย |
| 1 | เริ่มเข้าสู่กระบวนการ | ต้องมีคนใน TC39 รับเป็น champion มีเอกสารอธิบายปัญหา+แนวทางคร่าว ๆ และต้องมี repo ที่คนอื่นดูได้ | เอาไว้คิดแนวทางแก้แบบจริงจังขึ้น คุยเรื่อง algorithm, semantics, API ให้รอบด้านมากขึ้น |
| 2 | committee เลือกแนวทางหลักแล้ว | ต้องมี spec text คร่าว ๆ, ตัวอย่างการใช้, โค้ดที่อธิบายไอเดียชัดขึ้น | ขั้นนี้จะเริ่มเก็บรายละเอียด เช่น ถ้าเจอ input แปลก ๆ จะจัดการยังไง ตั้งชื่อฟังก์ชันยังไง รวมถึงทำ polyfill หรือ prototype ให้พอทดสอบได้ |
| 2.7 | ทุกอย่างเขียนครบแล้ว กำลังตรวจเช็คก่อนจะเข้าสู่ขั้นสุดท้าย | ต้องมี spec text ที่ละเอียดครบ, มีคน review และ editor ตรวจผ่าน | ใช้ตรวจสอบว่าเขียน spec ดีพอไหม มีอะไรตกหล่นหรือเปล่า ทดสอบจริงได้ไหม |
| 3 | พร้อมให้คนเอาไปลอง implement แล้ว | ต้องมี implement จริงอย่างน้อยหนึ่งเจ้า และมี feedback จากการใช้งาน | เก็บฟีดแบ็กจากการใช้งานจริง ดูว่ามีปัญหาอะไรไหม ปรับอะไรอีกไหม |
| 4 | พร้อมเข้า spec อย่างเป็นทางการ | ต้องมี implement อย่างน้อย 2 เจ้า, ผ่าน test262, มีคนใช้จริงแล้ว และส่ง PR เข้าสู่ ecma262 | เอาไว้รวมเข้า spec จริงเลย เพื่อเตรียมใส่ใน ECMAScript version ประจำปี |
เริ่มส่งข้อเสนอเข้ากระบวนการยังไง?
ไอเดียที่อยากเสนอให้ ECMAScript พัฒนาไปทางไหน รับหมดเลย จะเขียนมาสั้น ๆ หรือคุยกันในช่อง comment ก็ได้ ถ้ายังไม่ยื่นเป็นข้อเสนออย่างเป็นทางการ (formal proposal) มันจะถือว่าอยู่ใน Stage 0 หรือที่เรียกว่า strawperson ซึ่งยังไม่มีเกณฑ์พิจารณาอะไรทั้งนั้น
ไอเดียแบบนี้จะต้องมาจาก delegate ของ TC39 หรือถ้ามาจากคนนอก ก็ต้องเป็นคนที่ ลงทะเบียนผ่าน Ecma International ไว้ก่อน
วางแผนส่ง spec อย่างเป็นทางการยังไง?
TC39 ตั้งเป้าจะส่ง spec ไปให้ Ecma General Assembly รับรองทุก ๆ เดือนกรกฎาคมของทุกปี กำหนดการโดยประมาณจะเป็นแบบนี้:
- 1 กุมภาพันธ์: ร่าง Candidate Draft เสร็จ
- กุมภาพันธ์–มีนาคม: เปิดช่วงให้ถอนไม่เอาค่าลิขสิทธิ์ได้ 60 วัน
- มีนาคม (ประชุม TC39): รวมข้อเสนอที่อยู่ใน Stage 4 เข้าสู่ spec, สรุป semantics สุดท้าย, และแตก version ใหม่ออกจาก main หลังจากนี้จะรับแค่การแก้แบบ editor (เช่น พิมพ์ผิด หรือจัดหน้า)
- เมษายน–มิถุนายน: ให้ ExeCom กับ GA ของ Ecma ตรวจร่าง
- กรกฎาคม: ประกาศรับรองมาตรฐานใหม่
ข้อเสนอที่อยู่ระหว่างดำเนินการ
TC39 จะเก็บรายการข้อเสนอที่กำลังดำเนินการอยู่ พร้อมกับบอกว่าแต่ละอันอยู่ใน stage ไหนแล้วไว้ใน GitHub ของ committee
spec text คืออะไร?
ตั้งแต่ Stage 2 ขึ้นไป เนื้อหาใหม่ที่เสนอเข้ามาต้องเขียนเป็น spec text แบบเดียวกับ ECMAScript ฉบับปัจจุบัน โดยต้องใช้ภาษาและรูปแบบเดียวกันเป๊ะ ทั้ง semantics, API, และ syntax ซึ่งแต่ละ stage ก็จะคาดหวังระดับคุณภาพของ spec ที่ต่างกัน
ใครเป็น reviewer ได้บ้าง?
ใครก็เป็น reviewer ได้ และสามารถส่ง feedback ให้กับข้อเสนอที่อยู่ระหว่างดำเนินการได้
แต่พอถึง Stage 2 committee จะต้องแต่งตั้ง reviewer อย่างเป็นทางการ ซึ่ง reviewer เหล่านี้จะต้อง เซ็นรับรอง ข้อเสนอก่อนจะไป Stage 2.7 โดย reviewer ไม่ควรเป็นคนเขียน spec ของ feature นั้น และควรมีความรู้ในเรื่องที่เกี่ยวข้อง ที่สำคัญคือ reviewer ต้องถูกแต่งตั้งโดย committee เท่านั้น ไม่ใช่ champion เลือกเอง
เมื่อแต่งตั้ง reviewer แล้ว ควรกำหนดวันประชุมเป้าหมายสำหรับ Stage 2.7 และ reviewer ควรส่ง feedback เบื้องต้นให้กับ champion อย่างน้อย 2 สัปดาห์ก่อนวันประชุม เพื่อจะได้มีเวลาคุยและปรับแก้ ถ้ายังไม่พร้อม champion ก็สามารถขอเลื่อนวันประชุมนั้นได้
เรียกร้องให้ implement และรับ feedback
เมื่อข้อเสนอเข้าสู่ Stage 3 หมายความว่า งานออกแบบ (design) จบแล้ว สิ่งที่ต้องใช้ต่อจากนี้คือ ประสบการณ์จากการ implement จริง, การใช้งานในโลกจริง, และ feedback จากคนนอก
ทำยังไงให้ข้อเสนอผ่านฉันทามติ (Consensus)?
เวลาคุยข้อเสนอในที่ประชุม TC39 จะสามารถคุยได้ทุกเรื่อง และ feedback ที่มีผลต่อการเลื่อน stage ควรพูดไว้ตั้งแต่เนิ่น ๆ หรือจะคุยนอกรอบแบบ async ก็ได้ เพื่อให้ champion เอาไปปรับแก้ได้ทัน
บางครั้ง delegate อาจเสนอสิ่งที่เรียกว่า constraint คือเงื่อนไขที่อยากให้ข้อเสนอมี พร้อมเหตุผลว่าทำไมถึงสำคัญ ซึ่งควรพูดคุยกันตั้งแต่ต้น (ใน issue, call, หรือ plenary ก็ได้) และทำงานร่วมกับ champion เพื่อลองใส่ constraint นั้นลงไปในข้อเสนอ และพิจารณาผลกระทบต่าง ๆ
แน่นอน บางที constraint หลายอันก็ขัดกันเอง committee อาจต้องเลือกทางที่ “หาจุดตรงกลาง” โดยยอมทิ้งบาง constraint เพื่อความสมดุล
เมื่อข้อเสนอเข้า Stage 3 แล้ว หมายความว่า "design เสร็จแล้ว" — ทุกประเด็นที่เปิดไว้เคลียร์หมด รวมถึงเรื่องการ implement และความเข้ากันได้กับ ecosystem ดังนั้นคนใน TC39 ที่แคร์ข้อเสนอไหน ก็ควรตรวจให้ดี ก่อน จะยอมให้ Stage 3 ผ่าน
ถ้าข้อเสนอนั้นผ่านเกณฑ์ของ Stage 4 แล้ว ไม่ควรมีใครกั้นไม่ให้เลื่อนต่อได้ เว้นแต่เจอปัญหาจริงจากการ implement หรือข้อมูลใหม่ที่ committee ยังไม่เคยเห็นมาก่อน จุดมุ่งหมายของ Stage 3 คือเปิดไฟเขียวให้ implementer ลงมือได้จริง และช่วยยืนยันว่า “เราพร้อมแล้ว”
ถ้า committee ตกลงกันไม่ได้
บางครั้ง TC39 อาจคุยกันแล้ว ยังหาฉันทามติไม่ได้ ในเรื่องของ feature บางอย่าง ถ้าเกิดเหตุการณ์แบบนี้ขึ้น committee จะต้อง บันทึกเหตุผลให้ชัดเจน ว่าทำไมข้อเสนอนั้นถึงไม่ได้ไปต่อ อย่างน้อยควรจดไว้ทั้งใน meeting notes และ issue ใน repo ของข้อเสนอนั้น เพื่อให้คนอื่นเข้าใจบริบทของปัญหานี้ รวมถึงข้อเสนออื่นที่อาจคล้ายกันในอนาคต
โดยทั่วไป สถานการณ์แบบนี้มักจะเกิดขึ้นใน 2 รูปแบบหลัก ๆ:
- มีการละเมิด constraint ที่เคยตกลงกันไว้
- หรือแบบที่เรียกกันเล่น ๆ ว่า “block”
กรณีที่ 1: ละเมิด constraint
บางครั้ง delegate อาจเห็นว่าข้อเสนอไปละเมิด constraint ที่สำคัญ และร้ายแรงพอที่จะ ไม่สามารถให้ผ่าน stage ได้ ซึ่งในกรณีนี้ ฝ่ายที่ไม่เห็นด้วยกับ champion ควรทำงานร่วมกันเพื่อหาทางออก
กรณีที่ 2: block
ไม่ใช่ทุกปัญหาจะสามารถแก้ได้ง่าย ๆ บางปัญหานั้น ลึกและใหญ่พอสมควร อาจต้องแก้โครงสร้างของ proposal ใหม่ทั้งหมด หรือในบางกรณี อาจจะยังไม่มีเหตุผลพอที่จะดำเนินต่อเลยก็ได้
ถ้าเกิดเหตุการณ์แบบนี้ คนในวงมักจะเรียกกันว่า “block” ซึ่งหมายถึง proposal นั้นจะต้องใช้เวลาและความพยายามอีกมาก อาจต้องรื้อคิดใหม่หมด หรืออาจจะยังไม่เหมาะจะเดินหน้าต่อในตอนนี้
ทางออกที่ดีกว่า: ตั้ง constraint ที่แก้ไขได้
ถ้าเป็นไปได้ ควรเสนอ constraint ที่นำไปปฏิบัติได้จริง (actionable constraint) เพราะ TC39 ไม่มีแนวคิดว่า proposal ไหนจะ "ถูกปฏิเสธแบบถาวร" อยู่แล้ว ถ้าแก้ไขแล้วดีขึ้น champion ก็สามารถกลับมาเสนอใหม่เมื่อไรก็ได้
การเลื่อนขั้นแบบมีเงื่อนไข (Conditional advancement)
บางครั้ง delegate อาจขอเวลาเพิ่มในการพิจารณาข้อเสนอ ถ้าระหว่างคุยแล้วมีหัวข้อใหม่ที่ยังไม่เคยคิดมาก่อน ในกรณีแบบนี้ delegate ควรบอก champion ว่าต้องทำอะไรถึงจะช่วยให้วิเคราะห์ได้ง่ายขึ้น เช่น นัดคุยนอกรอบแบบตัวต่อตัว หรือให้ช่วย walkthrough เนื้อหาให้ฟัง
โดยทั่วไป การทำแบบนี้ควรเกิดขึ้นในช่วง plenary หรือล่วงหน้าก่อนประชุมครั้งต่อไป และในกรณีที่ proposal ถูกเพิ่มในวาระประชุมหลัง deadline สำหรับการขอเลื่อน stage ก็สามารถขอเวลาพิจารณาเพิ่มเติมได้เช่นกัน
ถ้าเลื่อนไปแบบมีเงื่อนไข ต้องทำยังไง?
committee อาจตัดสินใจว่า ให้ proposal เลื่อนไปได้แบบมีเงื่อนไข เช่น ให้แก้ spec จุดเล็ก ๆ ให้ชัดเจน โดยให้กลุ่มคนที่เกี่ยวข้องซึ่งเข้าใจปัญหานั้นอยู่แล้วไปช่วยกันคุยนอกรอบ
การเลื่อนแบบมีเงื่อนไขจะมี เวลาเป็นข้อจำกัด คนที่ยกประเด็นขึ้นมาควรใช้ช่วงเวลานี้คุยกับ champion และผู้เขียน proposal ให้เคลียร์ ถ้ามีการเลื่อนแบบนี้ จะต้องมี issue เปิดไว้ใน repo ของ proposal ด้วย
ถ้าปัญหานั้น แก้ได้ proposal จะเข้าสู่ stage ถัดไป โดยอัตโนมัติ โดยไม่ต้องคุยในที่ประชุมอีก แต่ถ้า แก้ไม่ได้ proposal ก็จะยังไม่เลื่อนไปไหน
ถอน proposal, ย้อนกลับไป stage เดิม หรือรับเข้าระบบแบบเต็มตัว
ระหว่างที่ข้อเสนอ (proposal) กำลังอยู่ในกระบวนการ ไม่ว่าจะอยู่ stage ไหน champion ก็สามารถขอ ย้อนกลับไปยัง stage ก่อนหน้า หรือ ถอนข้อเสนอออกจากกระบวนการ ได้ตลอด แต่จะต้องผ่านฉันทามติของคณะกรรมการก่อนเสมอ และถ้าจะถอนหรือย้อน ต้องมี เหตุผลชัด ๆ ด้วย เช่น เจอปัญหาใหญ่ที่มองข้ามไปตอนแรก หรือเพิ่งมารู้ทีหลัง
ถ้าเกิดว่า champion เดิมไม่ว่าง หรือไม่สนใจจะสานต่อ proposal นี้แล้ว ก็สามารถให้ delegate คนอื่นในคณะกรรมการอาสาเข้ามารับช่วงต่อได้เลย แล้วจากนั้น champion คนใหม่ จะเป็นคนดูแลทั้งหมด ไม่ว่าจะเลื่อน stage, ย้อน stage หรือถอนข้อเสนอ
แชมป์เปี้ยนทำอะไรบ้าง?
คนที่เป็น champion (หรือบางทีอาจเป็นกลุ่ม champion ที่ช่วยกันหลายคน) คือคนที่ เขียนและดูแลข้อเสนอ ตั้งแต่เริ่มต้นจนถึงจุดที่ข้อเสนอนั้นเข้าถึง Stage 4 พอถึงจุดนั้น หน้าที่จะถูกส่งต่อให้กับกลุ่ม editor ที่ดูแล spec โดยรวมแทน
Champion จะมีสิทธิ์เป็น admin ของ repo ข้อเสนอ สามารถแก้ไขเนื้อหาอะไรก็ได้ตามสะดวก และทุก ๆ ระยะเวลาหนึ่ง champion จะต้องเอาข้อเสนอไปให้ที่ประชุม TC39 ช่วยกันตัดสินใจว่าจะเลื่อนไป stage ถัดไปไหม
เวลาขอเลื่อน stage ต้องทำอะไรบ้าง?
เวลาจะขอเลื่อน stage champion ต้องเปิด proposal ทั้งชุดให้คณะกรรมการเข้ามาดูได้แบบชัด ๆ ต้องอธิบายว่าในนั้นมีอะไร เปลี่ยนตรงไหนบ้าง แนบเอกสารประกอบให้เข้าใจง่าย และถ้ามีจุดไหนที่เปลี่ยนเยอะก็ควรพูดให้ชัด ๆ ว่าคืออะไร
ถึงจะไม่ใช่กฎ แต่โดยทั่วไป ถ้า champion คอยอัปเดตสถานะของ proposal ให้คณะกรรมการรู้เรื่อย ๆ ว่ามีอะไรเปลี่ยนบ้าง ก็จะช่วยให้คนตามเข้าใจง่ายขึ้น และไม่ต้องงงทีหลัง (ตรงนี้ไม่ต้องขอ consensus แค่แจ้งไว้เฉย ๆ ก็พอ) แต่ถ้ามีการเปลี่ยน design ใหญ่ ๆ จริง ๆ คณะกรรมการอาจต้องกลับมาคิดใหม่ว่า proposal นั้นอยู่ถูก stage แล้วหรือยัง
เขียน test ยังไง?
ในช่วง Stage 2.7 ข้อเสนอควรจะมีการเขียน Test262 และส่งเข้าระบบผ่าน pull request ถ้าผ่านการตรวจเรียบร้อยแล้วก็ให้ merge เข้าได้เลย เพื่อให้พวก implementer เอาไปใช้ทดสอบ และส่ง feedback กลับมาได้ง่ายขึ้น
ข้ามขั้นตอนได้ไหม?
ได้ครับ ถ้าการเปลี่ยนแปลงนั้นดูเล็กหรือเฉพาะทางมาก ๆ คณะกรรมการสามารถ เลือกข้ามบางขั้นตอน ไปได้ ขึ้นอยู่กับสถานการณ์
แล้ว editor มีหน้าที่อะไร?
ข้อเสนอส่วนใหญ่จะมีคนเขียน spec text เป็น champion หรือสมาชิกคนอื่น ๆ ที่ไม่ใช่ editor ก็ได้ (แม้บางครั้ง editor เองอาจเป็น champion ของฟีเจอร์บางอย่างด้วยก็มี)
หน้าที่หลักของ editor คือดูแลภาพรวมของ ECMAScript spec ให้ โครงสร้างชัดเจน อ่านรู้เรื่อง ไม่ขัดกันเอง และคอยช่วยชี้แนะแนวทางให้กับคนที่เขียน spec text ว่าควรเขียนยังไงให้ได้คุณภาพตามมาตรฐาน
พอข้อเสนอไหนผ่าน Stage 4 แล้ว editor ก็จะเป็นคนรวมมันเข้าไปใน revision ใหม่ของ spec ให้เรียบร้อย