เหตุใดผู้ใช้จึงไม่สามารถสร้าง Issue ได้โดยตรง

 (github.com/ghostty-org)
12 คะแนน โดย GN⁺ 2026-01-03 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในรีโพซิทอรี Ghostty ผู้ใช้ไม่สามารถสร้าง Issue ได้โดยตรง และต้องเริ่มการพูดคุยใน GitHub Discussions ก่อน
  • โปรเจกต์นี้ ไม่ใช้ตัวติดตาม Issue สำหรับการพูดคุยเรื่องบั๊กหรือคำขอฟีเจอร์ โดยการสนทนาทั้งหมดจะเกิดขึ้นใน Discussions
  • เมื่อการพูดคุยมีความชัดเจนเพียงพอและ สรุปเป็นรายการที่นำไปดำเนินการได้ ผู้ดูแลจะเปลี่ยนสิ่งนั้นให้เป็น Issue
  • วิธีนี้เป็น โครงสร้างที่ช่วยให้ผู้ดูแลและผู้มีส่วนร่วมค้นหา Issue ที่ลงมือทำได้จริงอย่างรวดเร็ว
  • เนื่องจากรายงานส่วนใหญ่เป็น ปัญหาเฉพาะสภาพแวดล้อมของผู้ใช้ ความเข้าใจผิด หรือคำขอฟีเจอร์ที่ยังไม่ได้พัฒนา ขั้นตอนนี้จึงสำคัญต่อการควบคุมคุณภาพของโปรเจกต์

นโยบายการจำกัดการสร้าง Issue

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

หลักการดำเนินงานของตัวติดตาม Issue

  • Ghostty ไม่ใช้ตัวติดตาม Issue สำหรับการอภิปรายหรือคำขอฟีเจอร์
    • คำขอฟีเจอร์หรือคำถามทั่วไปจะจัดการใน Discussions
    • Issue จะมีเฉพาะ บั๊กที่นิยามไว้อย่างชัดเจนหรือรายการงานที่ดำเนินการได้
  • แนวทางนี้เป็น หลักการดำเนินงานที่ก่อตัวขึ้นจากประสบการณ์ในการดูแลโปรเจกต์โอเพนซอร์ส
    • จากประสบการณ์ที่ผ่านมา 80~90% ของรายงานจากผู้ใช้ไม่ใช่บั๊กจริง แต่เป็นความเข้าใจผิดหรือปัญหาสภาพแวดล้อม
    • ส่วนที่เหลือส่วนใหญ่เป็น คำขอฟีเจอร์ที่ยังไม่ได้พัฒนา ซึ่งมักต้องการรายละเอียดเพิ่มเติม

การเพิ่มประสิทธิภาพในการดูแลรักษา

  • เมื่อผ่านขั้นตอน Discussions ผู้ดูแลจะจัดการเฉพาะปัญหาที่ผ่านการตรวจสอบแล้วในรูปแบบ Issue
    • ลดรายงานซ้ำที่ไม่จำเป็นหรือบั๊กรายงานที่ไม่ถูกต้อง
    • ทำให้รายการ Issue ถูกจัดระเบียบโดยเน้นรายการที่ลงมือทำได้ทันที
  • ผู้ใช้ ไม่จำเป็นต้องทำงานเพิ่มเติมแม้จะพบปัญหาที่ใช้ได้จริง
    • ผู้ดูแลจะเปลี่ยนเป็น Issue และจัดการให้โดยตรง

เอกสารอ้างอิง

  • สามารถดูขั้นตอนโดยละเอียดและแนวทางการมีส่วนร่วมได้ในไฟล์ CONTRIBUTING.md
  • ในเอกสารดังกล่าวมีการระบุ วิธีเข้าร่วม Discussions และเกณฑ์ในการเปลี่ยนเป็น Issue ไว้อย่างชัดเจน

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

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

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

  • เห็นด้วย 100% ถ้าเป็นโปรเจ็กต์ของคนอื่น อำนาจในการตัดสินว่าอะไรควรเป็น issue ก็เป็นของคนนั้นทั้งหมด
    ยิ่งโปรเจ็กต์ใหญ่ ก็ยิ่งมีทั้งคนที่ไม่อ่านข้อความ คนที่ขออะไรแปลกๆ หรือแม้แต่กรณี ใช้ AI ปั่น CVE ให้ดูเกินจริง

    • ไม่เข้าใจจริงๆ ว่าทำไมบางคนถึงไม่อ่านข้อความ error
      ถึงผู้ใช้จะไม่รู้ความหมายของ error อย่างน้อยก็ควรบอกว่า ขึ้น error อะไร
      เคยมีตอนทดสอบที่ระบุชัดว่าเป็น “broken pipe error” แต่วิศวกรปิดเคสโดยบอกว่า “reproduce ไม่ได้” แล้วก็อ้าง error เดิมนี่แหละว่าเลย reproduce ไม่ได้
    • Github Issues มี ข้อจำกัดในฐานะ bug tracker
      tracker ส่วนใหญ่จัดสถานะอย่าง “unconfirmed” ได้ แต่ Github เป็นแค่ระบบ discussion แบบเรียบง่าย เลยจัดการยาก
    • เคยได้รับรายงาน CVE หลังจาก ChatGPT เปิดตัวได้ไม่นาน
      ใช้เวลา 4 ชั่วโมงโต้แย้งพร้อมยกโค้ดและหลักฐาน สุดท้ายคำตอบที่ได้คือ “shrugs AI”
    • ผู้ใช้จำนวนมากแค่อยากได้ผลลัพธ์ โดย ไม่มีเวลาศึกษาวิธีใช้เครื่องมือให้ถูกต้อง
      “Facebookization” ทำให้คนคุ้นกับแนวคิดว่าคลิกไม่กี่ครั้งก็เสร็จ และตอนนี้ “LLMization” ก็น่าจะยิ่งซ้ำเติม
      วิธีคิดแบบนี้ไม่เหมาะกับซอฟต์แวร์เฉพาะทาง แต่ความคาดหวังของคนก็ถูกสร้างมาแบบนั้นแล้ว
    • issue tracker ที่ดีควรมีฟังก์ชันกรอง noise พวกนี้ได้
      การที่ Ghostty ใช้ discussion เพื่อคัดแยกคำขอเป็นแนวทางที่ไม่เหมือนใคร แต่ก็ใช้ได้ผล

  • การสืบสวน memory leak กระจัดกระจายอยู่หลายแพลตฟอร์ม
    ลิงก์ X 1, ลิงก์ X 2, discussion 1, discussion 2
    ยังไม่ได้ยกระดับเป็น issue อย่างเป็นทางการ

    • ผมเลิกใช้ Ghostty เพราะ memory leak
      แม้แต่บนเครื่องที่มีแรม 8GB แค่เปิด terminal ไม่กี่ครั้งก็หน่วยความจำไม่พอแล้ว
      Foot ฟีเจอร์น้อยกว่า แต่เสถียรกว่ามาก
    • ตามลิงก์แรก ผู้เขียนบอกว่าปัญหานี้มีรายงานแค่สองครั้ง
      ลิงก์ที่สองดูเหมือนเป็นความพยายามจะหาเรื่องโต้เถียงมากกว่า
    • ผมก็เคยรายงานปัญหานี้ไว้ในdiscussion แต่ไม่มีการตอบกลับ
      ผมวิเคราะห์ log ด้วย Claude Code แล้วแก้ชั่วคราว ตอนนี้เลย reproduce ได้แค่ประมาณ 1 ใน 10 ครั้ง
      หวังว่าจะช่วยคนที่มาสืบต่อทีหลังได้
    • เรื่องความเข้ากันได้ของ GPU ก็จุกจิกเหมือนกัน
      แม้แต่ integrated GPU ก็ยังมีปัญหา แต่สุดท้ายก็มักโทษ GTK หรือ Nvidia ตลอด
    • ดูเหมือนผู้มีส่วนร่วมยังเห็นว่า เงื่อนไขการ reproduce ที่ชัดเจน ยังไม่พอ เลยยังไม่ยกขึ้นเป็น issue

  • คิดว่าการแยกระหว่าง “Issues” กับ “Discussions” ไม่มีประสิทธิภาพ
    ต้องค้นหาซ้ำซ้อน และก็ย้าย ticket ไปมาไม่ได้
    ถ้าตามต่อทางอีเมล การแจ้งเตือนก็ขาดหายไปเลย
    เพราะงั้นในโปรเจ็กต์ของผมเลยปิด Discussions ไปแล้ว

    • Discussions มีประโยชน์ในฐานะพื้นที่สำหรับคำถามทั่วไปหรือปัญหาการติดตั้ง
      ถ้าเป็นบั๊กจริง ค่อยเปลี่ยนเป็น issue ตอนนั้นก็ได้
    • กระบวนการแบบนี้ทำผ่าน ระบบ label ก็ได้เหมือนกัน
      แค่ให้แอดมินติด label “bug” ก็พอ
    • ไม่จำเป็นต้องตรวจ duplicate
      เพราะถ้าสรุปการคุยกันได้แล้ว ค่อยสร้าง issue ตอนนั้นก็ได้
    • จริงๆ แล้ว issue กับ discussion แปลงหากันได้
      และการแจ้งเตือนก็ยังคงอยู่
    • แบบโครงสร้างของ Ghostty ที่ใครก็เปิด Discussions ได้ แต่ Issues ให้แอดมินจัดการนั้น ดูเป็น การแยกหน้าที่ที่สมเหตุสมผล

  • โปรเจ็กต์ใหญ่บางส่วนในชุมชน Python ก็ใช้วิธีนี้เหมือนกัน
    แต่ในมุมของ power user ขั้นตอนการรายงานบั๊กมัน ยุ่งยาก
    ท่าทีแบบ “โปรเจ็กต์เราสมบูรณ์แบบ” ทำให้รู้สึกหยิ่งยโส

    • เข้าใจความไม่พอใจแบบนี้ได้ยาก
      drive-by bug report ส่วนใหญ่ใช้ประโยชน์ไม่ได้ และยิ่งเพิ่ม noise
      ถ้าอยากมีส่วนร่วมจริง การไปแก้บั๊กที่นิยามไว้แล้วน่าจะดีกว่า
    • หยิ่งยโสเหรอ? ตรงกันข้าม พวกเขาคือคนที่ สละเวลาและแรงไปให้ฟรีๆ
      การตั้งข้อจำกัดกับวิธีรายงานก็เป็นเรื่องปกติ
    • ถ้าคุณเจอบั๊กบ่อยขนาดนั้น การเข้าไปมีส่วนร่วมกับโปรเจ็กต์โดยตรงก็น่าจะดี
    • ในทางกลับกัน การมั่นใจว่า “นี่คือบั๊กชัดๆ” ก็อาจเป็นความหยิ่งอีกรูปแบบหนึ่งเหมือนกัน
    • การเปิด discussion มันยุ่งยากกว่าการเปิด issue จริงหรือ? ผมก็ไม่แน่ใจ

  • ต่อข้ออ้างที่ว่า “ทุก issue ต้องอยู่ในสภาพพร้อมให้เริ่มทำงานได้ทันที”
    ก็มีคนถามว่า “ถ้างั้นแค่ติดแท็ก ‘ready-to-be-worked-on’ ไม่พอเหรอ?”

    • แต่ Github ตั้งค่า default view เป็น “triage” ไม่ได้ และในโปรเจ็กต์ขนาดใหญ่ การจัดการ issue ไม่มีประสิทธิภาพ
      ระบบนี้ประสบความสำเร็จกว่ามาก
    • วิธีใช้แท็กต้องผ่าน feedback หลายรอบ ทำให้รายละเอียดกระจายอยู่ตามคอมเมนต์
    • ถ้าเปิดให้ใครก็ได้คอมเมนต์ จะเกิด เสียงรบกวนที่ไม่จำเป็น
      เลยแยกพื้นที่ของนักพัฒนาออกจากพื้นที่ของผู้ใช้
    • issue ที่ผิดพลาด ต่อให้ปิดไปก็ถูกเปิดใหม่ได้ สุดท้าย รายการ issue ก็ล้นจนรับมือไม่ไหว
    • ไม่จำเป็นต้องไปยัดเยียด workflow ของตัวเองให้คนอื่นว่า “ทำไมวิธีฉันดีกว่า”

  • Issues นั้น พอขยายใหญ่ก็จัดการไม่ไหว
    ใช้ Discussions เป็นตัวกรองจะมีประสิทธิภาพกว่า

    • แต่สุดท้าย maintainer ก็ยังต้องอ่านและคัดแยกทุกโพสต์อยู่ดี ดังนั้น ปริมาณงานก็พอๆ กัน
      ฟีเจอร์สองอย่างนี้ของ Github มี UI แทบจะเหมือนกัน
      เพียงแต่ Discussions มี ฟังก์ชัน upvote
    • ยังมีเสียงประชดด้วยว่า “งั้นปิดทุก issue อัตโนมัติหลัง 2 สัปดาห์ไม่ยิ่งมีประสิทธิภาพกว่าเหรอ?”
    • โปรเจ็กต์ใหญ่ระดับ Curl ยังมี open issue แค่ 5 อัน
      curl/curl/issues

  • ยังมีความเห็นว่าวิธีนี้ควรเป็นค่าเริ่มต้น
    ให้ชุมชนดูแล discussion และให้ผู้มีส่วนร่วมดูแล issue จะเป็นโครงสร้างที่เหมาะที่สุด

    • แต่นี่ก็แค่ การจัดวางกระบวนการใหม่ เท่านั้น แก่นแท้ยังเหมือนเดิม
      ใช้ระบบ label ของ GitHub ก็จัดการได้เพียงพอแล้ว
      เอกสารการจัดการ label ของ GitHub
    • แทนที่จะกำหนด “ค่าเริ่มต้น” ตายตัว ให้แต่ละโปรเจ็กต์ ทดลองไปตามธรรมชาติ แล้วหาวิธีที่เหมาะกับตัวเองน่าจะดีกว่า
      คล้ายกับ Natural experiment

  • เห็นด้วยกับนโยบายการรับเรื่องจากผู้ใช้
    ถ้าดู discussion ที่ปิดไปแล้ว มันก็คล้ายกับ issue ที่ปิดแล้ว แต่ก็อย่างน้อย ช่วยลด noise ในแท็บ issue ได้
    รายการ discussion ที่ปิดแล้วของ Ghostty

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

  • จริงๆ แล้วการที่ “เปิด issue ไม่ได้” ไม่ใช่ฟีเจอร์ของ GitHub
    มันเป็นแค่ ข้อความในเทมเพลต ที่บอกว่า “อย่าเปิด issue ใหม่ ให้ใช้ Discussions แทน”

  • เคยเห็นวิธีนี้ในโปรเจ็กต์อื่นเหมือนกัน
    โครงสร้างแบบ ใช้ discussion เป็นจุดเริ่มต้น ดูสมเหตุสมผลมากทีเดียว
    เพียงแต่หลายโปรเจ็กต์ยังไม่ได้เปิดใช้ GitHub Discussions
 
iolothebard 2026-01-03

แล้วการสนทนานั้นต่างจาก issue อย่างไร? issue ไม่ได้หมายถึงแค่ “บั๊ก” เท่านั้น ไม่ว่าจะเป็นบั๊ก ข้อเสนอฟีเจอร์ หรือ PR... ถ้ามีประเด็นให้ถกเถียงกัน นั่นก็คือ issue
ถ้าไม่มีคุณค่าพอให้ถกเถียง ก็ปิดมันได้
 
nemorize 2026-01-09

ไม่ใช่ว่าระหว่าง Discussion กับ Issue มีความต่างกันอะไรเป็นพิเศษหรอก น่าจะแค่ชอบให้แยกเป็นแท็บคนละอันมากกว่า

จะโพสต์ทั้งทูดูลิสต์และ Discussion ไว้ในแท็บ Issue แล้วจัดการด้วยแท็ก
vs
หรือจะใช้แท็บ Issue สำหรับทูดูลิสต์เท่านั้น และใช้ Discussion สำหรับ Discussion เท่านั้น