Issues dan Discussions

Pull request mengantar kode, tetapi proyek yang sehat bergerak lebih dulu lewat percakapan: bug dilaporkan, usulan fitur ditimbang, pertanyaan pengguna dijawab. Tanpa wadah resmi, percakapan itu tercecer di grup chat dan utas surel — hilang tepat saat paling dibutuhkan. Platform hosting menuntaskannya dengan dua ruang berdampingan: issues sebagai pelacak pekerjaan yang bernomor dan berstatus, serta discussions sebagai forum terkategori untuk topik yang belum menjadi pekerjaan. Chapter ini membedah keduanya, lalu melatih satu jembatan yang paling sering dipakai: menutup issue otomatis lewat pesan commit.

Issues: Pelacak Pekerjaan #

Sebuah issue adalah kartu kerja bernomor: judul, deskripsi, deretan komentar, dan dua status — open hingga tuntas, closed setelahnya. Nomornya diberikan platform secara berurutan (#1, #2, …) dan menjadi identitas pendek yang bisa dirujuk dari mana saja: pesan commit, pull request, dokumentasi. Di GitHub, issues dan pull request bahkan berbagi satu urutan penomoran — kebiasaan yang kita pakai di chapter Fork dan Pull Request saat meniru pesan merge bergaya platform.

Tiga pengelompok menyusun papan kerja di atas issues. Label menandai kategori, milestone mengikat kumpulan issue ke target versi, dan assignee menunjuk penanggung jawab satu orang. Label standar yang hampir universal di proyek open source:

Label	Artinya
`bug`	perilaku tidak sesuai harapan
`enhancement`	usulan peningkatan atau fitur baru
`documentation`	perbaikan atau penambahan dokumentasi
`good first issue`	kecil, terisolasi, cocok untuk kontributor baru
`help wanted`	maintainers aktif mencari bantuan luar
`question`	pertanyaan yang ternyata bukan bug
`duplicate`	sudah dilaporkan di issue lain
`wontfix`	diputuskan tidak akan dikerjakan

Label tersebut bukan sekadar hiasan: seluruhnya menjadi filter di antarmuka platform — “tampilkan semua bug yang belum ada assignee” adalah satu klik, bukan pencarian manual. Nomor dan label juga hidup di luar platform: git log --grep="Fixes #" --oneline di terminal menemukan commit yang pernah menutup issue.

Menutup Otomatis dengan Referensi Commit #

Hubungan paling produktif antara issues dan Git adalah penutupan otomatis. Platform membaca pesan commit yang terdorong; bila menemukan nomor issue didahului kata kunci tertentu, issue itu ditutup begitu commit mencapai branch utama. Frasa-frasanya:

Frasa dalam pesan commit	Efeknya di platform
`#12`	tautan silang saja — issue tetap terbuka
`fixes #12`, `closes #12`, `resolves #12`	menutup issue #12 saat commit mencapai branch utama
`fixes budi/toko-buku#12`	bentuk lengkap lintas repository — menutup issue #12 di repo tersebut

Demo nyatanya dimulai dari repository dengan sebuah form pemesanan yang kurang validasi — dan diasumsikan issue #12 sudah dibuat di web platform tempat repository ini kelak diterbitkan (nomor diberikan platform, bukan Git):

bash
mkdir latihan-issues && cd latihan-issues
git init -b main toko && cd toko
git config user.name "Budi Santoso"
git config user.email "[email protected]"
printf 'beranda\n' > situs.md
git add situs.md
git commit -m "Buat kerangka toko"
printf 'nama pembeli: (wajib)\n' > pemesanan.md
git add pemesanan.md
git commit -m "Buat form pemesanan"
printf 'nama pembeli: (wajib)\nemail: (wajib)\n' > pemesanan.md
git add pemesanan.md
git commit -m "Perbaiki validasi form pemesanan" -m "Fixes #12"

Commit terakhir memakai dua opsi -m: yang pertama menjadi subjek, yang kedua menjadi badan pesan yang terpisah satu baris kosong — bentuk yang dianjurkan di Menulis Commit Message . Hasilnya terbaca utuh:

bash

git log -1

Output yang Dihasilkan:

text
commit 186e9f36ba7e3b17797d099cbde7b1e63190715b
Author: Budi Santoso <[email protected]>
Date:   Tue Nov 3 09:20:00 2026 +0700

    Perbaiki validasi form pemesanan
    
    Fixes #12

Subjek menjawab apa yang berubah; badan Fixes #12 menjawab issue mana yang selesai — hash di mesin pembaca berbeda, strukturnya tidak. Sandbox tidak memiliki platform, jadi tidak ada issue yang benar-benar tertutup di sini; yang diuji nyata adalah format pesannya. Saat commit ini terdorong ke platform sungguhan, perilakunya mengikuti dokumentasi platform: issue #12 ditutup, dan commit merge yang membawanya tercatat di lini masa issue sebagai penutupnya.

Issue Templates #

Laporan bug yang baik membutuhkan struktur: kronologi, versi, dan langkah mengulang — informasi yang jarang disertakan pelapor pertama kali. Issue template memaksa strukturnya: platform menawarkan formulir terstruktur ketika orang menekan tombol New issue. Template hidup sebagai berkas biasa di dalam repository, di direktori .github/ISSUE_TEMPLATE (konvensi GitHub; GitLab menyimpannya di .gitlab/issue_templates):

bash
mkdir -p .github/ISSUE_TEMPLATE
cat > .github/ISSUE_TEMPLATE/bug-report.yml <<'EOF'
name: Laporan Bug
description: Laporkan perilaku aplikasi yang tidak sesuai harapan
labels: [bug]
body:
  - type: textarea
    id: kronologi
    attributes:
      label: Kronologi kejadian
      description: Langkah-langkah untuk mengulang masalah
      placeholder: |
        1. Buka halaman pemesanan
        2. Kirim form kosong
    validations:
      required: true
  - type: input
    id: versi
    attributes:
      label: Versi aplikasi
      placeholder: v1.0.0
EOF
git add .github
git commit -m "Tambah template laporan bug"

Isi berkasnya layak dibedah pelan. name dan description tampil sebagai judul dan keterangan pilihan template; labels: [bug] otomatis menandai issue yang lahir dari formulir ini — label taxonomy di atas langsung bekerja. Bagian body merinci dua pertanyaan: textarea bernama kronologi dengan placeholder dua langkah (pelapor tinggal melanjutkan pola), dan input bernama versi. Baris validations: required: true pada pertanyaan pertama membuat formulir menolak dikirim kosong — baris yang mengubah “kronologi sering lupa ditulis” menjadi “kronologi wajib terisi”. Keberadaan berkasnya terverifikasi di direktori:

bash

ls .github/ISSUE_TEMPLATE

Output yang Dihasilkan:

text

bug-report.yml

Template ter-commit seperti berkas biasa, ikut ter-review lewat pull request, dan berlaku per branch — sekeluarga dengan perilaku .gitlab-ci.yml yang dibedah di Mengenal GitLab .

Discussions: Forum di Samping Pelacak #

Tidak semua topik adalah pekerjaan. “Bagaimana cara memakai API ini untuk kasus X?” adalah pertanyaan, bukan bug; “bagaimana kalau arsitektur proyek pindah ke plugin?” adalah diskusi arah, belum kartu kerja. Discussions menampung keduanya sebagai forum dengan kategori — tanya-jawab, pengumuman, ide, hingga pamer karya — lengkap dengan kemampuan menandai satu balasan sebagai jawaban di kategori Q&A. Maintainernya bisa memindahkan topik di antara dua dunia: issue yang ternyata pertanyaan diubah menjadi discussion, dan diskusi yang sudah matang diubah menjadi issue pertama kali disepakati.

Kebutuhan	Wadah yang tepat
Bug dan pekerjaan konkret bernomor	issues
Pertanyaan penggunaan dan pemecahan masalah	discussions (kategori tanya-jawab)
Usulan besar yang butuh pendapat sebelum jadi keputusan	discussions (kategori ide)
Pengumuman rilis dan kebijakan	discussions (kategori pengumuman)
Perbaikan kecil yang langsung dikerjakan	issues atau langsung pull request

Aturan pembedanya satu kalimat: topik yang butuh status selesai masuk issues; topik yang butuh percakapan masuk discussions.

Issues melacak pekerjaan, discussions merawat percakapan, dan keduanya terhubung ke riwayat lewat nomor. Satu bahasa rujukan platform yang tersisa menyangkut momen publik: ketika pekerjaan dikemas menjadi versi dan dibagikan ke pengguna — di situlah tag bertemu release, pokok bahasan berikutnya. Panduan lengkap fitur issues tersedia di dokumentasi GitHub tentang issues .