GitHub pada 17 Juni merilis fitur yang membatasi jumlah PR terbuka secara bersamaan dari pengguna tanpa izin tulis. Fitur ini muncul setelah banyak cerita tentang maintainer yang kewalahan menghadapi PR berkualitas rendah yang dibanjiri AI, dan ini juga merupakan hal yang sudah diminta sejak 2016.
Jadi saya mencoba mengukur seberapa banyak yang benar-benar tersaring di antrean repositori nyata. Dengan mengecualikan bot, dan hanya menghitung PR yang dibuka oleh penulis tanpa izin tulis, saya menghitung berapa banyak yang akan tertunda jika batasnya ditetapkan ke 3.
- huggingface/transformers — 55 PR terbuka / 49 penulis / 1 PR akan tertunda oleh batas 3
- typescript-eslint — 28 / 24 / 1
- DIYgod/RSSHub — 26 / 23 / 1
- django/django — 79 / 59 / 7
- caddyserver/caddy — 58 / 43 / 7
- coollabsio/coolify — 86 / 68 / 11
Hasilnya 2–13%.
Alasannya adalah bentuk antreannya. Di transformers, 55 PR datang dari 49 penulis. Di coolify, 86 PR dari 68 penulis. Polanya bukan satu orang membuka tiga puluh PR sebagai spam, melainkan tiga puluh orang masing-masing membuka satu PR. Batas ini dibuat untuk menargetkan pola pertama, tetapi antrean nyata lebih sering seperti yang kedua.
Bukan berarti fiturnya tidak berguna. Repositori yang antreannya dibanjiri satu akun memang benar-benar ada, dan sebelumnya tempat seperti itu tidak punya cara bertahan. Hanya saja, jumlah yang sampai ke reviewer hampir tetap sama, dan pekerjaan menentukan apa yang harus dibaca lebih dulu tetap ada.
Ada satu hal lain yang saya ukur bersama ini. Saya mencari 167 repositori yang memasang action untuk menutup PR berkualitas rendah secara otomatis, dan di 30 repositori yang antreannya masih aktif, semuanya memiliki pull_request_creation_policy bernilai all. Memang itu nilai default, jadi artinya “tidak ada yang mengubahnya”, tetapi ini juga berarti kelompok yang motivasinya paling kuat untuk membatasi justru tidak menutup pintu, melainkan hanya memasang filter.
Dan dari 167 repositori itu, 126 (75%) memiliki kurang dari 4 PR terbuka. Artinya, “N repositori memasang filter slop” tidak boleh dibaca sebagai “N repositori sedang mengalami banjir”. Saya sendiri sempat membacanya begitu, lalu mengukurnya ulang dan merevisi kesimpulan.
Metode pengukuran dan keterbatasannya ada di dokumen yang ditautkan. Batas 3 adalah asumsi saya (setiap repositori mengaturnya berbeda), dan karena ini adalah snapshot antrean terbuka, PR yang sejak awal tidak sempat dibuka karena terblokir batas tidak terlihat — padahal itu juga salah satu inti fitur ini. Selama ada daftar PR publik, siapa pun bisa mereproduksinya.
(Pengungkapan: pengukuran ini berasal dari checker triase PR yang saya buat. Artinya ada kepentingan saya di sini, jadi mohon dibaca dengan mempertimbangkan hal itu, dan angkanya bisa direproduksi apa adanya dari daftar PR publik tiap repositori.)
Belum ada komentar.