google summer of code
1.0.0
ทรัพยากรสำหรับโปรแกรม Google Summer of Code
สวัสดี! และยินดีต้อนรับสู่พื้นที่เก็บข้อมูลทรัพยากร Google Summer of Code (GSOC) ของ Stdlib
GSOC เป็นโปรแกรมระดับโลกที่ให้โอกาสผู้สนับสนุนใหม่ (ซึ่งมีอายุ 18 ปีขึ้นไป) โอกาสที่จะได้รับค่าตอบแทนสำหรับการบริจาคโครงการโอเพนซอร์สในช่วงระยะเวลาสามเดือน Google จ่ายเงินโดย Google ให้ทำงานภายใต้คำแนะนำของผู้ให้คำปรึกษาจากชุมชนโอเพ่นซอร์ส GSOC เป็นโอกาสที่ดีในการเรียนรู้พัฒนาทักษะใหม่สร้างการเชื่อมต่อรับประสบการณ์การทำงานกับทีมที่มีขนาดใหญ่และกระจายบ่อยและได้รับการชดเชยทางการเงินสำหรับความพยายามของคุณ
ในที่เก็บนี้คุณจะพบข้อมูลเกี่ยวกับวิธีการสมัครสำหรับ GSOC และรายการความคิดที่เป็นไปได้ซึ่งสามารถใช้เป็นพื้นฐานสำหรับโครงการ GSOC
ผู้สนับสนุน GSOC คาดว่าจะทำงานได้ทั้ง 350 ชั่วโมง (เทียบเท่าเต็มเวลา) 175 ชั่วโมง (เทียบเท่านอกเวลา) หรือ 90 ชั่วโมง (เทียบเท่าเวลาสั้น ๆ ) ตลอดระยะเวลาของโปรแกรม กำหนดการเริ่มต้นทำงานในช่วง 3 เดือน (12 สัปดาห์) และอาจกระจายออกไปในระยะเวลานานขึ้น
วันที่เริ่มต้นโปรแกรม ไม่สามารถต่อรองได้ ผู้สนับสนุน GSOC ทั้งหมด จะต้อง เริ่มโปรแกรมในเวลาเดียวกัน
ในการใช้กับ GSOC กับ stdlib คุณต้อง:
โปรดจำไว้ว่าแอปพลิเคชันทั้งหมด จะต้อง ผ่านระบบแอปพลิเคชันของ Google และคุณ ต้องส่งใบสมัครของคุณบนเว็บไซต์ของ Google หากคุณไม่ส่งใบสมัครของคุณบนเว็บไซต์ GSOC เรา ไม่สามารถ ยอมรับใบสมัครของคุณได้
ความตั้งใจของ GSOC คือการจัดหาวิธีสำหรับผู้มีส่วนร่วมใหม่ในการเข้าร่วมและมีส่วนร่วมในโลกของโอเพ่นซอร์ส ผู้ให้ข้อมูลส่วนใหญ่มีแนวโน้มที่จะได้รับการคัดเลือกและประสบความสำเร็จในที่สุดก็คือผู้ที่มีส่วนร่วมในชุมชนและหวังว่าจะยังคงมีส่วนร่วมต่อไปนอกเหนือจากระยะเวลาของโปรแกรม GSOC โดยทั่วไปสำหรับโครงการส่วนใหญ่ การเป็นสมาชิกชุมชนที่ดีมีความสำคัญมากกว่าการเป็นนักเขียนที่ดี
สื่อสาร. การสื่อสารอาจเป็นส่วนที่สำคัญที่สุดของกระบวนการสมัคร พูดคุยกับที่ปรึกษาและนักพัฒนา stdlib อื่น ๆ ฟัง เมื่อพวกเขาให้คำแนะนำและแสดงให้เห็นว่าคุณเข้าใจคำแนะนำของพวกเขาโดยรวมความคิดเห็นของพวกเขาไว้ในสิ่งที่คุณเสนอ ความล้มเหลวในการรวมข้อเสนอแนะช่วยลดโอกาสของคุณในการประสบความสำเร็จ อย่างมีนัยสำคัญ
อ่านคำแนะนำ อ่านคำแนะนำทั้งหมด (และอ่านซ้ำ) เสมอเมื่อส่งข้อเสนอ อย่าเพียงแค่ส่งประวัติย่อเอกสารทางวิทยาศาสตร์การนำเสนอหรือไฟล์อื่น ๆ ที่ไม่มีข้อมูลใด ๆ เกี่ยวกับโครงการที่คุณต้องการติดตาม ความล้มเหลวในการปฏิบัติตามคำแนะนำได้รับการรับประกันว่าจะนำไปสู่การปฏิเสธข้อเสนอ
เป็นมืออาชีพ แสดงความเคารพและแสดงให้เห็นว่าคุณจะคำนึงถึงความสัมพันธ์การให้คำปรึกษาอย่างจริงจัง นั่นหมายถึงการฟังอย่างแข็งขันเมื่อคุณได้รับคำติชมและให้ความสำคัญกับเวลาของสมาชิกแต่ละคนในชุมชน Stdlib เสมอ การสื่อสารที่ไม่ดีและความล้มเหลวในการอ่านและปฏิบัติตามคำแนะนำสื่อถึงการขาดความเคารพและขาดการพิจารณาถึงเวลาที่ปรึกษาและไม่มีที่ปรึกษาต้องการทำงานกับผู้สนับสนุนที่ไม่แสดงความเป็นมืออาชีพที่จำเป็นเพื่อให้แน่ใจว่าทั้งความสำเร็จของโครงการและ การเติบโตส่วนบุคคลของพวกเขาในฐานะสมาชิกชุมชน Stdlib
หากคุณมีคำถามก่อนตรวจสอบว่าคำถามได้รับคำตอบแล้วในคำถามที่พบบ่อยของ GSOC หรือไม่ หากคุณยังมีคำถามหลังจากปรึกษาคำถามที่พบบ่อยของ GSOC คุณสามารถเข้าถึงช่องทางองค์ประกอบ stdlib
คุณสามารถใช้องค์ประกอบเพื่อขอความคิดเห็นเกี่ยวกับแนวคิดโครงการเริ่มต้นและเพื่อรับความช่วยเหลือในขณะที่คุณเริ่มทำงานกับ stdlib codebase โปรดทราบว่ายิ่งคำถามของคุณเฉพาะเจาะจงและชัดเจนขึ้นในฟอรัม Stdlib ยิ่งมีโอกาสมากขึ้นที่คุณจะได้รับคำตอบที่ดี คำถามปลายเปิดหรือคลุมเครือไม่น่าจะได้รับการตอบกลับที่เป็นประโยชน์
ตัวอย่างเช่นคำถามที่ดีอาจเป็นอะไรบางอย่างตามแนวของ
ฉันสนใจ Project X และฉันได้ทำการวิจัยเล็กน้อยและพบว่าปัญหา Y และ Z ดูเหมือนจะเกี่ยวข้อง จากการค้นพบของฉัน A, B และ C ถูกนำไปใช้แล้วดังนั้นฉันอยากรู้ว่ามันจะสมเหตุสมผลหรือไม่ที่จะเสนอโครงการที่จะบรรลุ D, E และ F
ในทางตรงกันข้ามคำถามต่อไปนี้เปิดกว้างเกินไปและคลุมเครือเกินไปที่จะเรียกร้องการตอบสนองที่มีความหมาย
ฉันสนใจ Project X โปรดช่วยฉันทำสิ่งนี้
เมื่อเข้าถึงองค์ประกอบให้แน่ใจว่าได้แนะนำตัวเองเพื่อที่เราจะได้รู้จักคุณ ข้อมูลที่มีประโยชน์บางส่วนที่จะรวม
ก่อนที่จะทำงานกับแอปพลิเคชัน GSOC ของคุณโปรดตรวจสอบรายการแนวคิดของเราเพื่อดูว่าคุณพบโครงการที่ทำให้คุณตื่นเต้นหรือไม่ รายการความคิดที่มีอยู่นั้นมีไว้เพื่อใช้เป็นแรงบันดาลใจและเพื่อระบุทิศทางใดที่อาจดีสำหรับ stdlib
หากคุณพบความคิดที่มีอยู่ที่คุณต้องการติดตามโปรดติดต่อเราในช่ององค์ประกอบของเราเพื่อพูดคุยก่อน! อย่าลืมถามเกี่ยวกับแนวคิดเหล่านี้ก่อนที่จะทำงานกับแอปพลิเคชันเพื่อรับข้อมูลล่าสุดเกี่ยวกับสิ่งที่นำไปใช้แล้วและสิ่งที่ต้องทำ
รายการความคิดถูกจัดโดยป้ายกำกับตามอนุสัญญาต่อไปนี้:
ลำดับความสำคัญ
high : แนวคิดที่ถือว่ามีความสำคัญในแผนงานของเราnormal : ความคิดที่ไม่เร่งด่วน แต่จะดีถ้ามีเร็วกว่าในภายหลังlow : ความคิดที่แปลกใหม่หรือน่าสนใจ แต่อยู่ในระดับต่ำในรายการลำดับความสำคัญของเราความยากลำบาก
1 : ความคิดที่เหมาะสำหรับคนที่มีประสบการณ์ JavaScript เพียงเล็กน้อยถึงไม่มีเลย2 : ความคิดที่เหมาะสำหรับคนที่มีความรู้ในการทำงานของ JavaScript3 : ความคิดที่น่าจะท้าทาย แต่จัดการได้4 : ความคิดที่น่าจะท้าทายและมีเป้าหมายที่ทะเยอทะยาน5 : ความคิดที่น่าจะเป็นเรื่องยากที่จะนำไปใช้กับสิ่งแปลกปลอมหลายอย่างเทคโนโลยี
javascript : แนวคิดที่เกี่ยวข้องกับการเขียนโปรแกรมใน JavaScript อย่างน้อยก็มีความจำเป็นสำหรับความคิดทั้งหมดnodejs : แนวคิดที่ต้องพัฒนาด้วย Node.js การทำงานกับ node.js มีแนวโน้มที่จะจำเป็นสำหรับส่วนใหญ่หากไม่ใช่ทั้งหมดความคิดเนื่องจาก node.js เป็นสภาพแวดล้อมเริ่มต้นสำหรับการทดสอบการเปรียบเทียบและการพัฒนาในท้องถิ่นc : ความคิดที่เกี่ยวข้องกับการเขียนโปรแกรมใน C นี่เป็นสิ่งจำเป็นสำหรับ node.js add-ons ดั้งเดิมfortran : ความคิดที่เกี่ยวข้องกับการเขียนโปรแกรมใน FORTRAN สิ่งนี้จำเป็นสำหรับการทำงานกับการผูก BLAS/lapackhtml/css : แนวคิดที่เกี่ยวข้องกับการใช้ HTML และ CSS (เช่นถ้าสร้างแอปพลิเคชันส่วนหน้า)jsx/react : แนวคิดที่เกี่ยวข้องกับการเขียนโปรแกรมด้วย React JSX (เช่นถ้าทำงานบนเว็บไซต์ stdlib)native addons : ความคิดที่เกี่ยวข้องกับการพัฒนา Node.js Add-ons ดั้งเดิมtypescript : แนวคิดที่เกี่ยวข้องกับการเขียนโปรแกรมใน TypeScriptลำดับความสำคัญความยากลำบากเทคโนโลยีและหัวข้อหัวข้อไม่มีโอกาสได้รับความคิดที่ได้รับการยอมรับ ความคิดทั้งหมดดีพอ ๆ กันและโอกาสในการได้รับการยอมรับขึ้นอยู่กับ คุณภาพของใบสมัครของคุณ เท่านั้น
ความยาวโครงการ
GSOC อนุญาตให้ใช้ความยาวโครงการสามแบบ: 90 ชั่วโมง 175 ชั่วโมงและ 350 ชั่วโมง แต่ละแนวคิดต้องระบุว่าความคิดนั้นเหมาะสมกว่าสำหรับ 90, 175 หรือ 350 ชั่วโมง
ในบางกรณีเราอาจสามารถขยายโครงการ 175 ชั่วโมงไปยังโครงการ 350 ชั่วโมงโดยขยายแนวคิดของสิ่งที่สามารถทำได้ ในทำนองเดียวกันในบางกรณีโครงการ 350 ชั่วโมงสามารถสั้นลงเป็นโครงการ 175 ชั่วโมงโดยใช้ส่วนหนึ่งของแนวคิดและออกจากส่วนที่เหลือสำหรับโครงการในอนาคต ไม่ว่าในกรณีใดหากคุณต้องการปรับความยาวโครงการโปรดติดต่อเราในช่ององค์ประกอบของเราเพื่อพูดคุยก่อน!
หากคุณต้องการส่งความคิดของคุณเองนั่นก็ยินดีต้อนรับเช่นกัน เพียงให้แน่ใจว่าได้เสนอความคิดของคุณต่อ Stdlib Mentors ก่อน! หลังจากเอื้อมมือออกไปเราจะแจ้งให้คุณทราบว่าความคิดนั้นได้ถูกนำไปใช้แล้วหรือไม่หากความคิดนั้นจะนำมาซึ่งการทำงานที่เพียงพอที่จะใช้เวลานานในช่วงเวลาของโปรแกรม GSOC หากความคิดนั้นต้องการงานมากเกินไปที่จะดำเนินการอย่างมีความหมายในระหว่าง GSOC แนวคิดอยู่ในขอบเขตของ stdlib ความคิดที่ไม่พึงประสงค์และไม่ได้อภิปรายมีโอกาสน้อยที่จะได้รับการยอมรับ
โครงการที่ดีที่สุดสำหรับคุณคือโครงการที่คุณสนใจและมีความรู้มากที่สุด ความตื่นเต้นและความถนัดเป็นส่วนผสมสำคัญสองประการของโครงการที่ประสบความสำเร็จและช่วยให้มั่นใจว่าความมุ่งมั่นและความสามารถของคุณในการมองเห็นโครงการจนถึงการเสร็จสิ้น ดังนั้นหากมีบางสิ่งที่คุณหลงใหลเป็นพิเศษและคุณเชื่อว่าสอดคล้องกับขอบเขตและเป้าหมายของ Stdlib เรายินดีที่จะได้ยินระดับเสียงของคุณ!
หลังจากพูดคุยกับเราในช่ององค์ประกอบของเราและได้รับการอนุมัติเพื่อส่งความคิดของคุณโปรดเปิดปัญหาที่อธิบายความคิดของคุณโดยใช้ เทมเพลตปัญหาความคิด
นอกเหนือจากข้อเสนอที่เป็นลายลักษณ์อักษรเรา ต้องการให้ ผู้สมัคร GSOC ทุกคนเขียนแพตช์และรวมเข้ากับที่เก็บ stdlib หลัก
เรานำแพตช์ของคุณไปที่ stdlib เพื่อพิจารณา อย่างมาก เมื่อตรวจสอบข้อเสนอของคุณ การส่งแพทช์อย่างน้อยหนึ่งครั้งเป็นโอกาสที่ดีที่สุดของคุณในการแสดงให้เห็นว่าคุณสามารถทำสิ่งที่รวมอยู่ในข้อเสนอของคุณได้
เพื่อส่งแพทช์
แยกที่เก็บ stdlib
ตั้งค่าแพลตฟอร์มของคุณเพื่อพัฒนา stdlib (เช่นติดตั้ง git, โคลนที่เก็บข้อมูลของคุณตั้งค่าเพื่อติดตามพื้นที่เก็บข้อมูล ripstream stdlib ระยะไกลติดตั้งการพึ่งพาและเริ่มต้นสภาพแวดล้อมการพัฒนาท้องถิ่นของคุณ) คู่มือการสนับสนุนของเราจะนำคุณผ่านการตั้งค่า GIT และรายละเอียดวิธีการพัฒนาที่เราต้องการ
โปรด อย่า ส่งแพตช์ผ่านตัวแก้ไขเว็บ GitHub คุณจะต้องเรียนรู้วิธีใช้ GIT และพัฒนา stdlib ในพื้นที่หากโครงการของคุณได้รับการยอมรับ สละเวลาในการใช้ Git และพัฒนา stdlib ในท้องถิ่นจะเพิ่มโอกาสในการประสบความสำเร็จและช่วยให้คุณตัดสินใจว่า stdlib นั้นเหมาะสมสำหรับคุณหรือไม่
ค้นหาบางสิ่งใน stdlib ที่ไม่ได้ผลต้องการการปรับปรุงหรือจะเป็นการเพิ่มที่มีประโยชน์ หากคุณต้องการแรงบันดาลใจโปรดแก้ไขปัญหาใด ๆ ในรายการปัญหาที่ดีสำหรับผู้มีส่วนร่วมครั้งแรก
นอกเหนือจากปัญหาแล้วให้ค้นหา FIXME หรือ TODO ใน Codebase คุณสามารถใช้ grep จากบรรทัดคำสั่งด้วย git grep "TODO"
นอกจากนี้คุณยังสามารถเล่นใน stdlib repl และค้นหาสิ่งที่ต้องการแก้ไขหรือสามารถนำไปใช้ได้
เมื่อคุณพบบางสิ่งบางอย่างหากปัญหาไม่มีอยู่แล้วให้เปิดปัญหาเกี่ยวกับตัวติดตามปัญหา stdlib ที่อธิบายถึงปัญหาและวิธีการแก้ปัญหาที่คุณเสนอ
หากโครงการของคุณจะใช้ภาษาอื่นที่ไม่ใช่ JavaScript (เช่น C หรือ Fortran) คุณควรส่งแพตช์ที่ใช้ภาษานั้นเช่นกันเพื่อแสดงให้เห็นว่าคุณมีความเชี่ยวชาญในภาษานั้น
โปรดทราบว่าแพตช์ของคุณ จะต้อง เกี่ยวข้องกับรหัสไม่ใช่เอกสาร ในขณะที่การแก้ไขเอกสารยินดีต้อนรับเสมอ แต่พวกเขาจะ ไม่ ปฏิบัติตามข้อกำหนดของแพตช์
และโปรดทราบว่าแพตช์ของคุณ ไม่ จำเป็นต้องเกี่ยวข้องกับโครงการที่คุณเสนอเพื่อตอบสนองความต้องการของแพตช์ เพื่อทำความคุ้นเคยกับรหัสที่คุณกำลังทำงานคุณอาจต้องการแก้ไขข้อผิดพลาดที่เกี่ยวข้องในรหัสเดียวกันหรือคล้ายกัน แต่นี่ ไม่ใช่ ส่วนหนึ่งของข้อกำหนดของแพตช์
เผยแพร่แพตช์ของคุณสำหรับการตรวจสอบเพียร์โดยการสร้างคำขอดึงบน GitHub คุณต้องส่งคำขอดึงของคุณผ่าน GitHub (เมื่อเทียบกับตัวอย่างเช่นการวางไฟล์ที่ได้รับการแก้ไข) เนื่องจากนี่เป็นวิธีที่ง่ายที่สุดสำหรับเราในการตรวจสอบรหัสของคุณและให้ข้อเสนอแนะและเป็นสิ่งที่เราคาดหวังจากผู้มีส่วนร่วมที่ทำงาน โครงการ GSOC
คุณต้องส่งแพตช์ที่ได้รับการตรวจสอบและรวมเข้าด้วยกันเพื่อตอบสนองความต้องการของแพตช์ได้สำเร็จ เรา ไม่ได้ พิจารณาแอปพลิเคชันโดยไม่รวมแพทช์สำเร็จ
แพตช์ที่ประสบความสำเร็จแสดงให้เห็นถึงความสามารถทางเทคนิคของคุณและความสามารถในการโต้ตอบกับชุมชน stdlib
เมื่อคุณสร้างคำขอดึงบน GitHub ผู้ตรวจสอบ stdlib จะตรวจสอบรหัสของคุณและอาจร้องขอการเปลี่ยนแปลง คุณ ควร จัดการกับการเปลี่ยนแปลงเหล่านี้
ตลอดกระบวนการพัฒนาและข้อเสนอแนะคุณควร ทำการ ทดสอบหน่วยในเครื่องเพื่อตรวจสอบพฤติกรรมที่คาดหวัง
ในระหว่างการตรวจสอบโปรดอดทนกับผู้ตรวจสอบ เนื่องจาก GSOC อาจมีคำขอดึงจำนวนมากเพื่อตรวจสอบและเราอาจตรวจสอบคำขอดึงทั้งหมดได้ช้าโดยเฉพาะอย่างยิ่งหากพวกเขาถูกส่งใกล้กับกำหนดส่งใบสมัคร คุณได้รับการสนับสนุน อย่างมาก ในการส่งคำขอดึงของคุณก่อนในขั้นตอนการสมัครเพื่อให้โอกาสที่ดีที่สุดสำหรับการมีแพตช์ที่ผสานก่อนกำหนดส่งใบ สมัคร
ในขณะที่มีการรวมแพตช์ก่อนกำหนดเวลาแอปพลิเคชันเป็นที่ต้องการหากแพตช์ของคุณยังอยู่ระหว่างการตรวจสอบนั่นก็ไม่เป็นไร สิ่งสำคัญคือการรวมแพทช์ของคุณจะถูกรวมเข้าด้วยกันก่อนถึงกำหนด ส่ง
มันขึ้นอยู่กับคุณที่จะตอบสนองต่อความคิดเห็นของเราในเวลาที่เหมาะสมเพียงพอเพื่อให้แพตช์ของคุณถูกรวมเข้าด้วยกันก่อนกำหนดเวลา การยอมรับ
ในใบสมัครของคุณโปรดให้สรุปสั้น ๆ เกี่ยวกับการมีส่วนร่วมของคุณต่อ Stdlib จนถึงตอนนี้รวมถึงงานที่ยังไม่ได้รวมเข้าด้วยกัน นี่ควรเป็นรายการคำขอดึงและบ่งชี้ว่าคำขอดึงแต่ละครั้งจะถูกรวมปิดหรือยังเปิดอยู่ หากคุณมีส่วนร่วมอย่างมีนัยสำคัญนอกเหนือจากคำขอดึงของคุณ (เช่นการตรวจสอบคำขอดึงของคนอื่น) คุณอาจแสดงรายการนั้นเช่นกัน
โปรดทราบว่าเราจะ ไม่ ทนต่อการลอกเลียนแบบในรูปแบบใด ๆ เมื่อพัฒนาแอปพลิเคชันของคุณ ทำโดยการเขียนด้วยคำพูดของคุณเอง
ในขณะที่ผู้สมัครคนอื่น ๆ อาจพูดคุยและส่งข้อเสนอสำหรับความคิดเดียวกันต่อสาธารณะคุณไม่ควรยกเนื้อหาจากข้อเสนอของพวกเขา คุณควรเขียนและเสนอสิ่งที่ คุณ คิดว่าเป็นแนวทางที่ดีที่สุดในการดำเนินการเพื่อให้มั่นใจว่าโครงการที่ประสบความสำเร็จตามไทม์ไลน์ที่ คุณ เชื่อว่าเหมาะสม
หากเราตรวจพบว่าแอปพลิเคชันของคุณมีเนื้อหาลอกเลียนแบบเราจะปฏิเสธแอปพลิเคชันของคุณโดยไม่ต้องตรวจสอบ
นอกจากนี้ในขณะที่เรารับรู้ว่าสำหรับผู้มีส่วนร่วมหลายคนภาษาอังกฤษอาจไม่ใช่ภาษาแรกของคุณโปรดหลีกเลี่ยงการใช้ LLMS (เช่น CHATGPT ฯลฯ ) โดยทั่วไปเราสามารถบอกได้ว่าเมื่อใดที่บุคคลนั้นพึ่งพา LLM เพื่อสร้างเนื้อหาแอปพลิเคชันอัตโนมัติ (และการบริจาครหัส!) และสิ่งที่สัญญาณนี้ให้เราคือคุณไม่สามารถใช้เวลาในการเขียนแอปพลิเคชันที่รอบคอบและคุณน่าจะไม่เป็น สามารถรับความไว้วางใจของเราได้
ผู้สมัครที่ดีที่สุดคือผู้ที่รอบคอบผู้ให้ความสนใจในรายละเอียดและผู้ที่กระตือรือร้นและเต็มใจที่จะเรียนรู้
เอกสารนี้ยืมมาอย่างหนักจาก
เอกสารนี้อาจนำกลับมาใช้ใหม่ภายใต้ใบอนุญาต Creative Commons Attribution-Shareike 4.0 International (CC BY-SA 4.0)
