Ubah pesan Slack menjadi issue GitHub, dan menjadi perbaikan
Jelaskan bug dengan bahasa biasa di Slack. Zero menulis issue GitHub dan menugaskannya, dan ketika penyebabnya ada di satu komponen ia membuka pull request berisi perbaikan dan tes regresi untuk Anda review.
Yang Zero hasilkan: dari pesan Slack sampai perbaikan yang menunggu review
Thread asli dari channel #bug-report tim vm0, apa adanya. Seorang rekan menempelkan laporan pelanggan dan meminta perbaikannya. Empat menit kemudian Zero sudah membuat issue GitHub lengkap dengan diagnosisnya. Empat belas menit setelah pesan pertama, pull request-nya terbuka dan tautan preview sudah ada di thread. Di bawah ini kedua tangkapannya: thread tempat semuanya bermula, dan pull request yang ditulis Zero. Keduanya publik, jadi Anda bisa membaca sendiri issue, diff, dan review-nya.
Yang terjadi di thread
Seorang rekan melaporkan bug layout PWA yang dialami pelanggan di #bug-report beserta tangkapan layarnya. Zero membaca thread-nya, melacak penyebabnya ke bar atas yang dirender tanpa safe area inset iOS, lalu membuat issue #11708 dengan label dan alasannya. Ketika perbaikan diminta di thread, Zero mengubah satu berkas saja (tinggi minimum dan padding safe area pada bar atas mobile), membuka pull request #11709 dengan tautan preview, lalu berhenti di situ. Review dan merge dilakukan manusia.
- Dari pesan ke issue
- 4 mntissue #11708, label bug dan PWA
- Dari pesan ke pull request
- 14 mntPR #11709 dengan tautan preview
- Berkas yang diubah perbaikan
- 1di-merge manusia, bukan Zero
Apa artinya membuat issue GitHub dari Slack?
Membuat issue GitHub dari Slack berarti mengubah bug yang dijelaskan seseorang di percakapan menjadi issue yang tertata rapi di repositori Anda, tanpa siapa pun perlu keluar dari utas untuk mengetik ulang. Bagian sulitnya tidak pernah panggilan API: yang sulit adalah menulis judul yang jelas, memisahkan langkah reproduksi dari perilaku yang diharapkan, memilih label, menetapkan prioritas, dan menemukan orang yang tepat. Zero mengerjakan bagian itu. Ia membaca pesan Slack beserta balasan di sekitarnya, menulis isi issue, menerapkan label dan prioritas yang bisa ia pertanggungjawabkan, menentukan penanggung jawab dengan mencocokkan nama tampilan Slack ke handle GitHub, lalu membalas di utas yang sama dengan tautan issue supaya pelapor bisa langsung memeriksanya.
Mengapa laporan bug hilang di utas Slack
Seseorang menemukan bug saat demo, atau pelanggan menulis di hari Sabtu. Jalur lamanya panjang: buka GitHub, cari repositorinya, tulis issue yang rapi, tugaskan ke seseorang, lalu tunggu orang itu mengambilnya, membaca kode, dan menulis perbaikannya. Perubahan sepuluh menit berubah menjadi bolak-balik berhari-hari melewati tiga orang, dan separuh laporan tidak pernah keluar dari utas. Sebagai gantinya, jelaskan saja di Slack. Zero membuat issue lengkap dengan langkah reproduksi, label, dan penanggung jawab, dan bila penyebabnya terbatas ia lanjut membuka pull request berisi perbaikan dan tes. Anda tinggal review dan rilis.
Cara Zero membuat issue GitHub dari Slack
Langkah 1: Hubungkan alat Anda
Langkah 2: Tanya Zero
Langkah 3: Lanjutkan lebih jauh
Integrasi Slack dan GitHub di balik alur ini
Ini integrasi Slack dengan GitHub dengan agen di tengahnya: Zero membaca percakapan di Slack dan menulis catatannya di GitHub. Setiap konektor diberikan terpisah dan dibatasi pada apa yang benar-benar dipakai alur ini, jadi membaca sebuah kanal tidak pernah berarti akses tulis ke repositori Anda.
Integrasi Slack: percakapan yang Zero baca
WajibZero membaca pesan yang Anda tunjuk beserta balasan di sekitarnya, sehingga konteks yang baru muncul tiga pesan kemudian tetap masuk ke issue. Ia membawa serta tangkapan layar yang dilampirkan, membaca nama tampilan pelapor untuk menentukan penanggung jawab, dan menyimpan permalink pesan sehingga setiap issue menautkan kembali ke tempat laporan bermula. Yang ia tulis hanya satu: balasan di utas yang sama berisi nomor dan tautan issue. Zero tidak memposting ke kanal lain, tidak mengirim pesan langsung, dan tidak menyunting pesan siapa pun.
Integrasi GitHub: issue yang Zero buat
WajibZero membuat issue di repositori yang Anda sebut, dengan judul yang ditulis dari laporan alih-alih salinan pesan mentah, plus deskripsi, langkah reproduksi, perilaku yang diharapkan, dan area terdampak bila utasnya menyebutkan. Ia menerapkan label yang Anda tentukan atau menyimpulkannya dari redaksi pesan, menetapkan prioritas yang ia jelaskan, dan menugaskan pemiliknya. Sebelum membuat, ia menelusuri issue terbuka untuk gejala yang sama dan berkomentar di issue yang ada bila menemukan kecocokan. Ketika ia juga bisa memperbaiki bug-nya, ia mendorong sebuah branch dan membuka pull request yang menutup issue itu serta meminta review. Akses tulis dibatasi pada repositori yang Anda izinkan, dan itu seluruh permukaannya: issue, komentar, dan pull request yang dibuka untuk direview. Zero tidak melakukan merge, tidak force push, dan tidak menyentuh pengaturan repositori.
Zero vs. aplikasi GitHub untuk Slack vs. pembuat otomatisasi
Membawa bug dari pesan Slack ke GitHub punya tiga bagian: menangkap laporannya, menulis issue yang bisa dipakai, dan mengarahkannya ke penanggung jawab. Opsi yang ada menyelesaikan satu bagian masing-masing.
Aplikasi GitHub untuk Slack
Mengetik /github membuka dialog tempat Anda sendiri mengisi judul, isi, label, dan penanggung jawab. Itu menghemat perjalanan ke browser, tetapi Anda tetap yang menulis issue-nya, dan formulir di tengah percakapan justru gesekan yang membuat orang berkata “nanti saja saya laporkan”.
Pembuat otomatisasi
Alat no-code bisa menyalin pesan Slack menjadi issue baru lewat pemicu. Yang disalin adalah pesan mentah, jadi issue-nya mewarisi apa pun yang kebetulan diketik pelapor, dan aturan label, prioritas, penugasan, serta duplikat harus Anda tetapkan dan rawat sendiri per kanal.
Alur Slack-ke-GitHub milik Zero
Zero membaca utasnya dan menulis issue: judul yang sesungguhnya, langkah reproduksi yang terpisah dari perilaku yang diharapkan, label dan prioritas yang bisa ia pertanggungjawabkan, serta penanggung jawab yang dicocokkan dari nama tampilan pelapor. Ketika penyebabnya terbatas pada satu komponen, ia lanjut membuka pull request berisi perbaikan dan tes regresi, tertaut ke issue-nya dan menunggu review Anda. Ia memeriksa issue terbuka lebih dulu dan berkomentar pada duplikat alih-alih membuatnya, lalu membalas di utas dengan tautannya.
Tips untuk hasil yang lebih baik
Pertanyaan yang sering diajukan
Bagaimana cara membuat issue GitHub dari pesan Slack?
Hubungkan Slack dan GitHub ke Zero, jelaskan bug-nya di kanal, lalu sebut Zero. Ia membaca pesan dan balasan di sekitarnya, menulis issue dengan judul, langkah reproduksi, perilaku yang diharapkan, label, dan prioritas, membuatnya di repositori yang Anda sebut, menugaskan pemiliknya, dan membalas di utas dengan nomor serta tautannya. Anda tidak mengisi formulir.
Apa bedanya dengan aplikasi GitHub untuk Slack?
Aplikasi GitHub memberi Anda dialog untuk diisi: judul, isi, label, dan penanggung jawab Anda tulis sendiri. Zero menuliskannya dari percakapan, memeriksa issue dengan gejala yang sama sebelum membuat, dan bisa menjalankan satu kanal penuh secara terjadwal, bukan satu pesan setiap kali.
Apakah Zero hanya membuat issue, atau bisa memperbaiki bug-nya?
Keduanya, dan ia memberi tahu mana yang ia lakukan beserta alasannya. Issue selalu ia buat. Bila utas atau kode menunjuk satu komponen, perilaku yang diharapkan tidak ambigu, dan tes yang gagal bisa ditulis lebih dulu, ia juga membuka pull request berisi perbaikan dan tes itu, menautkannya ke issue, dan meminta review. Utilitas bersama, token desain, dan apa pun yang butuh keputusan produk dilaporkan, bukan diubah. Zero tidak pernah melakukan merge; setiap perbaikan datang sebagai pull request yang Anda review.
Bisakah Zero menugaskan issue ke orang yang tepat secara otomatis?
Bisa. Zero mencocokkan nama yang Anda sebut, atau nama tampilan Slack pelapor, dengan handle GitHub di repositori lalu menugaskan issue-nya. Menyebut penanggung jawab di pesan Anda adalah cara paling andal; bila tidak ada yang disebut, Zero beralih ke pemilik area yang ditunjuk utas dan mencatat di issue bagaimana ia memutuskan.
Bagaimana Zero menghindari issue GitHub ganda?
Sebelum membuat apa pun, Zero menelusuri issue terbuka untuk gejala, area terdampak, dan redaksi yang sama. Bila cocok, ia menambahkan utas Slack baru sebagai komentar di issue itu, lengkap dengan pelapor dan waktunya, lalu membalas di Slack dengan tautan issue yang sudah ada alih-alih membuka yang kedua.
Apa yang terjadi bila laporan bug tidak punya langkah reproduksi?
Zero tetap membuat issue-nya supaya laporan tidak hilang, memberi label bahwa langkah reproduksi masih dibutuhkan, dan membalas di utas Slack untuk memintanya. Jawabannya lalu mendarat di utas yang memang sudah tertaut dari issue.
Bisakah Zero membuat issue dari satu kanal penuh secara terjadwal?
Bisa. Arahkan Zero ke satu kanal atau lebih dan beri jadwal, misalnya setiap Jumat pukul 16.00. Ia membaca pesan sepekan, membuat issue untuk setiap pesan yang menjelaskan cacat, berkomentar pada duplikat, melewati permintaan fitur dan pertanyaan, lalu melaporkan apa yang ia kerjakan.
Apakah ini bekerja dengan Linear atau Jira, bukan GitHub?
Bentuk alur yang sama berlaku untuk pelacak mana pun yang terhubung ke Zero; halaman ini membahas jalur GitHub, yang memakai konektor GitHub. Linear dihubungkan dengan cara yang sama, dan pelacaknya Anda sebut di dalam instruksi.
Laporkan bug berikutnya tanpa keluar dari Slack
Hubungkan Slack dan GitHub, jelaskan bug-nya seperti Anda bercerita ke rekan kerja, dan biarkan Zero menulis issue-nya dan menugaskannya. Kalau penyebabnya terbatas, pull request-nya juga sudah menunggu Anda.