GitHub Issue Template Generator: สร้าง issue template แบบ Markdown และ Issue Forms ด้วยตัวสร้างแบบเห็นภาพ

Maintainer ทุกคนคงเคยเจอรายงานแบบที่หวาดกลัว: bug report ที่เขียนไว้แค่ว่า "ใช้งานไม่ได้" ไม่มีเวอร์ชัน ไม่มีขั้นตอนการเกิดปัญหา ไม่มี log — มีแค่ title กับท่าไหว้เท่านั้น ข้อความแบบนี้กินเวลาไปกับการถามตอบเพื่อทำความเข้าใจหลายชั่วโมง และนี่คือสิ่งที่ issue template ที่ออกแบบมาดีป้องกันได้โดยตรง แทนที่จะต้องตอบคำถามชุดเดิมห้าข้อใน comment ซ้ำไปมา template จะถามให้ครั้งเดียว ตั้งแต่ต้น ในรูปแบบฟอร์มที่เป็นระเบียบ

GitHub Issue Template Generator เป็นตัวสร้าง template แบบฟรีที่ทำงานบนเบราว์เซอร์โดยตรง รองรับทั้งสองรูปแบบที่ GitHub เข้าใจ: classic Markdown template ที่มี YAML front matter และ structured Issue Forms ที่เขียนเป็น YAML พร้อมฟิลด์ input, textarea, dropdown และ checkbox คุณตั้งค่าฟิลด์ด้วยตัวสร้างแบบเห็นภาพ เห็น live preview อัปเดตตามที่พิมพ์ แล้วคัดลอกหรือดาวน์โหลดไฟล์ที่เสร็จแล้วไปใช้ได้ทันที — ไม่ต้องสมัครสมาชิก ทำงานฝั่งไคลเอนต์ 100%

ทำไมต้องใช้ GitHub Issue Template Generator?

• หยุดตามล่าข้อมูลที่หายไป Template เปลี่ยนรายงานที่คลุมเครือให้เป็นรายงานที่ครบถ้วน มีเวอร์ชัน ขั้นตอนการเกิดปัญหา และพฤติกรรมที่คาดหวัง เพราะฟอร์มถามข้อมูลแต่ละส่วนอย่างชัดเจน
• ไม่มีข้อผิดพลาดไวยากรณ์ YAML Issue Forms YAML ที่เขียนมือเองมักมีปัญหาย่อหน้า (indentation) ที่ GitHub ปฏิเสธอย่างเงียบ ๆ เครื่องมือนี้สร้าง output ที่ถูกต้องตั้งแต่ commit แรก
• สองสไตล์ ในตัวสร้างเดียว สร้าง classic Markdown template สำหรับความเข้ากันได้ หรือ Issue Forms ยุคใหม่เพื่อบังคับการกรอกข้อมูล โดยไม่ต้องเรียนรู้สองรูปแบบ
• Live preview ระหว่างสร้าง เห็นฟอร์มที่ render แล้วและ output ดิบเรียงกันเคียงข้างกัน จับ label ที่อ่านไม่รู้เรื่องได้ก่อน contributor จะเจอ
• ฟิลด์ required ถูกบังคับโดย GitHub ทำเครื่องหมายฟิลด์เป็น required แล้ว GitHub จะปฏิเสธ submission ที่ไม่สมบูรณ์ — ไม่มีอะไรกรอกว่าง ๆ หลุดเข้า backlog ของคุณ
• เป็นส่วนตัวและรวดเร็ว ทุกอย่างทำงานฝั่งไคลเอนต์: ไม่มีการอัปโหลด ไม่มีการติดตาม ไม่มีข้อบังคับให้สมัครสมาชิก

ฟีเจอร์หลัก

• Output ยังคงสอดคล้องกับสิ่งที่ GitHub ตรวจสอบ ดังนั้น dropdown และตัวเลือก required จึงทำงานตามสเปกของ Issue Forms อย่างถูกต้อง
• Live preview ทำหน้าที่เป็นเอกสารไปด้วยในตัว — แสดงให้เพื่อนร่วมทีมเห็นฟอร์มที่ผู้รายงานจะเจอก่อน merge
• เพราะทุกอย่างทำงานฝั่งไคลเอนต์ การร่าง template สำหรับ private repository จึงปลอดภัยอย่างสมบูรณ์

วิธีการใช้งาน

1. เปิดตัวสร้าง เข้าไปที่ GitHub Issue Template Generator แล้วเลือกสไตล์: classic Markdown พร้อม YAML front matter หรือ structured Issue Forms YAML
2. ตั้งค่าพื้นฐาน กรอกชื่อ template, คำอธิบายที่แสดงในหน้าเลือก template, labels ที่จะใส่อัตโนมัติ และเลือกใส่ title prefix ได้ถ้าต้องการ
3. เพิ่มฟิลด์ของคุณ เลือกชนิดของแต่ละคำถาม — input สำหรับคำตอบสั้น, textarea สำหรับรายละเอียด, dropdown สำหรับรายการที่ตายตัว, checkboxes สำหรับการยืนยัน — จากนั้นตั้ง label, placeholder และว่าฟิลด์นั้นจำเป็นต้องกรอกหรือไม่
4. ตรวจสอบ live preview ดูฟอร์มที่ render แล้วและ YAML ที่สร้างได้เรียงกันเคียงข้าง ปรับลำดับฟิลด์จนกระทั่งลำดับการอ่านเป็นธรรมชาติจากมุมมองของผู้รายงาน
5. คัดลอกหรือดาวน์โหลด แล้ว commit บันทึกไฟล์เป็น .github/ISSUE_TEMPLATE/bug_report.yml (หรือ .md สำหรับ classic template) commit ลง แล้วเปิด issue ทดสอบเพื่อยืนยัน

เทียบกันให้เห็นชัด: Markdown Templates กับ Issue Forms

GitHub รองรับ issue template สองรุ่น และเครื่องมือนี้สร้างได้ทั้งคู่

Classic Markdown templates เป็นไฟล์ Markdown ธรรมดาที่มีบล็อก YAML front matter เล็ก ๆ กำหนด name, ข้อความ about สั้น ๆ ที่แสดงในหน้าเลือก template, labels สำหรับ issue ใหม่ และ title prefix ที่เลือกใส่ได้ ส่วนเนื้อหาเป็น Markdown ธรรมดาที่ผู้รายงานกรอกเองด้วยมือ Classic template ใช้ง่ายและรองรับทุกที่ — แต่ไม่มีอะไรถูกบังคับเลย ผู้รายงานลบ heading ทิ้งได้ทุกอันและส่ง issue เปล่า ๆ มาให้คุณ

Issue Forms เป็นไฟล์ YAML ที่มีโครงสร้างซึ่ง GitHub render เป็นฟอร์มจริง: input สำหรับคำตอบหนึ่งบรรทัด, textarea สำหรับรายละเอียด, dropdown ที่มีรายการตัวเลือกตายตัว และ checkboxes สำหรับการยืนยัน แต่ละฟิลด์มี label, คำอธิบาย, placeholder และกฎ validation ได้ — โดยเฉพาะตัวเลือก required ซึ่งทำให้ GitHub บล็อกการส่งจนกว่าฟิลด์นั้นจะถูกกรอก Dropdown รับประกันว่าค่าอย่างระบบปฏิบัติการมาจากรายการที่คุณกำหนด ไม่ใช่ข้อความอิสระ

ไฟล์ทั้งสองชนิดอยู่ในไดเรกทอรี .github/ISSUE_TEMPLATE/ ที่รากของ repository ไฟล์ config.yml ที่อยู่ในโฟลเดอร์เดียวกันควบคุมพฤติกรรมระดับ repository โดยเฉพาะ blank_issues_enabled: false ซึ่งตัดทางหนี "เปิด blank issue" ออกไป

นี่คือตัวอย่าง Issue Forms แบบสั้นพร้อมคำอธิบายประกอบ:

name: Bug Report # ชื่อที่แสดงในหน้าเลือก template
description: รายงานปัญหาที่ทำซ้ำได้
labels: [bug, triage] # ใส่ให้ issue ใหม่อัตโนมัติ
body:
  - type: input # คำตอบหนึ่งบรรทัด
    id: summary
    attributes:
      label: Summary
    validations:
      required: true # GitHub บล็อก submission ที่กรอกว่าง
  - type: textarea
    id: steps
    attributes:
      label: Steps to reproduce
  - type: dropdown
    id: os
    attributes:
      label: Operating system
      options: [Windows, macOS, Linux]
  - type: checkboxes
    id: checks
    attributes:
      label: ก่อนส่งรายงาน
      options:
        - label: ค้นหา issue ที่มีอยู่แล้วเรียบร้อย
          required: true

กฎง่าย ๆ คือ: ใช้ classic Markdown เมื่อคุณต้องการความยืดหยุ่นแบบอิสระ และใช้ Issue Forms เมื่อข้อมูลที่สม่ำเสมอและถูกตรวจสอบสำคัญกว่า

ตัวอย่างการใช้งานจริง

Bug Reports พร้อมข้อมูลสภาพแวดล้อม

กรณีคลาสสิกที่สุด input สำหรับเวอร์ชันที่มีปัญหา, textarea สำหรับขั้นตอนการทำซ้ำ, dropdown สำหรับระบบปฏิบัติการ และ checkbox "ค้นหา issue ที่มีอยู่แล้ว" แบบ required เปลี่ยนช่องทางที่ยุ่งวุ่นวายที่สุดของคุณให้เป็นรายงานที่ triage ได้จาก labels เพียงอย่างเดียว

Feature Requests ที่นำไปทำต่อได้

ถามถึงปัญหา ไม่ใช่เฉพาะทางแก้: textarea สำหรับ use case, dropdown ว่าความต้องการเกิดบ่อยแค่ไหน และ input สำหรับวิธีแก้ชั่วคราวที่เคยลอง แบบนี้กรองสัญญาณรบกวนและให้ roadmap ของคุณได้บริบทที่ใช้งานจริง

เรื่องร้องเรียนเกี่ยวกับเอกสารประกอบ

เอกสารประกอบอยู่ใน repository แล้วในทุกวันนี้ จึงสมควรได้ template ของตัวเองด้วย ฟิลด์สำหรับ URL ของหน้า, หัวข้อที่ผิด, ข้อความจริงเขียนว่าอะไรเทียบกับควรเขียนว่าอะไร และ checkbox "ตรวจสอบเวอร์ชันล่าสุดแล้ว" ช่วยให้การแก้เอกสารยังคงเล็กและกระชับ

รับเรื่องแบบ Support และ Triage

ทีมที่ใช้ issue เป็นคิว support สามารถสร้าง template แยกสำหรับคำถาม เหตุการณ์ฉุกเฉิน และคำขอสิทธิ์การเข้าถึง พร้อม dropdown สำหรับความเร่งด่วนและ component เมื่อมี labels การแบ่งงานแต่ละรายการจะเสร็จก่อนที่ใครจะได้อ่านด้วยซ้ำ

แนวทางปฏิบัติที่ดี

• ใช้ฟิลด์ required ให้น้อยที่สุด ทำเครื่องหมายเฉพาะสิ่งที่ maintainer จำเป็นต้องรู้จริง ๆ — โดยทั่วไปคือ summary และขั้นตอนการทำซ้ำ ทุกฟิลด์ required ที่เพิ่มขึ้นยิ่งทำให้คนทิ้งฟอร์มกลางทางมากขึ้น
• ใช้ dropdown สำหรับค่าที่คุณรู้แล้ว เวอร์ชัน แพลตฟอร์ม และ component ควรเป็นรายการตัวเลือกตายตัว คำตอบแบบข้อความอิสระอย่าง "น่าจะ v2 มั้ง?" แย่กว่าไม่มีเลย
• ทดสอบฟอร์มจากมุมมองของผู้รายงาน เปิด issue จริงจาก branch ทดลอง ตรวจดูลำดับการอ่านและการแสดงผลบนมือถือ ไม่ใช่แค่ความถูกต้องของ YAML
• เขียน label ให้เป็นคำถาม "คุณคาดหวังให้เกิดอะไรขึ้น?" ให้คำตอบที่ดีกว่า "Expected behavior" อยู่เสมอ
• ปิด blank issues ตั้ง blank_issues_enabled: false ใน config.yml เพื่อไม่ให้มีอะไรหลุดเลี่ยงโครงสร้างที่คุณสร้างไว้
• ปรับปรุงจาก submission จริง ถ้าผ่านไปหนึ่งเดือนแล้ว issue ยังต้องถามเพิ่มบ่อยอยู่ แสดงว่าควรเข้มฟิลด์ตัวไหนสักตัวขึ้นมา

พร้อมจัดระเบียบกล่อง issue ของคุณหรือยัง?

เปิด GitHub Issue Template Generator สร้างฟอร์มที่เหมาะกับโปรเจกต์ของคุณ แล้ว commit ไปพร้อมกับไฟล์ตั้งค่า repository ของคุณ เครื่องมือนี้ทำงานร่วมกับเครื่องมือด้านล่างนี้ได้อย่างเป็นธรรมชาติ

เครื่องมือที่เกี่ยวข้อง

• GitHub Actions Workflow Generator — สร้าง workflow สำหรับ CI และ automation พร้อม YAML ที่ commit ได้ทันที
• Markdown Preview — render และตรวจทานไฟล์ Markdown รวมถึงเนื้อหา template ก่อน commit
• YAML Formatter — จัดรูปแบบและตรวจสอบ YAML ที่ template และ workflow ของคุณพึ่งพา

ทำให้การรับเรื่องเป็นมาตรฐานเดียวกัน เคารพเวลาของ contributor และปล่อยให้ทุก bug report มาถึงพร้อม triage ได้ทันที

คำถามที่พบบ่อย

ถ: ควรวางไฟล์ที่สร้างไว้ที่ไหนใน repository?

ตอบ: ภายใต้ .github/ISSUE_TEMPLATE/ ที่รากของ repository — ตัวอย่างเช่น bug_report.yml สำหรับ Issue Form หรือ feature_request.md สำหรับ classic template commit ลง default branch แล้ว GitHub จะหยิบไปแสดงบนหน้า "New issue" ทันที

ถ: classic template กับ Issue Forms ต่างกันอย่างไร?

ตอบ: classic template เป็นไฟล์ Markdown ที่มี YAML front matter (name, about, labels, title prefix) และเนื้อหาแบบอิสระที่ผู้รายงานแก้ไขเองด้วยมือ ส่วน Issue Forms เป็น YAML ที่มีโครงสร้างซึ่ง GitHub render เป็นตัวควบคุมฟอร์มจริง — input, textarea, dropdown, checkboxes — พร้อม validation ของฟิลด์ required ที่บล็อก issue ที่กรอกไม่ครบ

ถ: ทำให้ฟิลด์ไหนบังคับกรอกได้ไหม?

ตอบ: ได้ เพิ่มบล็อก validations พร้อม required: true ให้ฟิลด์ใดก็ได้ใน Issue Forms แล้ว GitHub จะปฏิเสธการสร้าง issue จนกว่าฟิลด์นั้นจะถูกกรอก โดยเครื่องมือนี้สลับตัวเลือกนี้ต่อฟิลด์ด้วย checkbox

ถ: เครื่องมือนี้อัปโหลด template ของฉันขึ้นเซิร์ฟเวอร์ไหม?

ตอบ: ไม่ เครื่องมือทำงานฝั่งไคลเอนต์ (client-side) ทั้งหมดในเบราว์เซอร์ของคุณ นิยามฟิลด์และ YAML ที่สร้างได้ไม่เคยออกจากเครื่องของคุณ ไม่ต้องมีบัญชี และการร่าง template สำหรับ private repository ก็ปลอดภัยอย่างสมบูรณ์