การมีส่วนร่วมใน OpenXLA

ทุกคนสามารถมีส่วนร่วมกับ OpenXLA ได้ และเราให้ความสำคัญกับการมีส่วนร่วมของทุกคน โดยคุณมีส่วนร่วมได้หลายวิธีดังนี้

• การตอบคำถามในฟอรัมการสนทนาของ OpenXLA (openxla-discuss)

• การปรับปรุงหรือขยายเอกสารประกอบของ OpenXLA

• การมีส่วนร่วมในฐานของโค้ดของ OpenXLA

• การมีส่วนร่วมด้วยวิธีใดๆ ข้างต้นเพื่อสร้างระบบนิเวศที่กว้างขึ้นของไลบรารีที่สร้างบน OpenXLA

โครงการ OpenXLA เป็นไปตาม หลักเกณฑ์ของชุมชนโอเพนซอร์สของ Google

ก่อนเริ่มต้น

ลงนามในข้อตกลงใบอนุญาตผู้สนับสนุน

การมีส่วนร่วมในโครงการนี้ต้องมาพร้อมกับข้อตกลงการอนุญาตสำหรับผู้ร่วมให้ข้อมูล (CLA) คุณ (หรือนายจ้าง) เป็นผู้ครองลิขสิทธิ์ผลงานของคุณ ซึ่งถือเป็นการอนุญาตให้เราใช้และแจกจ่ายผลงานของคุณในฐานะส่วนหนึ่งของโครงการ

หากคุณหรือนายจ้างปัจจุบันของคุณได้ลงนามใน CLA ของ Google ไปแล้ว (แม้ว่าจะเป็นโปรเจ็กต์อื่นก็ตาม) คุณอาจไม่จำเป็นต้องลงนามใน CLA อีก

ไปที่ <https://cla.developers.google.com/> เพื่อดูข้อตกลงปัจจุบันหรือลงนามในข้อตกลงใหม่

ทบทวนหลักจรรยาบรรณ

โปรเจ็กต์นี้เป็นไปตามหลักจรรยาบรรณของ Tensorflow

กระบวนการสนับสนุน

คู่มือนักพัฒนา

ดูคำแนะนำเกี่ยวกับวิธีตั้งค่าสภาพแวดล้อมในการพัฒนาซอฟต์แวร์สำหรับ OpenXLA รวมถึงการรับโค้ด การสร้าง การเรียกใช้การทดสอบ และการส่งการเปลี่ยนแปลงได้ที่คู่มือนักพัฒนาซอฟต์แวร์

มาตรฐานโค้ด

• รูปแบบการเขียนโค้ด: เราปฏิบัติตามคู่มือสไตล์โค้ดของ Google โปรดดูคู่มือ C/C++ และ Python โดยเฉพาะ โค้ดทั้งหมดที่ส่งต้องเป็นไปตามคู่มือการจัดรูปแบบเหล่านี้อย่างเคร่งครัด

• กะทัดรัดการเปลี่ยนแปลง: เราปฏิบัติตามแนวทางปฏิบัติด้านวิศวกรรมของ Google โดยเฉพาะอย่างยิ่ง โปรดดูคำแนะนำในการเขียนการเปลี่ยนแปลงแบบกะทัดรัด วิธีนี้จะเพิ่มความเร็วในการรวมโค้ดได้เป็นอย่างมากเนื่องจากปรับปรุงความสามารถในการตรวจสอบ และลดโอกาสเกิดผลข้างเคียงโดยไม่ตั้งใจจากการเปลี่ยนแปลง ถึงแม้ว่าคุณจะมีการเปลี่ยนแปลงครั้งใหญ่ แต่ก็มีกลยุทธ์มากมายในการแบ่งย่อยผลิตภัณฑ์ออกเป็นส่วนๆ เพิ่มเติม

• การครอบคลุมในการทดสอบ: การเปลี่ยนแปลงทั้งหมดควรมีการทดสอบ 1 หน่วยที่เหมาะสม การทดสอบ 1 หน่วยไม่ควรขึ้นอยู่กับช่วงเวลาของฮาร์ดแวร์ (CPU, GPU ฯลฯ) เฉพาะ และควรใช้รูปแบบจำลองและของปลอมอย่างเสรีเพื่อทำการทดสอบโดยเจาะจงและเจาะจง การเปลี่ยนแปลงที่ตั้งใจจะขยายโค้ดที่มีอยู่ซึ่งทดสอบยากในปัจจุบันควรปรับปรุงความสามารถในการทดสอบให้เหมาะสม

  การเปลี่ยนแปลงทั้งหมดควรรวมผลการเปรียบเทียบที่เหมาะสมไว้ในชื่อการเปลี่ยนแปลงเพื่อให้แน่ใจถึงประโยชน์ที่จะได้รับอย่างชัดเจน

• หากไม่แน่ใจเกี่ยวกับรูปแบบภายในโค้ด ควรตรวจสอบโค้ดที่มีอยู่แล้วและพยายามทำตามรูปแบบที่มีอยู่แล้วใน OpenXLA

ตรวจสอบกระบวนการ

ข้อมูลทั้งหมดที่ส่งมา รวมถึงการส่งจากสมาชิกโปรเจ็กต์ จะต้องได้รับการตรวจสอบ เราใช้คำขอพุลของ GitHub สำหรับวัตถุประสงค์นี้ โปรดดูข้อมูลเพิ่มเติมที่ความช่วยเหลือของ GitHub เกี่ยวกับการใช้คำขอพุล

• โค้ดต้องเป็นไปตามมาตรฐานทั้งหมดที่ระบุไว้ด้านบนก่อนที่จะมีการตรวจสอบ ข้อกำหนดเหล่านี้ไม่ได้เกี่ยวข้อง (ไม่บังคับ) และผู้ส่งต้องตรวจสอบให้แน่ใจว่าโค้ดของตนเป็นไปตามหลักเกณฑ์ก่อนที่จะขอรับการตรวจสอบเพื่อให้ยอมรับการเปลี่ยนแปลงได้ทันท่วงที

• การทดสอบทั้งหมดต้องผ่าน หากคุณพบว่าการทดสอบไม่ทำงานและปัญหาไม่เกี่ยวข้องกับสภาพแวดล้อมของบิลด์หรือการเปลี่ยนแปลงของคุณ โปรดติดต่อผู้ดูแล

• พยายามหลีกเลี่ยงการเพิ่มขอบเขตในระหว่างกระบวนการตรวจสอบ นี่คือความรับผิดชอบของทั้งผู้ส่งและผู้ตรวจสอบ หากการเปลี่ยนแปลงเริ่มมีมากเกินไป ให้แบ่งการเปลี่ยนแปลงออกเป็นหลายๆ ส่วน

• ก่อนที่จะผสานรวมการเปลี่ยนแปลง การเปลี่ยนแปลงจะผ่านการทดสอบภายในที่ใช้โค้ดภายในสำหรับ Google และผู้ให้บริการฮาร์ดแวร์รายอื่นๆ ซึ่งอาจเพิ่มขั้นตอนเพิ่มเติมลงในกระบวนการตรวจสอบได้หากมีความล้มเหลวในการทดสอบภายในที่ CI สาธารณะของเราตรวจไม่พบ Googler ที่ตรวจสอบการเปลี่ยนแปลงจะแจ้ง ความล้มเหลวในการทดสอบภายในและอธิบายถึงสิ่งที่ต้องแก้ไข

คำถามที่พบบ่อย

"การเปลี่ยนแปลงโครงสร้างพื้นฐานนี้ไม่เกี่ยวข้องกับการประชาสัมพันธ์ของฉัน ทำไมฉันต้องทำเช่นนี้"

ทีม XLA ไม่มีทีมโครงสร้างพื้นฐานเฉพาะ ทุกคนจะขึ้นอยู่กับเราในการสร้างไลบรารีตัวช่วยและหลีกเลี่ยงหนี้ทางเทคนิค เราถือว่าการเปลี่ยนแปลงนี้เป็นเรื่องปกติ ของการเปลี่ยนแปลง XLA และทุกคนคาดหวังว่าจะมีส่วนร่วม โดยทั่วไป เราจะสร้างโครงสร้างพื้นฐานตามที่จำเป็นเมื่อเขียนโค้ด

ผู้ตรวจสอบ XLA อาจขอให้คุณสร้างโครงสร้างพื้นฐานบางอย่าง (หรือทำการเปลี่ยนแปลงครั้งใหญ่ใน PR) ควบคู่ไปกับการประชาสัมพันธ์ที่คุณเขียน คำขอนี้อาจดูไม่จำเป็นหรือไม่เกี่ยวข้องกับการเปลี่ยนแปลงที่คุณพยายามจะทำ ซึ่งอาจเป็นเพราะความไม่ตรงกันระหว่างความคาดหวังของคุณเกี่ยวกับโครงสร้างพื้นฐานที่ต้องสร้างกับความคาดหวังของผู้ตรวจสอบสำหรับสิ่งเดียวกันนี้

ความคาดหวังที่ไม่ตรงกันก็ไม่เป็นไร ซึ่งเป็นไปตามที่คาดไว้เมื่อคุณเพิ่งเริ่มทำโปรเจ็กต์ (และบางทีเราก็ไม่ชอบหน้าตาแบบนี้ด้วยซ้ำ) เป็นไปได้มากว่าโครงการต่างๆ ที่คุณเคยทำ จะมีความคาดหวังที่แตกต่างกัน ซึ่งก็ไม่เป็นไร และเป็นไปตามที่คาดไว้! ไม่ได้หมายความว่าโครงการใดโครงการหนึ่งมีแนวทางที่ผิด เพียงแต่แตกต่างกัน เราขอเชิญให้คุณรับคำขอ Infra ร่วมกับความคิดเห็นด้านการตรวจสอบอื่นๆ ทั้งหมด โอกาสที่จะได้เรียนรู้ถึงสิ่งที่เราคาดหวังในโปรเจ็กต์นี้

"ฉันจะจัดการกับความคิดเห็นของคุณในการประชาสัมพันธ์ในอนาคตได้ไหม"

คำถามที่พบบ่อยเกี่ยวกับคำขอโครงสร้างพื้นฐาน (หรือคำขอขนาดใหญ่อื่นๆ) ใน PR คือการเปลี่ยนแปลงต้องทำใน PR เดิมหรือไม่ หรือสามารถทำเป็นการติดตามผลในการประชาสัมพันธ์ในอนาคตได้หรือไม่

โดยทั่วไป XLA ไม่อนุญาตให้ผู้เขียนด้านการประชาสัมพันธ์จัดการความคิดเห็นเกี่ยวกับรีวิวด้วยการประชาสัมพันธ์ติดตามผล เมื่อผู้รีวิวตัดสินใจว่าเรื่องใดที่จำเป็นต้องได้รับการแก้ไขในการประชาสัมพันธ์โดยทั่วไป เราคาดหวังให้ผู้เขียนพูดถึงเรื่องนี้ในการประชาสัมพันธ์นั้น แม้ว่าสิ่งที่ร้องขอจะเป็นการเปลี่ยนแปลงครั้งใหญ่ก็ตาม มาตรฐานนี้มีผลกับทั้งภายนอกและภายใน ภายใน Google ด้วย

มีเหตุผล 2-3 ประการที่ XLA ใช้แนวทางนี้

• ความไว้วางใจ: การได้รับความไว้วางใจจากผู้ตรวจสอบเป็นองค์ประกอบสำคัญอย่างหนึ่ง ในโปรเจ็กต์โอเพนซอร์ส ผู้ร่วมให้ข้อมูลจะปรากฏหรือหายไปได้ตามต้องการ หลังจากที่เราอนุมัติการประชาสัมพันธ์ ผู้ตรวจสอบจะไม่มีวิธีตรวจสอบว่าการติดตามผลตามที่สัญญาไว้มีขึ้นจริง

• ผลกระทบต่อนักพัฒนาซอฟต์แวร์รายอื่นๆ: หากคุณส่งการประชาสัมพันธ์เพื่อกล่าวถึงส่วนใดของ XLA ก็มีโอกาสสูงที่ผู้ใช้คนอื่นๆ กำลังดูส่วนเดียวกัน หากเรายอมรับหนี้ทางเทคนิคในการประชาสัมพันธ์ของคุณ ทุกคนที่กำลังดูไฟล์นี้จะได้รับผลกระทบจากหนี้สินนี้จนกว่าจะมีการส่งการติดตามผล

• แบนด์วิดท์ของผู้ตรวจสอบ: การเลื่อนเวลาการเปลี่ยนแปลงเพื่อติดตามผลจะทำให้เกิดค่าใช้จ่ายหลายรายการสำหรับผู้ตรวจสอบที่ทำงานมากเกินไปอยู่แล้ว ผู้ตรวจสอบอาจลืมว่าการประชาสัมพันธ์ครั้งแรกเกี่ยวกับอะไรระหว่างที่รอการติดตามผล ซึ่งทำให้การตรวจสอบครั้งต่อไปทำได้ยากขึ้น นอกจากนี้ ผู้ตรวจสอบจะต้องติดตาม การติดตามผลที่คาดไว้เพื่อให้แน่ใจว่าเกิดขึ้นจริง หากสามารถเปลี่ยนแปลงแก้ไขได้ โดยเป็นการเปลี่ยนแปลงโดยไม่ต้องกำหนดทิศทางประชาสัมพันธ์เดิมเพื่อให้ผู้ตรวจสอบคนอื่นๆ ตรวจสอบได้ แบนด์วิดท์ก็จะเป็นปัญหาน้อยลง จากประสบการณ์ นี้ไม่ค่อยเกิดขึ้น