first-contributions/docs/additional-material/Things a non Programmer can do.th.md

#สิ่งที่คนที่ไม่ใช่โปรแกรมเมอร์สามารถทำได้

เริ่มฟัง

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

1. เข้าร่วมรายชื่ออีเมล: สำหรับหลายโครงการ รายชื่ออีเมลเป็นช่องทางหลักในการสื่อสารเกี่ยวกับการพัฒนาโครงการ ในโครงการขนาดใหญ่ มีรายชื่อผู้รับจดหมายให้เลือกมากมาย ตัวอย่างเช่น โครงการ PostgreSQL มีรายชื่อผู้ใช้ไม่น้อยกว่า 12 รายการ และรายชื่อนักพัฒนาอีก 6 รายการในหน้ารายชื่อผู้รับเมล ฉันขอแนะนำให้คุณปฏิบัติตามรายการหลักที่มุ่งเน้นผู้ใช้และรายชื่อนักพัฒนาหลักที่จะเริ่มฟัง

2. ติดตามบล็อก: บล็อกที่ดูแลโดยนักพัฒนาหลักมักจะให้ข้อมูลเกี่ยวกับสิ่งที่จะเกิดขึ้นในอนาคต และสิ่งที่ต้องทำเพื่อไปถึงที่นั่น ไซต์ Planet รวบรวมข่าวสารและบล็อกจากแหล่งต่างๆ ที่เกี่ยวข้องกับโครงการ หากมีไซต์ planet เช่น planet.gnome.org หรือ planet.mysql.com ให้เริ่มต้นจากที่นั่น เพียงค้นหา Google ด้วยคำว่า "planet "

3. เข้าร่วมช่อง IRC: โครงการโอเพ่นซอร์สจำนวนมากมีช่อง Internet Relay Chat (IRC) โดยเฉพาะ ซึ่งนักพัฒนาและผู้ใช้ออกไปเที่ยวเพื่อหารือเกี่ยวกับปัญหาและการพัฒนา ตรวจสอบเว็บไซต์ของโครงการเพื่อดูรายละเอียดว่าช่องดังกล่าวเรียกว่าอะไรและพบเครือข่าย IRC ใด

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

4. วินิจฉัยจุดบกพร่อง: มักมีการรายงานจุดบกพร่องไม่ดี การวินิจฉัยและคัดแยกจุดบกพร่องสามารถช่วยให้นักพัฒนาประหยัดเวลาโดยต้องอาศัยการทำงานที่ถูกต้องในการหาลักษณะเฉพาะของปัญหา หากผู้ใช้รายงานว่า "ซอฟต์แวร์ไม่ทำงานเมื่อฉันทำ X" ใช้เวลาสักพักเพื่อหาสาเหตุเฉพาะของปัญหานั้น มันทำซ้ำได้หรือไม่? คุณสามารถสร้างชุดขั้นตอนเพื่อทำให้เกิดปัญหาซ้ำๆ ได้หรือไม่ คุณสามารถจำกัดปัญหาให้แคบลง เช่น เกิดขึ้นในเบราว์เซอร์เดียวแต่ไม่เกิดขึ้นอีก หรือหนึ่ง distro แต่ไม่ได้เกิดขึ้นที่อื่น

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

5. ปิดจุดบกพร่องที่แก้ไขแล้ว: บ่อยครั้งจุดบกพร่องได้รับการแก้ไขในโค้ดเบส แต่ตั๋วที่รายงานเกี่ยวกับจุดบกพร่องเหล่านั้นไม่ได้รับการอัปเดตในระบบตั๋ว การทำความสะอาดสิ่งที่ค้างอยู่นี้อาจใช้เวลานาน แต่ก็มีคุณค่าต่อทั้งโครงการ

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

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

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

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

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

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

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

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

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

8. เขียนแบบทดสอบ: โปรเจ็กต์ส่วนใหญ่มีชุดทดสอบที่ทดสอบโค้ด แต่ก็ยากที่จะจินตนาการถึงชุดทดสอบที่ไม่สามารถเพิ่มการทดสอบเข้าไปได้อีก ใช้เครื่องมือความครอบคลุมการทดสอบ เช่น gcov สำหรับ C หรือ Devel::Cover สำหรับ Perl เพื่อระบุพื้นที่ในซอร์สโค้ดที่ไม่ได้รับการทดสอบโดยชุดทดสอบ จากนั้นจึงเพิ่มการทดสอบลงในชุดเพื่อให้ครอบคลุม

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

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

11. สร้างตัวอย่าง: ไม่มีโปรเจ็กต์ใดที่มีตัวอย่างวิธีปฏิบัติมากเกินไป ไม่ว่าจะเป็นเว็บ API, ไลบรารีของกิจวัตร, แอป GUI เช่น Gimp หรือเครื่องมือบรรทัดคำสั่ง ตัวอย่างที่ดีของการใช้งานที่เหมาะสมสามารถอธิบายการใช้งานซอฟต์แวร์ที่เหมาะสมได้ชัดเจนและรวดเร็วกว่าหน้าเอกสารประกอบ สำหรับ API หรือไลบรารี ให้สร้างโปรแกรมตัวอย่างที่ใช้เครื่องมือนี้ สิ่งนี้สามารถดึงออกมาจากโค้ดที่คุณเขียนได้ โดยตัดทอนให้เหลือเพียงสิ่งจำเป็นเท่านั้น สำหรับเครื่องมือ ให้แสดงตัวอย่างการใช้งานจริงของคุณในชีวิตประจำวัน หากคุณมุ่งเน้นด้านการมองเห็น ลองพิจารณาสร้างภาพหน้าจอของกระบวนการสำคัญ เช่น วิธีการติดตั้งแอพพลิเคชั่น

ทำงานร่วมกับชุมชน โอเพ่นซอร์สเป็นเพียงบางส่วนเกี่ยวกับโค้ดเท่านั้น ชุมชนทำให้โอเพ่นซอร์สทำงานได้ ต่อไปนี้เป็นวิธีที่คุณสามารถช่วยสร้างมันขึ้นมาได้

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

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

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

15. เขียนเอกสารทางเทคนิค หากคุณสามารถเขียนเกี่ยวกับวิธีการทำงานของแอปพลิเคชันหรือซอฟต์แวร์ได้ คุณสามารถเขียนเอกสารทางเทคนิคเกี่ยวกับแอปพลิเคชันหรือซอฟต์แวร์นั้นได้ โดยเฉพาะโครงการโอเพ่นซอร์สที่ต้องการอัปเดต ปรับปรุง ขยาย หรือสร้างเอกสารทางเทคนิคให้บุคคลทั่วไปได้อ่าน ยิ่งคุณเขียนภาษาอังกฤษธรรมดามากเท่าไรก็ยิ่งดีเท่านั้น ส่วนที่ดีที่สุด คุณไม่จำเป็นต้องเป็นโปรแกรมเมอร์จึงจะเขียนเอกสารทางเทคนิคได้

สิ่งสำคัญที่สุดคือฟังสิ่งที่คนรอบตัวคุณพูดคุยกัน ดูว่าคุณสามารถรับรู้ถึงความจำเป็นเร่งด่วนหรือไม่ ตัวอย่างเช่น เมื่อเร็ว ๆ นี้ในรายชื่อผู้รับจดหมายของนักพัฒนา Parrot มีการตัดสินใจที่จะใช้ GitHub เป็นระบบตั๋วปัญหา โดยละทิ้งการติดตั้ง Trac แบบเก่าที่พวกเขามี บางคนไม่เห็นด้วยกับการเคลื่อนไหวนี้เนื่องจากไม่มีทางที่จะแปลงตั๋วเป็นระบบของ GitHub ได้ หลังจากทะเลาะกันมาทั้งวัน ฉันก็พูดขึ้นและพูดว่า "ถ้าฉันเขียนตัวแปลงล่ะ" ผู้คนต่างตื่นเต้นกับความคิดนี้ ฉันใช้เวลาเขียนโปรแกรมแปลงตั๋วสำหรับตั๋วมากกว่า 450 ใบ ดังนั้นเราจึงไม่สูญเสียประวัติตั๋วเลย มันเป็นความสำเร็จที่ยิ่งใหญ่. ฉันได้เข้าร่วม และนักพัฒนาหลักยังคงมุ่งเน้นไปที่ธุรกิจการทำงานกับ Parrot

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