Linear, GitHub, Slack Bildirimleri – 200'den 5'e
Linear, GitHub ve Slack bildirimleri mühendislik ekibinizi bunaltıyor mu? Mimarinin neden çöktüğünün analizi – ve tutmaya değer 5 sinyal.
By Ellis Keane · 2026-03-13
Sorun çok fazla bildirim almanız değil. Sorun tam olarak doğru sayıda almanız – üç farklı araçtan, aynı etkinlik için, aynı anda.
Her webhook doğru şekilde çalışıyor. Her entegrasyon tam olarak vaat ettiğini sunuyor. GitHub sizi PR hakkında bilgilendiriyor. Linear sizi PR'ın kapattığı issue hakkında bilgilendiriyor. Slack sizi bilgilendiriyor çünkü biri, bir noktada (muhtemelen siz, üç ay önce, "görünürlük" konusunda yanlış yerleştirilmiş bir iyimserlik anında), proje kanalına bir bot bağladı. Üç araç, üç bildirim, bir etkinlik ve hepsi tam olarak tasarlandığı gibi çalışıyor. Mühendislik kusursuz. Deneyim berbat.
Linear, GitHub ve Slack bildirimleriniz bunaltıcı çünkü bir şeyler bozuk değil. Hiçbir şey bozuk olmadığı için bunaltıcı. Her araç, diğerlerinin varlığından tamamen habersiz şekilde bildirim sözleşmesini sadakatle yerine getiriyor. Paylaşılan bir event bus yok. Tekrarsızlaştırma katmanı yok. Yığında hiçbir yerde "bu insan bunu zaten biliyor" kavramı yok. Yanlış yapılandırma nedeniyle acı çekmiyorsunuz. Altı aracı aynı iş akışına bağlayıp her birinin bağımsızca boşluğa bağırmasına izin vermenin mantıksal sonucu nedeniyle acı çekiyorsunuz.
"Bildirim sistemi başarısız olmuyor. O kadar başarılı oluyor ki sizi gömüyor." – Chris Calo
İlerleme.
Tek bir birleştirmenin anatomisi – tekrarlama otopsisi
Size bir etkinliği – tek bir PR birleştirmesini – anlatayım ve bildirim katmanında ne olduğunu izleyelim. Olağandışı olduğu için değil, kasvetli ölçüde sıradan olduğu için.
Bir takım arkadaşı GitHub'da bir PR birleştiriyor. İşte basamaklanma:
- GitHub, bildirim gelen kutunuza bir webhook gönderiyor. Bu PR'da inceleme yazdınız, bu yüzden abone oldunuz. Bu birinci bildirim.
- Linear'ın GitHub entegrasyonu, bağlı issue'yu tespit eder ve durumunu otomatik olarak "Devam Ediyor"dan "Tamamlandı"ya geçirir. Linear, issue'yu izleyen herkes için bir bildirim oluşturur – siz de dahil, çünkü aynı takımdasınız. Bu ikinci bildirim.
- Slack botu (bahsettiğim iyimserlik anında bağladığınız) #frontend'e bir birleştirme özeti gönderir. Biri o mesaja emoji veya yorum ile yanıt verirse Slack bir başlık bildirimi oluşturur. Bu üçüncü, potansiyel olarak dördüncü bildirim.
- CI, birleştirme commit'i üzerinde çalışır. GitHub başka bir webhook gönderir. CI geçerse muhtemelen umursamazsınız, ancak yine de bildirimi alırsınız çünkü GitHub'ın abonelik modeli ikili – ya izliyorsunuzdur ya da izlemiyorsunuzdur. Bu beşinci bildirim.
Beş bildirim. Bir etkinlik. Ve birleştirmenin tartışıldığı çağrıdaydınız, yani herhangi biri gelmeden önce bunu zaten biliyordunuz.
Bunu her PR, her issue geçişi ve altı kişilik bir ekip için her CI çalıştırması üzerine çarpın; gerçekten yeni sinyalleri saymadan önce kişi başı günde 30 ila 40 tekrar etkinlikle karşı karşıyasınız. Bildirim sistemi başarısız olmuyor. O kadar başarılı oluyor ki sizi gömüyor.
Sessize almanın neden bir yara bandı olduğu
Standart tavsiye agresif sessize almadır. GitHub e-posta bildirimlerini kapatın. Slack'i yalnızca doğrudan bahsedildiğinde bildirim verecek şekilde ayarlayın. Linear'daki size atananlar dışındaki tüm issue'ların takibini bırakın. Bu, kırık bir bileği saati çıkararak tedavi etmenin bildirim eşdeğeri – teknik olarak bilek ile ilgili karmaşıklığı azalttınız, ancak saatin kaç olduğunu söyleme yeteneğinizi de kaybettiniz.
Sessize alma yaklaşımını denedim (tabii ki denedim – hepimiz deneriz, herkesin denediği ilk şey bu, bunu daha da kötü hale getiren bir Zapier zinciri olan herkesin denediği ikinci şeyden önce). Agresif gittim: GitHub e-postalarını tamamen kapattım, ekibimin çalışma kanalı dışındaki her Slack kanalını sessize aldım, Linear'da kendi issue'larım dışında her şeyin takibini bıraktım. Yaklaşık üç gün mutluluk.
Sonra tartışmalar sessize aldığım kanallarda gerçekleştiği için iki engelleme PR incelemesini kaçırdım. İncelememe ihtiyaç duyan mühendisler sonunda bana DM attı – bu sadece ekstra adımlar ve bir kenar passive-aggressive "hey, mesajımı gördün mü?" enerjisi olan bir bildirim. Bir hafta sonra, tam inşa ettiğim komponenti değiştiren bir tasarım kararı kimsenin beni @-bahsetmediği bir Figma yorum başlığına düştü ve PR'm reddedilinceye kadar öğrenemedim. Eğlenceliydi.
Sessize almanın temel sorunu, dinamik bağlama statik kurallar uygulamasıdır. Geçen Salı'dan gelen bildirim ayarlarınız bu sabah gelen acil hatadan habersizdir. Ve ne kadar agresif sessize alırsanız, farkındalığınızdaki boşluklar o kadar genişler – takım arkadaşlarının "sadece gördüğünü kontrol ediyorum..." DM'leriyle doldurduğu boşluklar. Sayıyorsanız, bu agresif sessize almanın bildirimlerinizi azaltmadığı anlamına geliyor. Sadece onları botlardan (sizi yargılamayan) insanlara (kesinlikle yargılayan) kaydırıyor.
Gerçekten kesintiye değer beş sinyal
Birkaç hafta bildirim kaydettikten sonra (düz bir metin dosyasında, çünkü bildirim mimarisi hakkında makale yazacağınızı bekleyeceğiniz türden birisiyim), bir desen ortaya çıktı. Günlük yaklaşık 200 bildirim arasından, gerçekten saat içinde eylem gerektirenlerin beş kategoriye girdiği görüldü:
- Biri sizin tarafınızdan engelleniyor. Sahip olduğunuz kod üzerinde PR inceleme isteği, yalnızca sizin yanıtlayabileceğiniz bir soru, girdinizi bekleyen bir karar. Bu, gecikmenin bileşik bir maliyeti olan tek kategoridir – yanıt vermediğiniz her saat, başkasının çalışamadığı bir saattir.
- Dağıttığınız bir şey bozuk. Dalınızda CI hataları, birleştirmenizin ardından hata artışları, geri alma isteği. "Kodunuz yanıyor" kategorisi.
- Mevcut çalışmanızı etkileyen bir karar alındı. Tasarım değişikliği, API sözleşmesi güncellemesi, ürün tarafından öncelik değişikliği. Bunlar nadir ama kaçırması pahalı (bkz: reddedilen PR'm, yukarıda).
- Son teslim tarihi değişti. Sprint kapsamı değişti, bir demo öne çekildi, bir bağımlılık kaydı. Takvimi değiştiren etkinlikler.
- Birisinin yardıma ihtiyacı var ve siz doğru kişisiniz. Her @channel değil. Her @here değil. Uzmanlığınızın gerçekten ilgili olduğu spesifik olanlar – ve hatta o zaman bile yalnızca kimse başkası yanıtlayamazsa.
Diğer her şey – durum geçişleri, otomatik bot mesajları, "güzel" emoji tepkileri, izlemediğiniz dallarda CI geçişleri – nihayetinde yararlı olabilecek bilgilerdir, ancak yazdığınız işlevi kesintiye uğratması gerekmez. Bildirim sanayi kompleksi hepsinin eşit aciliyete layık olduğuna bizi inandırdı. Değiller.
Günlük 200 bildirimden yaklaşık beş kategori gerçekten ne yaptığınızı kesintiye uğratmayı hak ediyor. Geri kalanı nihayetinde yararlı olabilecek bilgilerdir – ancak araçlar her şeye eşit derecede acil davranır, bu da hiçbir şeyin acil olmadığı anlamına gelir.
Mimarisi hain dışına kalmış olanlar için bir önceliklendirme çerçevesi
İşte bugün kullanmaya başlayabileceğiniz bir çerçeve – araç gerekmez, sadece disiplin ve yaklaşık 20 dakika kurulum. Mimari sorunu çözmeyecek (bunu yalnızca bir tekrarsızlaştırma katmanı yapabilir), ancak daha uzun vadeli çözümler değerlendirirken kanamayı durduracak.
Günde iki tarama: Bildirimleri sürekli kontrol etmek yerine iki taramaya yığın – biri sabah ortasında, biri öğleden sonra ortasında. Her taramada GitHub bildirimlerinizi, Linear gelen kutunuzu ve Slack okunmamışlarını tarayın ve her birini üç gruptan birine ayırın:
| Grup | Kural | Eylem | |--------|------|--------| | Şimdi harekete geç | Biri engellendi, bir şey bozuk ya da bir karar sizi gerektiriyor | Hemen hallerin | | Toplu işlem | Önemli ama zamana duyarlı değil | "Daha sonra yanıtla" listesine ekle, gün sonunda hallerin | | Arşiv | Bot sohbeti, durum güncellemeleri, çözülen başlıklar, tekrarlar | Okundu işaretle, hayatına devam et |
Slack'te kanal düzeyinde varsayılanlar ayarlayın: Her kanal için karar verin: Bu bir "şimdi harekete geç" kanalı mı (ekibinizin çalışma kanalı, olay kanalları) yoksa "toplu işlem" kanalı mı (genel duyurular, çapraz ekip güncellemeleri)? Toplu işlem kanallarını sessize alın ve yalnızca taramalarınız sırasında kontrol edin. Evet, bu teknik olarak sessize almadır, bunu az önce iki paragrafta alay etmiştim – fark şu ki, var olmadığını varsaymak yerine yine de bir programa göre kontrol ediyorsunuz.
GitHub'ın bildirim filtrelerini kullanın: github.com/notifications?query=reason:review-requested adresini yer imlerinize ekleyin – bu URL yalnızca size açıkça atanan PR incelemelerini gösterir, abone olunan/CI gürültüsünü tamamen keser. E-posta için GitHub, filtreleyebileceğiniz bir reason header (review_requested, mention, subscribed, ci_activity) içerir: "subscribed" ve "ci_activity"yi otomatik arşivleyin, gerçekten ihtiyaç duyduğunuz hiçbir şeyi kaçırmazsınız. GitHub'ın bu yararlı meta verileri bildirim arayüzünde değil e-posta başlıklarına gömmesi, bu sistemlerin tüketim tarafına ne kadar düşünüldüğünü anlatıyor.
Bu yaklaşım bağlamsal sinyalleri yakalamaz (PR'ımı sabote eden Figma yorumunu hatırlıyor musunuz? Günde iki tarama onu da yakalamıyordu). Ancak gürültüyü yüzde 60 ila 70 azaltacak; sorunun gerçek bir çözüm gerektirip gerektirmediğini değerlendirirken zorunlu alt-tab'ı durdurmaya yetecek kadar.
Bir tekrarsızlaştırma katmanının gerçekten ne yapması gerektiği
İşte mimarisi açısından ilginçleşiyor – ve bunu bir bildirim ayarları sorunu olarak düşünmeyi bırakıp bir sınıflandırma sorunu olarak düşünmeye başladığım yer.
Naif yaklaşım anahtar kelime eşleştirme ve bahsetme tespitidir. Adınız görünürse, öne çıkarın. Size atanan bir inceleme isteğiyse, öne çıkarın. Bu, belirgin vakaları yakalar, ancak bağlamsal olanları tamamen kaçırır – etkilediği komponenti inşa ettiğinizi fark etmedikleri için sizi kimsenin @-bahsetmediği bir başlıkta alınan tasarım kararı gibi. (Bu beni bir süre daha rahatsız edecek.)
Gerçekten ihtiyaç duyacağınız şey bir ilişkiler grafiğidir: Hangi görevler sizin, hangi PR'lar hangi issue'larla ilgili, hangi Slack başlıkları hangi özelliklerle ilgili, hangi kişiler hangi konularda girdinize ihtiyaç duyuyor. Yeni bir sinyal geldiğinde – bir Slack mesajı, bir GitHub etkinliği, bir Linear geçişi – onu o grafiğe göre sınıflandırırsınız. "Bu Chris'ten bahsediyor mu?" değil, "Bu Chris'in şu anda üzerinde çalıştığı, beklediği veya sorumlu olduğu bir şeyi etkiliyor mu?"
Sınıflandırma şöyle bir şeye ayrılması gerekir:
| Sınıflandırma | Anlamı | Eylem | |---------------|---------------|--------| | Acil | Birini engelliyorsunuz veya bir şey bozuk | Hemen öne çıkar | | Önemli | Mevcut çalışmanızı etkiliyor, ancak zamana duyarlı değil | Günlük özette toplu işle | | Bilgilendirici | Bilmek güzel, eylem gerekmiyor | Ararsanız erişilebilir | | Gürültü | Tekrarlar, bot sohbeti, çözülen başlıklar | Tamamen filtrelendi |
Zor kısım, sınıflandırma güveninin ikili olmamasıdır. Hiç ziyaret etmediğiniz bir kanaldaki Slack mesajı, size atanan bir issue'ya atıfta bulunuyorsa yine de acil olabilir. Aylardır dokunmadığınız bir repo hakkındaki GitHub bildirimi, biri düzeltildiğini düşündüğünüz bir hatayı yeniden açarsa önem kazanabilir. Birlikte çalışan iki katmana ihtiyacınız var: gelen her webhook'u bileşik bir anahtara göre – repo, issue kimliği, aktör, etkinlik türü – karma eden ve TTL'li bir tekrarsızlaştırma penceresine karşı kontrol eden bir etkinlik normalleştirme katmanı (temelde son etkinlik parmak izlerinin kayan penceresi) ve bunun arkasında görev sahipliğini, PR bağlantılarını, başlık katılımcılarını ve son etkinlik modellerini eşleştiren canlı bir ilişki grafiği. Temelde ekibin tüm çalışma durumunun neredeyse gerçek zamanlı güncellenen ve gelen her sinyalde sorgulanan bir okuma modelini inşa ediyorsunuz. Tekrarsızlaştırma katmanı açık tekrarları yakalar. Grafik daha zor soruyu yanıtlar: "Bu şu anda özellikle sizinle ilgili mi?"
Temel sınıflandırma döngüsü açık vakaları iyi işler ve bu tek başına gürültüyü önemli ölçüde azaltır – ancak gerçekten belirsiz sinyaller (bastırmak için yeterince güvensiz ama öne çıkarmak için de yeterince güvensiz olduğunuz) hâlâ açık bir problem. Bunları "maybe" özetinde toplamayı deniyoruz, ancak bunu çözdüğümüzü iddia etmeyeceğim.
Hortum durduğunda ne değişir
Beklentim olmayan şey – gerçekten faydanın sadece "daha az bildirim" olacağını düşünüyordum – araçlarınızla ilişkinizin, onlar size bağırmayı bıraktığında ne kadar derinden değiştiğidir.
Her bildirim önemli olabildiğinde, okunmamış sayılar hakkında düşük yoğunluklu bir kaygı geliştirirsiniz. Kalın kanal adlarıyla Slack kenar çubuğu. GitHub zili. Linear gelen kutusu. Zorunlu olarak kontrol edersiniz, acil bir şey beklediğiniz için değil, bir şeyi kaçırmanın maliyeti gürültüye dönüşen 50 şeyi kontrol etmenin maliyetinden daha yüksek hissettirdiği için. Bir işlev imzası ile gövdesini yazarken Slack'e alt-tab yapar olmuştum. Bilinçli bir karar değil – sadece bir refleks, kırmızı ışıkta aynalarınızı kontrol edeceğiniz gibi.
Önleyici öz-kesinti, bildirimlerin kendisinden tartışmasız daha kötüdür, çünkü herhangi bir bildirim gelmeden önce kendi konsantrasyonunuzu bozuyorsunuzdur. Kalıcı kısmi dikkat durumunda yaşıyorsunuzdur ve bunu yazdığınız kodda hissedebilirsiniz – daha yüzeysel incelemeler, daha güvenli mimari seçimler, gerçekten doğru olan yaklaşım yerine en az direnç yolu, çünkü düşünmek için 45 kesintisiz dakika alacağınıza güvenmiyorsunuzdur.
Hortum durduğunda – önemli sinyallerin sizi bulacağına ve gürültünün bulmayacağına güvendiğinizde – o refleks solar. Hemen değil, çünkü eski alışkanlıklar inatçıdır. Ancak birkaç hafta içinde editörünüzde zorunlu alt-tab olmadan daha uzun süreler geçirdiğinizi fark edersiniz. Düşüncelerinizi tamamlamaya başlarsınız. Daha iyi kod yazarsınız, aniden daha akıllı hale geldiğiniz için değil, hiç sormadığı bir bildirim sistemi adına saatte 30 bağlam değiştirmeye gönüllü olmayı bıraktığınız için.
Bildirimlerde boğulmayı bırakın. Sugarbug, Linear, GitHub ve Slack'ten gelen her sinyali ilgiye göre sınıflandırır – ve yalnızca gerçekten sizi gerektireni öne çıkarır.
Q: Sugarbug, Linear, GitHub ve Slack'ten gelen bunaltıcı bildirimleri azaltıyor mu? A: Evet. Sugarbug, Linear, GitHub ve Slack'e API aracılığıyla bağlanır ve her sinyali aciliyet ve ilgiye göre sınıflandırır. Her bildirimi iletmek yerine yalnızca dikkatinizi gerektirenleri öne çıkarır – genellikle günlük yüzlerce bildirimi gerçekten sizi gerektiren bir avuç bildirime indirir.
Q: Sugarbug, GitHub PR bildirimlerini üzerinde çalıştıklarıma göre önceliklendirebilir mi? A: Sugarbug, görevlerinizin, PR'larınızın ve konuşmalarınızın bir bilgi grafiğini oluşturur. Hangi PR'ların mevcut çalışmanızla ilgili olduğunu bilir ve önce bunlar için inceleme isteklerini, birleştirme çakışmalarını ve CI hatalarını öne çıkarır – geri kalanını sessizce arşivler.
Q: Sugarbug, Slack'in yerleşik bildirim ayarlarından nasıl farklı? A: Slack'in ayarları kanalları sessize almanıza veya anahtar kelimeler ayarlamanıza izin verir, ancak araçlar arasındaki bağlamı anlayamaz. Sugarbug, Linear, GitHub ve Slack'i birlikte okur; bu nedenle sessize aldığınız bir kanalda bile yazdığınız bir PR hakkındaki Slack başlığının acil olduğunu bilir.
Q: Mühendislik ekipleri için bildirim aşırı yükünün gerçek maliyeti nedir? A: Gloria Mark'ın UC Irvine'deki araştırması, bir kesintiden sonra derin odağı yeniden kazanmanın yaklaşık 23 dakika aldığını öne sürüyor. Bildirimlerin ötesinde, oluşturdukları zorunlu kontrol davranışı, karmaşık mühendislik çalışmasının gerektirdiği sürekli konsantrasyonu parçalıyor.
Mühendislik ekibinizin bildirimleri "bilgi sahibi olmak"tan "kaygılı kalmak"a geçtiyse, bu muhtemelen bildirim tercihlerinizin değil, mimarinin düzeltilmesi gerektiğinin bir işaretidir.