วิวัฒนาการของ GitHub Issues (พรีวิวสาธารณะ)

 (github.blog)
2 คะแนน โดย GN⁺ 2024-10-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เปิดตัวการปรับปรุงหลากหลายอย่าง เช่น Sub-Issue, Issue Type และการค้นหา Issue

จัดการ Issue ให้ละเอียดขึ้นด้วย Sub-Issue

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

จัดระเบียบงานด้วย Issue Type

  • ใช้ Issue Type เพื่อจัดหมวดหมู่และจัดการ Issue ด้วยภาษากลางร่วมกันที่ใช้ข้ามทุกรีโพซิทอรีภายในองค์กรได้
  • ช่วยให้ดูความคืบหน้าของ bug backlog ได้อย่างรวดเร็ว ค้นหา high-level initiative ทั้งหมดที่ทีมกำลังทำอยู่ และเข้าใจการจัดประเภทงานของโปรเจ็กต์ได้

ค้นหาสิ่งที่ต้องการได้อย่างแม่นยำด้วยการค้นหาขั้นสูง

  • บนหน้า Issue ของรีโพซิทอรี สามารถตั้งค่าการค้นหาขั้นสูงได้ด้วยคีย์เวิร์ด AND และ OR รวมถึงวงเล็บสำหรับการค้นหาแบบซ้อน
  • สร้างฟิลเตอร์ที่ซับซ้อนมากขึ้นเพื่อค้นหาชุด Issue ที่ต้องการได้อย่างแม่นยำ

อัปเดต UI ของ Issue

  • เพิ่มแถบฟิลเตอร์ใหม่ในหน้า index ของ Issue ที่มี autocomplete และ syntax highlighting
  • การสร้างหลาย Issue ทำได้เร็วขึ้นด้วยตัวเลือก 'Create More' ที่ช่วยให้กลับไปยังหน้าสร้างได้อย่างรวดเร็ว
  • ตั้งค่าลำดับที่ต้องการได้ง่ายขึ้นด้วยแบบฟอร์มและเทมเพลตของ Issue ที่แสดงเรียงตามตัวอักษรของชื่อไฟล์
  • แชร์ URL ของ Issue ได้ง่ายด้วยปุ่ม 'Copy Link' ใหม่
  • สำหรับ Issue ที่ยาว เมื่อเลือก 'Load More' ตอนนี้จะดึง 150 อีเวนต์แทน 50 รายการ

จำนวนไอเท็มใน GitHub Projects เพิ่มขึ้น

  • ก่อนหน้านี้ได้ประกาศ private beta ของการเพิ่มขีดจำกัดไอเท็มในโปรเจ็กต์ จาก 1,200 เป็น 50,000 ต่อโปรเจ็กต์
  • วันนี้ได้ขยายกลุ่มเป้าหมายของขีดจำกัดที่เพิ่มขึ้นนี้
  • หลังจาก private beta ได้เพิ่มการรองรับ slice, swimlane และ GraphQL API รวมถึงแก้ไขรายงานบั๊กสำคัญและปรับปรุงประสิทธิภาพ
  • หากคุณเป็นผู้ดูแลโปรเจ็กต์ และโปรเจ็กต์นั้นไม่ได้ใช้งาน insights (ฟีเจอร์เดียวที่ยังไม่รองรับในตอนนี้) พร้อมทั้งกำลังเข้าใกล้ขีดจำกัดไอเท็ม จะแสดงแบนเนอร์เหนือโปรเจ็กต์
  • อัปเดตนี้เกิดขึ้นเป็นรายโปรเจ็กต์ ไม่ใช่รายองค์กร ดังนั้นสามารถเข้าร่วมได้โดยคลิกปุ่ม "Join Waitlist" ในโปรเจ็กต์ที่มีสิทธิ์

ความเห็นของ GN⁺

  • นี่เป็นอัปเดตที่ยกระดับเครื่องมือ issue tracking เดิมขึ้นไปอีกขั้น และน่าจะช่วยปรับปรุงการทำงานร่วมกันของทีมพัฒนาซอฟต์แวร์ได้อย่างมาก
  • ข้อดีของการใช้ Sub-Issue คือช่วยแยกย่อยงานพร้อมกับทำให้เห็นภาพรวมความคืบหน้าได้ง่ายขึ้น แต่ถ้าโครงสร้างลำดับชั้นลึกเกินไปก็อาจกระทบต่อความอ่านง่ายได้เช่นกัน
  • การตั้งค่า Issue Type ที่ทำให้สามารถจัดการ Issue ด้วยภาษาที่เป็นมาตรฐานเดียวกันภายในองค์กรได้เป็นจุดที่น่าสนใจ น่าจะช่วยเพิ่มการสื่อสารและความเข้าใจระหว่างทีม
  • ฟีเจอร์การค้นหาขั้นสูงน่าจะมีประโยชน์มากในการค้นหาข้อมูลที่ต้องการอย่างรวดเร็วจาก Issue จำนวนมาก แต่ควรมีการฝึกอบรมผู้ใช้ให้เขียน query ที่ซับซ้อนได้ก่อน
  • การเพิ่มขีดจำกัดไอเท็มในโปรเจ็กต์น่าจะช่วยอย่างมากต่อการจัดการโปรเจ็กต์ขนาดใหญ่ อย่างไรก็ตาม การใส่ไอเท็มมากเกินไปไว้ในโปรเจ็กต์เดียวก็ไม่ใช่แนวทางที่เหมาะสม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-03
ความคิดเห็นจาก Hacker News

  • จุดอ่อนที่ใหญ่ที่สุดของ GitHub Issues คือเมื่อเข้าไปที่หน้า issue รายงานต้นฉบับจะแสดงเป็นเนื้อหาหลัก

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

  • เคยอยากใช้ GitHub Issues แต่ผิดหวังที่มันซับซ้อนขึ้น

    • กังวลว่ามันจะซับซ้อนแบบ ADO, Jira, Asana

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

    • ตอนนี้โฟกัสถูกทำให้พร่าเลือนจากคำขอความช่วยเหลือ ข้อเสนอแนะ และบทสนทนา
    • ไม่สนใจการทำให้ Issue กลายเป็นแบบ Jira

  • เป็นคนทำอัปเดตใหญ่ครั้งล่าสุดของ GitHub Issues เมื่อ 10 ปีก่อน และคาดหวังมากกว่านี้

    • ให้ความรู้สึกเหมือนการพัฒนาแบบอิงเช็กบ็อกซ์
    • มี React รวมอยู่ด้วย

  • ควรมีสถานะเพิ่มอย่าง "closed - duplicate", "closed - won’t fix", "our bot closed this because no one commented on it for 6 weeks"

    • เวลาพบปัญหาแล้วเห็นว่ามันถูกปิดไปแล้วมักทำให้รู้สึกหงุดหงิด

  • ไม่เข้าใจปฏิกิริยาเชิงลบ

    • สำหรับผู้ใช้ระดับองค์กร นี่เป็นการอัปเกรดที่ยอดเยี่ยม
    • เป็นการไล่ตาม Gitlab Issue หรือ Linear ให้ทัน

  • มี label อยู่แล้ว เลยไม่เข้าใจว่าประเภท issue มีความหมายอะไร

  • ถ้าเพิ่มหลายปัญหาไว้ในคอมเมนต์ของ issue เดียว จะติดตามได้ยาก

    • มีวิธีเพิ่มเช็กบ็อกซ์ [ ] ได้ แต่ไม่ชัดเจนว่าใครเป็นคนทำเสร็จ
    • มีวิธีเพิ่มรีวิวคอมเมนต์ใน pull request ของโค้ดได้เช่นกัน แต่ไม่สามารถระบุคนที่ได้รับมอบหมายได้

  • ปัญหาใหญ่ที่สุดของ GitHub Issues คือโปรเจกต์โอเพนซอร์สขนาดใหญ่ไม่สามารถแสดง issue ที่มีลำดับความสำคัญได้ง่าย

    • แม้จะใช้การกำกับดูแลที่เข้มงวดได้ แต่ก็ทำให้ผู้เปิด issue รู้สึกกังวล
    • ต้องการวิธีแยกระหว่าง backlog กับงานที่ต้องทำ

  • ชอบการปรับปรุงรายการงานที่เคยใช้ในอดีต

    • ชอบแนวทางการจัดการโปรเจกต์แบบยืดหยุ่นเป็นธรรมชาติ
    • แต่ผิดหวังที่มันเปลี่ยนไปเป็นงานย่อยแบบระบุชัดเจน