Alasan pengguna tidak bisa membuat Issue secara langsung

• Repositori Ghostty tidak mengizinkan pengguna membuat Issue secara langsung, dan diskusi harus dimulai terlebih dahulu di GitHub Discussions
• Proyek ini tidak menggunakan pelacak Issue untuk diskusi bug atau permintaan fitur, dan semua pembahasan dilakukan di Discussions
• Jika diskusi sudah cukup matang dan dirangkum menjadi item yang dapat ditindaklanjuti, maintainer akan mengubahnya menjadi Issue
• Pendekatan ini merupakan struktur yang membantu maintainer dan kontributor lebih cepat menemukan issue yang benar-benar bisa dikerjakan
• Karena sebagian besar laporan adalah masalah lingkungan pengguna, kesalahpahaman, atau permintaan fitur yang belum diimplementasikan, prosedur ini penting untuk menjaga kualitas proyek

---

Kebijakan pembatasan pembuatan Issue

• Di repositori Ghostty, pengguna tidak dapat membuat Issue secara langsung
  • Sebagai gantinya, pengguna harus lebih dulu membagikan masalah atau usulan di GitHub Discussions
  • Maintainer akan meninjau diskusi dan mengubahnya menjadi Issue jika terbukti sebagai masalah yang dapat direproduksi dengan jelas
• Pendekatan ini bertujuan menjaga agar pelacak Issue hanya berisi item yang benar-benar dapat dikerjakan
  • Karena semua Issue sudah dalam keadaan terdefinisi dengan jelas, kontributor bisa langsung mulai mengerjakannya

Prinsip pengelolaan pelacak Issue

• Ghostty tidak menggunakan pelacak Issue untuk diskusi atau permintaan fitur
  • Permintaan fitur atau pertanyaan umum ditangani di Discussions
  • Issue hanya berisi bug yang didefinisikan dengan jelas atau item kerja yang dapat ditindaklanjuti
• Pendekatan ini adalah prinsip operasional yang dibentuk dari pengalaman memelihara proyek open source
  • Berdasarkan pengalaman sebelumnya, 80~90% laporan pengguna ternyata bukan bug nyata, melainkan kesalahpahaman atau masalah lingkungan
  • Sebagian besar sisanya adalah permintaan fitur yang belum diimplementasikan, yang sering kali masih memerlukan spesifikasi tambahan

Meningkatkan efisiensi maintainer

• Dengan melalui tahap Discussions, maintainer hanya perlu mengelola masalah yang sudah tervalidasi sebagai Issue
  • Mengurangi laporan duplikat yang tidak perlu atau bug report yang keliru
  • Daftar Issue menjadi lebih terfokus pada item yang bisa langsung dikerjakan
• Pengguna tidak perlu melakukan pekerjaan tambahan meski menemukan masalah yang valid
  • Maintainer akan langsung mengubahnya menjadi Issue dan menanganinya

Dokumen referensi

• Prosedur rinci dan panduan kontribusi dapat dilihat di file CONTRIBUTING.md
• Dokumen tersebut menjelaskan cara berpartisipasi di Discussions dan kriteria perubahan menjadi Issue

[GN⁺]

Pendapat Hacker News

• 100% setuju. Jika itu proyek orang lain, wewenang untuk menilai issue sepenuhnya ada pada mereka
  Semakin besar proyeknya, semakin banyak orang yang tidak membaca pesan, membuat permintaan aneh, bahkan ada yang membesar-besarkan CVE dengan AI

  • Saya benar-benar tidak paham dengan orang yang tidak membaca pesan error
    Walaupun pengguna tidak tahu arti error-nya, setidaknya mereka harus memberi tahu error apa yang muncul
    Dulu saat pengujian saya secara jelas menyebut “broken pipe error”, tetapi engineer menutupnya dengan alasan “tidak bisa direproduksi”, lalu bilang tidak bisa mereproduksi justru karena error yang sama
  • Github Issues punya keterbatasan sebagai bug tracker
    Kebanyakan tracker bisa mengelompokkan status seperti “unconfirmed”, tetapi Github hanyalah sistem diskusi sederhana sehingga sulit dikelola
  • Saya pernah menerima laporan CVE tepat setelah ChatGPT dirilis
    Selama 4 jam saya membantahnya sambil menunjukkan kode dan bukti, tetapi balasan yang datang cuma “shrugs AI”
  • Banyak pengguna hanya ingin hasil tanpa punya waktu untuk mempelajari cara memakai alat dengan benar
    “Facebookization” menciptakan anggapan bahwa semuanya bisa selesai hanya dengan beberapa klik, dan sekarang dengan “LLMization” sepertinya itu akan makin parah
    Pendekatan seperti ini tidak cocok untuk software profesional, tetapi ekspektasinya sudah telanjur terbentuk
  • Issue tracker yang baik seharusnya punya fitur untuk menyaring noise seperti ini
    Ghostty mengelompokkan permintaan lewat diskusi memang unik, tetapi ini pendekatan yang efektif

• Investigasi memory leak tersebar di beberapa platform
  Link X 1, Link X 2, Diskusi 1, Diskusi 2
  Belum dinaikkan menjadi issue resmi

  • Saya berhenti memakai Ghostty karena memory leak
    Bahkan di sistem 8GB, hanya dengan menjalankan terminal beberapa kali saja sudah terjadi kehabisan memori
    Foot memang fiturnya lebih sedikit, tetapi jauh lebih stabil
  • Menurut link pertama, penulis mengatakan masalah ini baru dilaporkan dua kali
    Link kedua terlihat hanya sebagai upaya untuk memicu perdebatan
  • Saya juga melaporkan masalah ini di diskusi, tetapi tidak ada respons
    Saya menganalisis log dengan Claude Code dan memperbaikinya sementara, dan sekarang hanya muncul lagi sekitar 1 dari 10 kali
    Semoga ini membantu saat ada orang lain yang menyelidikinya lebih lanjut
  • Kompatibilitas GPU juga rumit
    Bahkan di GPU terintegrasi pun bisa muncul masalah, tetapi selalu disalahkan ke GTK atau Nvidia
  • Tampaknya para kontributor menilai kondisi reproduksi yang jelas masih kurang, jadi belum diangkat menjadi issue

• Saya rasa pembedaan antara “Issues” dan “Discussions” itu tidak efisien
  Harus mencari duplikasi di dua tempat, dan tiket juga tidak bisa dipindahkan
  Jika follow-up lewat email, notifikasinya malah terputus
  Karena itu, di proyek saya Discussions saya matikan

  • Discussions berguna sebagai tempat untuk pertanyaan sederhana atau masalah instalasi
    Jika ternyata memang bug sungguhan, barulah diubah menjadi issue
  • Proses seperti ini sebenarnya juga bisa dibuat dengan sistem label
    Cukup admin yang menambahkan label “bug”
  • Pemeriksaan duplikasi tidak diperlukan
    Setelah diskusinya rapi, barulah issue dibuat
  • Sebenarnya issue dan diskusi bisa saling dikonversi
    Notifikasinya juga tetap dipertahankan
  • Seperti struktur Ghostty, saya rasa pemisahan di mana siapa pun bisa membuka Discussions, sedangkan Issues dikelola admin adalah pemisahan yang masuk akal

• Beberapa proyek besar di komunitas Python juga memakai cara seperti ini
  Tetapi dari sudut pandang power user, proses pelaporan bug terasa merepotkan
  Sikap yang seolah berkata “proyek kami sempurna” terasa arogan

  • Keluhan seperti ini sulit dipahami
    Kebanyakan drive-by bug report tidak berguna, malah hanya jadi noise
    Jika benar-benar ingin berkontribusi, lebih baik memperbaiki bug yang sudah didefinisikan
  • Arogan? Justru mereka adalah orang-orang yang secara gratis menginvestasikan waktu dan tenaga
    Wajar kalau mereka membatasi cara pelaporan
  • Kalau Anda sesering itu menemukan bug, mungkin bagus juga untuk ikut terlibat langsung dalam proyeknya
  • Sebaliknya, keyakinan diri bahwa “ini jelas bug” juga bisa menjadi bentuk arogansi tersendiri
  • Apakah membuka diskusi benar-benar lebih merepotkan daripada membuka issue? Saya kurang yakin

• Menanggapi klaim bahwa “semua issue harus berada dalam kondisi siap dikerjakan”,
  muncul pertanyaan, “kalau begitu kenapa tidak cukup diberi tag ‘ready-to-be-worked-on’?”

  • Namun Github tidak bisa mengatur tampilan default ke “triage”, dan pada proyek besar pengelolaan issue menjadi tidak efisien
    Sistem ini jauh lebih berhasil
  • Cara berbasis tag memerlukan beberapa putaran feedback sehingga detailnya tersebar di komentar
  • Jika semua orang dibiarkan berkomentar, akan muncul noise yang tidak perlu
    Karena itulah ruang khusus developer dan ruang pengguna dipisahkan
  • Issue yang salah meskipun ditutup bisa dibuka kembali, sehingga pada akhirnya daftar issue menjadi tak terkendali
  • Tidak perlu memaksa alur kerja orang lain dengan berkata “kenapa cara saya lebih baik”

• Issues itu tidak bisa dikelola saat skalanya membesar
  Memakai Discussions sebagai filter itu efisien

  • Tetapi pada akhirnya maintainer tetap harus membaca dan mengelompokkan semua kiriman, jadi beban kerjanya mirip
    Kedua fitur GitHub itu UI-nya hampir sama
    Hanya saja Discussions punya fitur upvote
  • Ada juga tanggapan sinis seperti, “bukankah akan lebih efisien kalau semua issue otomatis ditutup setelah 2 minggu saja?”
  • Proyek besar seperti Curl pun hanya punya 5 issue terbuka
    curl/curl/issues

• Ada juga pendapat bahwa cara ini seharusnya menjadi pengaturan default
  Struktur idealnya adalah komunitas menangani diskusi, dan kontributor menangani issue

  • Tetapi ini pada dasarnya hanya pemindahan proses saja, substansinya tetap sama
    Sistem label GitHub pun sebenarnya sudah cukup untuk menangani ini
    Dokumentasi pengelolaan label GitHub
  • Daripada menentukan “default”, lebih baik tiap proyek bereksperimen secara alami untuk menemukan cara yang cocok
    Seperti Natural experiment

• Saya setuju dengan kebijakan kiriman pengguna seperti ini
  Kalau melihat diskusi yang ditutup, memang mirip dengan issue yang ditutup, tetapi setidaknya noise di tab issue berkurang
  Daftar diskusi Ghostty yang ditutup

  • Semua laporan pengguna dimulai dari diskusi, lalu dipindahkan ke issue jika terbukti bug sungguhan
    Banyak diskusi tidak sampai ke tahap itu, tetapi masalah pengguna tetap terselesaikan
    Saya rasa struktur pemisahan ini adalah desain yang cukup cerdas

• Sebenarnya “tidak bisa membuka issue” itu bukan fitur GitHub,
  melainkan hanya pesan template yang mengatakan “jangan buka issue baru, gunakan Discussions”

• Saya pernah melihat cara seperti ini di proyek lain juga,
  dan struktur yang menjadikan diskusi sebagai titik awal terlihat cukup masuk akal
  Hanya saja banyak proyek masih belum mengaktifkan GitHub Discussions

[iolothebard]

Apa bedanya diskusi itu dengan issue? Issue bukanlah “bug”. Baik itu bug, usulan fitur, maupun PR… jika ada hal yang perlu didiskusikan, itu adalah issue.
Jika tidak layak untuk didiskusikan, tinggal tutup saja.

[nemorize]

Bukan karena diskusi dan issue itu berbeda, melainkan mungkin karena membaginya ke tab terpisah memang lebih sesuai dengan preferensi mereka.

Memasang semacam to-do list dan diskusi sekaligus di tab issue, lalu mengelolanya dengan tag
vs
menggunakan tab issue hanya untuk to-do list, dan diskusi hanya untuk diskusi