Template PR dan CODEOWNERS

PR tanpa deskripsi adalah PR yang menyebalkan

Setiap maintainer pernah membuka PR berisi satu baris: "fix bug". Reviewer harus menebak-nebak apa yang diperbaiki, bagaimana cara mengetesnya, dan apakah ada efek samping. Template PR menyelesaikan ini dengan cara paling murah: form isian otomatis yang muncul setiap kali seseorang membuka PR. Bukan paksaan, hanya pengingat terstruktur tentang informasi apa yang reviewer butuhkan.

Kenapa ini penting di tim? Karena kualitas review berbanding lurus dengan kualitas deskripsi. PR yang menjelaskan "apa, kenapa, dan cara test" bisa di-review dalam 10 menit; PR misterius butuh investigasi satu jam atau, lebih sering, di-approve asal-asalan karena reviewer menyerah.

Membuat PULL_REQUEST_TEMPLATE.md

Buat file .github/PULL_REQUEST_TEMPLATE.md di repo. Setiap PR baru otomatis terisi konten file ini:

## Ringkasan
<!-- Apa yang diubah dan kenapa? -->

## Cara mengetes
<!-- Langkah konkret untuk memverifikasi perubahan ini -->

## Checklist
- [ ] Test lolos (`npm test`)
- [ ] Tidak ada breaking change, atau sudah didokumentasikan

Komentar HTML (<!-- -->) tampil sebagai panduan yang hilang saat di-render, jadi penulis tinggal menghapus dan mengisi. Butuh beberapa template untuk kasus berbeda (misalnya bugfix vs fitur)? Buat folder .github/PULL_REQUEST_TEMPLATE/ berisi beberapa file markdown; GitHub menampilkan pemilih template saat membuka PR.

Template tidak memaksa siapa pun: penulis bisa menghapus semuanya. Tapi pengalaman menunjukkan form kosong yang terstruktur tetap menghasilkan deskripsi lebih baik daripada halaman kosong yang mengintimidasi.

CODEOWNERS: review otomatis ke orang yang tepat

Masalah kedua: di repo besar, siapa yang harus me-review perubahan di folder payments/? Tanpa aturan, PR menunggu berhari-hari karena tidak ada yang merasa bertanggung jawab. File CODEOWNERS (di root, docs/, atau .github/) memetakan path ke pemiliknya:

# Pemilik default untuk seluruh repo
* @tim-core

# Folder sensitif punya penjaga khusus
/payments/ @budi @siti
/docs/ @tim-dokumentasi
*.sql @dba-team

Aturan dibaca dari bawah ke atas, pola terakhir yang cocok menang, jadi aturan spesifik harus di bawah aturan umum. Saat PR menyentuh file yang cocok, GitHub otomatis meminta review dari pemiliknya. Contoh output yang akan kamu lihat di sidebar PR: "Review requested" dengan nama yang sudah terisi, tanpa penulis PR harus menebak siapa yang paham kode itu.

Mengunci dengan branch protection

Template dan CODEOWNERS menjadi benar-benar bertaji saat digabung dengan branch protection di Settings, Branches. Aktifkan "Require a pull request before merging" plus "Require review from Code Owners": PR tidak bisa di-merge sampai pemilik kode yang relevan menyetujui. Rantai lengkapnya: template memastikan PR layak dibaca, CODEOWNERS memastikan dibaca orang yang tepat, branch protection memastikan tidak ada yang lolos diam-diam.

Kesalahan umum pemula

Salah: membuat template super panjang dengan 20 checklist yang melelahkan, sehingga semua orang mengabaikannya dan menghapusnya tiap kali buka PR. Benar: template yang pendek dan relevan lebih ditaati. Tiga bagian (ringkasan, cara test, checklist singkat) cukup untuk 90 persen PR.

Salah: menulis * @budi di CODEOWNERS lalu heran kenapa semua review numpuk ke satu orang dan ia burnout. Benar: gunakan nama tim (@tim-core) bukan individu untuk kepemilikan umum, dan bagi area sensitif ke beberapa pemilik agar beban review tersebar.