GitHub Projects dan Discussions

Tiga ruangan dalam satu rumah

Bayangkan GitHub sebagai sebuah rumah kontrakan yang dihuni timmu. Di rumah itu ada tiga ruangan dengan fungsi berbeda, dan kekacauan dimulai saat orang salah masuk ruangan. Issues adalah ruang kerja: tempat tugas konkret dicatat, "tombol login error di HP Android", lengkap dengan siapa yang mengerjakan dan kapan deadline-nya. Discussions adalah ruang tamu: tempat ngobrol santai, tanya-jawab, dan lempar ide yang belum tentu jadi tugas. Projects adalah papan tulis besar di dinding: ringkasan visual ke mana semua tugas bergerak, dari "baru" ke "dikerjakan" ke "selesai".

Kenapa pemisahan ini penting? Karena kalau semua diobrolin di Issues, daftar tugasmu akan tenggelam di lautan pertanyaan "kak, cara install-nya gimana?" Sebaliknya kalau ide bagus cuma diobrolin di chat dan tidak dicatat di mana pun, ia menguap begitu chat-nya ke-scroll jauh. Setiap ruangan punya penghuni yang tepat.

GitHub Projects: papan kanban-mu

Projects adalah alat manajemen tugas bawaan GitHub, mirip Trello tapi terhubung langsung ke repo. Kamu membuat sebuah project, memilih tampilan Board (kanban), Table, atau Roadmap, lalu mengisi kartu-kartu yang bisa ditautkan ke Issues dan PR. Kartu yang ditautkan ke PR akan bergerak otomatis: misalnya PR di-merge, kartunya pindah sendiri ke kolom Done. Itu sihir kecil yang menghemat banyak update status manual.

Alur tipikal untuk tugas sekolah atau proyek kecil: buat kolom Todo, In Progress, dan Done. Setiap tugas (misalnya "bikin halaman login") dibuat sebagai issue, lalu ditambahkan ke project dan ditaruh di Todo. Saat mulai dikerjakan, geser ke In Progress. Saat PR-nya merge, ia melompat sendiri ke Done. Dalam satu pandangan kamu tahu persis siapa mengerjakan apa dan apa yang macet.

Contoh konkret: tim tiga orang membuat aplikasi kasir warung. Issue "struk tidak tercetak" masuk kolom Todo hari Senin. Budi mengambilnya, geser ke In Progress. Ia buka PR "fix: cetak struk", PR di-review dan di-merge hari Rabu, kartu otomatis pindah ke Done. Tanpa rapat status, semua orang bisa melihat progres itu kapan saja.

Discussions: ruang tamu yang tertib

Discussions adalah forum terstruktur di dalam repo, dengan kategori seperti Q and A, Ideas, Polls, dan Announcements. Bedanya dengan Issues: Discussions tidak menuntut aksi. "Menurut kalian warna tombolnya bagusan ungu atau hijau?" adalah Polls yang sempurna, sementara "tombolnya tidak bisa diklik di Safari" adalah Issue yang menuntut perbaikan.

Kapan memakai Discussions? Tiga momen paling pas: pertama, pertanyaan yang jawabannya berguna untuk banyak orang (Q and A bisa ditandai "answered" sehingga jadi dokumentasi). Kedua, ide mentah yang butuh digodok dulu sebelum layak jadi tugas ("gimana kalau aplikasinya bisa mode offline?"). Ketiga, pengumuman ke komunitas, misalnya "versi 2.0 rilis minggu depan".

Analoginya begini: Issues itu seperti daftar belanja yang ditempel di kulkas, setiap baris harus dicoret setelah dibeli. Discussions itu seperti obrolan di meja makan: boleh serius, boleh santai, tidak semua harus berujung belanja. Kalau daftar belanjamu penuh coretan obrolan meja makan, kamu tidak akan pernah tahu apa yang benar-benar harus dibeli.

Kapan pakai yang mana

Aturan jempolnya sederhana. Ada bug, tugas, atau pekerjaan dengan definisi selesai yang jelas? Buat Issue, lalu pantau di Projects. Ada pertanyaan, ide, jajak pendapat, atau pengumuman? Buka Discussion. Mau melihat gambaran besar progres tim? Buka Projects.

Hubungan ketiganya juga fleksibel: Discussion yang matang bisa diubah menjadi Issue ("ide mode offline ini ternyata feasible, jadikan tugas"), dan Issue yang ternyata cuma pertanyaan bisa dipindah. GitHub menyediakan tombol convert untuk itu, jadi tidak perlu takut salah pilih di awal.

Kesalahan umum pemula

Salah: membuka Issue untuk bertanya "cara pakai API ini gimana?", lalu maintainer menutupnya dengan "bukan bug, tanya di Discussions". Kamu membuang waktu dua belah pihak dan menumpuk issue tracker dengan non-tugas. Benar: pertanyaan ke Discussions kategori Q and A. Issue hanya untuk hal yang butuh dikerjakan dan diselesaikan.

Salah: mengelola tugas tim lewat chat grup saja ("eh kemarin siapa yang kerjain X?"), lalu tidak ada yang ingat status masing-masing tugas seminggu kemudian. Benar: tiap tugas jadi Issue yang masuk Projects. Chat untuk koordinasi cepat, Projects untuk kebenaran status. Kalau informasinya cuma ada di chat, ia tidak ada di mana-mana.

Salah: membuat Projects tapi tidak pernah mengupdate kartunya, sehingga papan kanban menampilkan kebohongan yang rapi: semua "In Progress" padahal sudah selesai sebulan lalu. Benar: tautkan kartu ke Issue/PR agar status bergerak otomatis, atau jadikan update papan sebagai ritual singkat tiap standup. Papan yang tidak dipercaya lebih buruk daripada tidak punya papan.