- Ghostty deposunda kullanıcılar doğrudan Issue oluşturamaz; önce GitHub Discussions üzerinde bir tartışma başlatmaları gerekir
- Proje, hata veya özellik isteği tartışmaları için Issue takip sistemini kullanmaz; tüm tartışmalar Discussions üzerinden yürütülür
- Tartışma yeterince netleşip eyleme dönüştürülebilir bir madde haline geldiğinde, yönetici bunu bir Issue’ya dönüştürür
- Bu yöntem, bakımcılar ve katkıda bulunanların gerçekten üzerinde çalışılabilir sorunları hızlıca bulmasına yardımcı olan bir yapıdır
- Bildirimlerin çoğu kullanıcı ortamı sorunları, yanlış anlamalar veya henüz uygulanmamış özellik istekleri olduğu için, bu süreç projenin kalite yönetimi açısından önemlidir
Issue oluşturma kısıtlama politikası
- Ghostty deposunda kullanıcılar doğrudan Issue oluşturamaz
- Bunun yerine önce GitHub Discussions üzerinde sorunlarını veya önerilerini paylaşmaları gerekir
- Yönetici tartışmayı inceleyip bunun açıkça yeniden üretilebilir bir sorun olduğunu doğrularsa bunu bir Issue’ya dönüştürür
- Bu yöntem, Issue takip sisteminin yalnızca gerçekten üzerinde çalışılabilir maddeler içermesini sağlamak için kullanılan bir yapıdır
- Tüm Issue’lar zaten somutlaştırılmış durumda olduğundan, katkıda bulunanlar hemen çalışmaya başlayabilir
Issue takip sisteminin işletim ilkeleri
- Ghostty, Issue takip sistemini tartışma veya özellik isteği amacıyla kullanmaz
- Özellik istekleri veya genel sorular Discussions üzerinden ele alınır
- Issue’lar yalnızca açıkça tanımlanmış hataları veya uygulanabilir iş maddelerini içerir
- Bu yaklaşım, açık kaynak proje bakım deneyimine dayanarak şekillenmiş bir işletim ilkesidir
- Geçmiş deneyimlere göre, kullanıcı bildirimlerinin %80–90’ı gerçek hata değil, yanlış anlama veya ortam sorunuydu
- Kalanların çoğu ise henüz uygulanmamış özellik istekleriydi ve çoğu zaman ek spesifikasyon gerektiriyordu
Bakım verimliliğini artırma
- Discussions aşamasından geçildiğinde bakımcılar yalnızca doğrulanmış sorunları Issue olarak yönetebilir
- Gereksiz mükerrer bildirimleri veya hatalı hata raporlarını azaltır
- Issue listesi, hemen üzerinde çalışılabilecek maddeler etrafında düzenli kalır
- Kullanıcıların geçerli bir sorun bulsalar bile ek iş yapmasına gerek yoktur
- Yönetici bunu doğrudan bir Issue’ya dönüştürüp işler
Referans doküman
- Ayrıntılı prosedür ve katkı yönergeleri CONTRIBUTING.md dosyasında görülebilir
- Bu belgede Discussions’a katılım şekli ve Issue’ya dönüştürme ölçütleri açıkça belirtilmiştir
3 yorum
Hacker News görüşleri
%100 katılıyorum. Eğer proje başkasına aitse, issue olarak kabul edip etmeme yetkisi tamamen o kişiye aittir
Proje büyüdükçe mesajları okumayanlar, tuhaf taleplerde bulunanlar, hatta AI ile CVE şişirenler bile çıkıyor
Kullanıcı hatanın ne anlama geldiğini bilmese bile, en azından hangi hatanın çıktığını söylemeli
Bir keresinde test sırasında açıkça “broken pipe error” demiştim; mühendis “yeniden üretilemedi” diyerek kapatmıştı, sonra da aynı hatayı gerekçe gösterip yeniden üretilemediğini söylemişti
Çoğu takip sistemi “unconfirmed” gibi durumlarla sınıflandırma yapabilirken, Github daha çok basit bir tartışma sistemi olduğu için yönetmesi zor
4 saat boyunca kod ve kanıt göstererek itiraz ettim, gelen cevap ise “shrugs AI” oldu
“Facebookization” yüzünden birkaç tıklamayla her şeyin hallolduğu düşüncesi oluştu, şimdi de “LLMization” ile bu daha da kötüleşecek gibi görünüyor
Profesyonel yazılımlar için bu yaklaşım uygun değil ama beklentiler artık bu yönde şekillenmiş durumda
Ghostty'nin talepleri tartışmalar üzerinden sınıflandırması alışılmadık ama geçerli bir yaklaşım
Bellek sızıntısı incelemesi birden fazla platforma dağılmış durumda
X bağlantısı 1, X bağlantısı 2, tartışma 1, tartışma 2
Henüz resmî bir issue'ya dönüştürülmedi
8GB sistemde bile terminal birkaç kez çalıştırılınca bellek yetersizliği oluşuyordu
Foot daha az özellik sunuyor ama çok daha kararlıydı
İkinci bağlantı ise sadece tartışma çıkarmaya yönelik gibi görünüyor
Claude Code ve logları analiz ederek geçici bir düzeltme yaptım; şu an 10 denemenin 1'inde yeniden üretilebiliyor
Umarım biri daha derin inceleme yaparken işe yarar
Entegre GPU'larda bile problemler çıkıyor ama suç hep GTK'ya ya da Nvidia'ya atılıyor
“Issues” ile “Discussions” ayrımının verimsiz olduğunu düşünüyorum
Tekrar eden aramalar yapmak gerekiyor ve ticket taşımak da mümkün değil
E-postayla takip edince bildirim akışı da kopuyor
Bu yüzden kendi projelerimde Discussions'ı kapattım
Gerçek bir bug ise o zaman issue'ya çevrilebilir
Yöneticinin “bug” etiketini vermesi yeterli
Tartışma netleşince issue oluşturulabilir
Bildirimler de korunur
Python topluluğundaki bazı büyük projeler de bu yöntemi kullanıyor
Ama güçlü kullanıcılar açısından bug raporlama süreci zahmetli
“Bizim projemiz kusursuz” der gibi bir tavır kibirli hissettiriyor
Çoğu drive-by bug report işe yaramaz, hatta sadece gürültü üretir
Gerçekten katkı sunmak istiyorsan, zaten tanımlanmış bir bug'ı düzeltmek daha iyi olur
Raporlama biçimine sınır koymaları gayet doğal
“Tüm issue'lar üzerinde çalışmaya hazır durumda olmalı” iddiasına karşı,
“O zaman neden sadece ‘ready-to-be-worked-on’ etiketi eklenmiyor?” sorusu soruluyor
Bu sistem çok daha başarılı olmuş
Bu yüzden geliştiricilere ait alan ile kullanıcı alanı ayrılmış
Issues, ölçek büyüdüğünde yönetilemez hale geliyor
Discussions'ı filtre olarak kullanmak daha verimli
Github'ın bu iki özelliği neredeyse aynı arayüze sahip
Sadece Discussions'ta upvote özelliği var
curl/curl/issues
Bunun varsayılan ayar olması gerektiğini düşünenler de var
Topluluk tartışmaları, katkı verenler ise issue'ları yürütmeli; ideal yapı bu
GitHub'ın etiket sistemiyle de rahatça yönetilebilir
GitHub etiket yönetimi belgesi
Tıpkı Natural experiment gibi
Kullanıcıların gönderi açma politikası konusunda hemfikirim
Kapatılmış tartışmalara bakınca kapatılmış issue'lara benziyor ama en azından issue sekmesindeki gürültü azalıyor
Ghostty kapatılmış tartışmalar listesi
Pek çok tartışma o aşamaya gelmiyor ama kullanıcı sorunu çözülmüş oluyor
Bu ayrım yapısı bence oldukça zekice bir tasarım
Aslında “issue açılamıyor” denmesi bir GitHub özelliği değil,
sadece “yeni issue açmak yerine Discussions kullanın” diyen bir şablon yönlendirmesi
Bunu başka projelerde de gördüm;
tartışmayı başlangıç noktası yapan yapı oldukça makul görünüyor
Ancak birçok proje hâlâ GitHub Discussions'ı etkinleştirmiş değil
O tartışmanın issue'dan farkı nedir? Issue bir “bug” değildir. İster bug olsun, ister özellik önerisi, ister PR… tartışmaya değer bir konu varsa bu bir issue'dur.
Tartışmaya değmiyorsa kapatılır.
Bunun nedeni discussion ve issue’nun farklı olması değil; muhtemelen sadece ayrı sekmelere bölünmüş olmasının tercih edilmesidir.
Mesele, issue sekmesinde hem bir tür yapılacaklar listesi hem de discussion’ların paylaşılıp bunların etiketlerle yönetilmesi mi,
vs
issue sekmesinin yalnızca yapılacaklar listesi için, discussion’ın da yalnızca discussion için kullanılması mı.