Deskripsi PR yang membuat reviewer cepat paham
Reviewer membaca deskripsi PR sebelum membaca kodenya, jadi deskripsi yang baik menghemat waktu semua orang. Jawab tiga hal: apa yang berubah, kenapa perubahan itu perlu, dan bagaimana cara mengujinya. Tambahkan Closes #<nomor> agar issue-nya otomatis tertutup saat PR di-merge, dan sertakan tangkapan layar bila perubahannya terlihat di antarmuka. PR yang deskripsinya kosong hampir selalu lebih lama menunggu review, karena reviewer harus menebak sendiri maksudnya.
👀 Contoh dulu
## Apa Menambahkan filter kategori di halaman katalog. ## Kenapa Pengguna harus scroll 200+ produk untuk menemukan satu kategori (BIL-17). ## Cara uji 1. Buka /katalog 2. Pilih kategori Minuman 3. Pastikan hanya produk minuman yang tampil Closes #17
Hasilnya: Deskripsi tampil di halaman PR GitHub; issue #17 otomatis tertutup saat PR di-merge.
💡 Bagian 'Cara uji' adalah yang paling sering dilupakan, padahal itu yang paling menghemat waktu reviewer.
📝 Sekarang giliranmu
Tulis deskripsi PR untuk perbaikan tombol checkout (tiket BIL-42, GitHub issue nomor 42). Wajib ada tiga heading Markdown tingkat dua: Apa, Kenapa, Cara uji — masing-masing dengan isi — dan diakhiri penanda agar issue 42 tertutup otomatis.