ได้มีโอกาสไปลองร่วมงาน Contributor Day ที่จัดขึ้นก่อนวันงาน WordCamp Bangkok 2018 ซึ่งงาน Contributor Day เป็นงานที่จัดขึ้นมาเพื่อเปิดโอกาสให้ใครก็ตามได้เข้ามามีส่วนร่วมในการพัฒนา WordPress ซึ่งเค้าก็จะแบ่งเป็นทีมต่างๆ ตั้งแต่การร่วมพัฒนาส่วน Core ตลอดจนถึงการสร้าง Community ของ WordPress ให้แข็งแกร่งยิ่งขึ้น
ตอนแรกลังเลอยู่ว่าจะไปร่วมทีม Core หรือทีม CLI ดี แล้วก็แว๊บไปเห็นชื่อลีดเดอร์ของทีม Core ผมนี่ตัดสินใจง่ายเลย ว่าจะไปร่วมทีม CLI.. ผิด! ผมต้องไปร่วมทีม Core สิ ท่านผู้นำของทีมนี้คือ Konstantin Obenland (@obenland) มาจากบริษัท Automattic ซึ่งเป็นบริษัทที่พัฒนา WordPress เชียว โอกาสแบบนี้หาไม่ได้ง่ายๆ
สิ่งที่ Konstantin สอนให้กับคนที่มาร่วมทีม Core
อ่านให้รู้
- เราสามารถมีส่วนร่วมในการ Contribute ให้กับ WordPress Core ได้หลายช่องทาง ไม่ว่าจะเป็นช่วยทดสอบ Patch ที่คนอื่นส่งเข้ามา ช่วยแก้บั๊ก รวมไปถึงช่วยพัฒนา Feature ต่างๆ
- หน้า Core Contributor Handbook นี่ก็ควรทำ Bookmark ไว้ เพราะว่าเราสามารถไปหน้าอื่นๆ จากหน้านี้ได้เลย
- อธิบายว่า Trac คือระบบที่คอยติดตาม Issue หรือ Feature ต่างๆ และยังเป็นที่ดู Source Code ของ WordPress อีกด้วย
- ส่วนประกอบของ Ticket จะมีอะไรบ้าง การกำหนด Type เพื่อบอกว่า Ticket นี้เป็นบั๊กหรือเป็น Feature การบอกเวอร์ชั่นของ WordPress (ถ้าเป็นบั๊กจะได้ทดสอบได้ถูกว่าเป็นบั๊กของเวอร์ชั่นไหน) การกำหนด Component จะได้บอกได้ถูกว่ามันคือส่วนไหนของ WordPress และการบอก Focuses ก็จะช่วยเจาะจงไปได้ว่าภายใน Component นั้นๆ ตรงไหนที่เกี่ยวข้องกับ Ticket นี้มากที่สุด
- ส่วน Workflow ต่างๆ (ตรงนี้พวกเหล่า Maintainers จะสามารถเซตได้) ยกตัวอย่าง Workflow ง่ายๆ ก็คือ ถ้า Ticket ไหนต้องการให้มีคนส่ง Patch มาแก้ ก็จะแปะคำว่า
needs-patchเอาไว้ ส่วน Ticket ไหนที่มี Patch แล้วก็จะแปะhas-patchไว้ หรือ Ticket ไหนถ้าต้องการ Feedback จากเหล่าผู้พัฒนาก็จะแปะdev-feedbackเอาไว้เป็นต้น ลองตามไปอ่านต่อที่ Trac Workflow Keywords - สำหรับคนที่อยากจะเริ่ม Contribute ให้ติดตาม Ticket ที่แปะ
good-first-bugsไว้ หรือเข้าไปดู Ticket ที่มีแปะคำนี้ไว้ ที่หน้า Good First Bugs ก็ได้เช่นกัน
ลงมือทำให้เป็น
- โค้ดหลักของ WordPress เก็บอยู่ที่ Repository นี้ (เป็น Subversion)
- โค้ดของ WordPress ที่ GitHub ไม่ว่าจะเป็นส่วนที่ Release ไปแล้วหรือที่ยัง Develop อยู่จะถูก Sync มาจาก Subversion แปลว่าเรายังไม่สามารถเปิด Pull Request เข้าไปช่วยพัฒนาได้ เรายังคงต้องส่ง Patch ผ่านระบบ Trac อยู่ดี ณ ตอนนี้
- การที่เราจะ Contribute เข้า WordPress Core นั้น เราควรใช้โค้ดจาก Trunk หรือจาก wordpress-develop บน GitHub เพราะว่าจะมี Tools ต่างๆ เช่น Grunt หรือ Unit Tests รวมอยู่ด้วย หรือเราจะใช้ VVV ก็ได้ ลงตัวเดียวจบ
- การทดสอบ Patch ให้อ่าน Testing A Patch ซึ่งจะมีคำอธิบายวิธีอยู่
- การส่ง Patch ให้อ่าน Submitting a Patch แต่ถ้าใครที่ใช้ Git ให้อ่านที่ Patches สรุปง่ายๆ ก็คือ หลังจากที่เราแก้ไขโค้ดแล้ว คอมมิต เราจะสร้างไฟล์ Diff ขึ้นมา โดยตั้งชื่อไฟล์เป็นเลข Ticket นั้นๆ พอเสร็จแล้วเราก็จะอัพโหลดไฟล์ Patch เข้าไปยัง Ticket นั้นๆ ก็เป็นอันเสร็จ
ได้ส่ง Patch แรกในชีวิตเข้า WordPress Core
เรียกว่าโชคดีก็ว่าได้ที่ได้ทำ Patch นี้ เพราะว่าเปิดกันมาเจอพอดี และงานที่ทำก็ไม่ยากเกินไป ประมาณว่าให้ลดจำนวน Function Calls โดยการไปเรียก Function ที่เหมาะสมกว่าแทน
ผมทำขั้นตอนประมาณนี้
- ไปโคลน wordpress-develop ใน GitHub ลงมาบนเครื่อง
- ติดตั้ง WordPress บนเครื่องจาก Source Code นั้นจนเสร็จ เพื่อทำ Manual Tests ต่างๆ ได้
- สร้าง Branch ใหม่
- แก้โค้ด เสร็จแล้วก็คอมมิต
- สร้าง Diff ไฟล์โดยเทียบ Branch ที่ผมสร้างใหม่กับ Branch ที่ชื่อ Master (ซึ่งเป็น Branch หลัก) โดยชื่อไฟล์ก็จะเป็นเลข Ticket ตัวอย่างเช่นถ้า Ticket มีเลข 43339 เราก็สร้างไฟล์ชื่อ
43339.diff - เข้าไปใน Ticket แล้วอัพโหลดไฟล์ Diff ก็เป็นอันเสร็จ
- ถ้ามีสิ่งที่ต้องแก้ เราก็แค่มาแก้โค้ดบนเครื่อง เสร็จแล้วก็คอมมิต สร้าง Diff ไฟล์ แล้วอัพโหลดกลับเข้าไปใหม่
ผลลัพธ์ที่ได้ก็ตามนี้..
เวลาที่เหลือทำอะไร?
ตอนแรกผมว่าจะลองหา Ticket ทำต่อ แต่ทีนี้บางส่วนต้องรัน Unit Tests ทดสอบ แล้วไม่ค่อยอยากใช้ VVV เท่าไหร่ เพราะหนักเครื่องมาก เลยนั่งทำ Docker Press ขึ้นมาเองครับ สามารถรัน Unit Tests ได้ด้วย เบาๆ 😛
ปิดท้าย
ขอขอบคุณ Konstantin มา ณ ที่นี้ด้วย ที่ช่วยแนะนำให้ตั้งแต่แรกจนจบงาน 🙂
แล้วก็ขอบคุณทีมงาน WordCamp Bangkok มาด้วย ที่จัดงานดีๆ แบบนี้ จัดต่อไปนะ 😀
Credit: ขออนุญาตนำรูปจากคุณ Pathompong Sangkajit มาเป็นรูป Featured Image นะครับ
