Linear, GitHub, Slack: 200 सूचनाओं को 5 में बदलें
Linear, GitHub और Slack की सूचनाओं से परेशान? जानें क्यों आर्किटेक्चर विफल होती है – और वे 5 सिग्नल जो मायने रखते हैं।
By Ellis Keane · 2026-03-13
समस्या यह नहीं है कि आपको बहुत अधिक notifications मिलती हैं। समस्या यह है कि आपको बिल्कुल सही संख्या में मिलती हैं – तीन अलग-अलग tools से, एक ही event के बारे में, एक ही समय पर।
हर webhook सही तरीके से fire होता है। हर इंटीग्रेशन ठीक वही deliver करती है जो उसने promise किया था। GitHub आपको PR के बारे में notify करता है। Linear आपको उस issue के बारे में notify करता है जिसे PR close करता है। Slack आपको notify करता है क्योंकि किसी ने – किसी point पर (शायद आपने, तीन महीने पहले, "visibility" के बारे में misplaced optimism के एक दौर में) – एक bot को project channel से connect किया था। तीन tools, तीन notifications, एक event, और सभी बिल्कुल वैसे काम कर रहे हैं जैसे design किए गए थे। Engineering बेदाग है। अनुभव दयनीय है।
आपकी Linear, GitHub और Slack notifications इसलिए भारी नहीं हैं क्योंकि कुछ टूटा हुआ है। वे इसलिए भारी हैं क्योंकि कुछ भी टूटा नहीं है। हर tool अपना notification contract ईमानदारी से execute करता है, इस बात से बिल्कुल बेखबर कि दूसरे मौजूद हैं। कोई shared event bus नहीं है। कोई deduplication layer नहीं है। Stack में कहीं भी यह concept नहीं है कि "यह इंसान पहले से जानता है।" आप किसी misconfiguration से नहीं पीड़ित हैं। आप छह tools को एक ही वर्कफ़्लो में plug करने और उन्हें independently void में चिल्लाने देने के logical endpoint से पीड़ित हैं।
"Notification system fail नहीं हो रहा। यह इतना successful है कि आपको दबा रहा है।" – Chris Calo
प्रगति।
एक single merge की anatomy – duplicates की autopsy
मुझे एक event से गुजरने दें – एक single PR merge – और trace करें कि notification layer में क्या होता है। इसलिए नहीं कि यह असामान्य है, बल्कि इसलिए कि यह depressingly ordinary है।
एक teammate GitHub पर PR merge करता है। यहाँ cascade है:
- GitHub आपके notification inbox में webhook fire करता है। आपने इस PR पर review लिखा था, इसलिए आप subscribe हैं। यह notification एक है।
- Linear की GitHub इंटीग्रेशन linked issue detect करती है और उसका status automatically "In Progress" से "Done" में बदल देती है। Linear उन सभी के लिए notification generate करता है जो issue watch कर रहे हैं – जिसमें आप भी शामिल हैं, क्योंकि आप same team में हैं। यह notification दो है।
- Slack bot (जो आपने optimism के उस दौर में connect किया था जिसका मैंने जिक्र किया) #frontend में एक merge summary post करता है। अगर कोई उस message पर emoji या comment से react करता है, तो Slack एक thread notification generate करता है। यह notification तीन है, संभावित रूप से चार।
- CI merge commit पर run होती है। GitHub एक और webhook fire करता है। अगर CI pass हो जाती है, तो शायद आपको परवाह नहीं, लेकिन आपको notification वैसे भी मिलती है क्योंकि GitHub का subscription model binary है – आप या तो watch कर रहे हैं या नहीं। यह notification पाँच है।
पाँच notifications। एक event। और आप उस call में थे जहाँ merge discuss किया गया था, इसलिए आप उनमें से किसी के आने से पहले ही इसके बारे में जानते थे।
छह लोगों की team के लिए हर PR, हर issue transition और हर CI run पर इसे multiply करें, और आप genuinely new signals को गिनने से पहले ही प्रति व्यक्ति प्रति दिन 30 से 40 duplicate events देख रहे हैं। Notification system fail नहीं हो रहा। यह इतना successful है कि आपको दबा रहा है।
Muting क्यों एक hemorrhage पर पट्टी है
Standard advice है aggressive muting। GitHub email notifications बंद कर दें। Slack को केवल direct mentions पर notify करने के लिए set करें। अपने assigned issues को छोड़कर सभी Linear issues को unfollow कर दें। यह notification का equivalent है एक fractured wrist का इलाज करने के लिए अपनी watch उतारना – technically आपने wrist-related complexity कम कर दी है, लेकिन आपने time देखने की ability भी खो दी है।
मैंने muting approach try की (बेशक मैंने की – हम सब करते हैं, यह वही पहली चीज़ है जो हर कोई try करता है, उस दूसरी चीज़ से ठीक पहले जो हर कोई try करता है, जो कि एक Zapier chain है जो किसी तरह इसे और बुरा बना देती है)। मैं aggressive था: मैंने GitHub emails पूरी तरह बंद कर दीं, हर Slack channel को mute कर दिया जो मेरी team का working channel नहीं था, और Linear में सब कुछ unfollow कर दिया सिवाय अपने issues के। लगभग तीन दिन के लिए bliss।
फिर मैंने दो blocking PR reviews miss कर दिए क्योंकि discussions उन channels में हुईं जिन्हें मैंने mute किया था। जिन engineers को मेरा review चाहिए था, उन्होंने eventually मुझे DM किया – जो कि बस extra steps के साथ एक notification है और passive-aggressive "hey, did you see my message?" energy का एक पहलू है। एक हफ्ते बाद, एक design decision एक Figma comment thread में आई जिसने उस component को पूरी तरह बदल दिया जिसे मैं आधा बना रहा था, और मुझे तब तक पता नहीं चला जब तक मेरा PR reject नहीं हो गया। जो मजेदार था।
Muting की fundamental problem यह है कि यह dynamic context पर static rules apply करती है। पिछले मंगलवार की आपकी notification settings उस urgent bug के बारे में कुछ नहीं जानतीं जो आज सुबह आया। और जितना aggressively आप mute करते हैं, आपकी awareness में gaps उतनी ही बड़ी होती जाती हैं – gaps जो teammates "just checking you saw..." DMs से भरते हैं। जो, अगर आप score रख रहे हैं, तो इसका मतलब है कि aggressive muting आपकी notifications कम नहीं करती। यह उन्हें बस bots (जो आपको judge नहीं करते) से humans (जो definitely करते हैं) में shift कर देती है।
पाँच सिग्नल जो वाकई interruption justify करते हैं
कुछ हफ्तों तक notifications log करने के बाद (एक plain text file में, क्योंकि मैं exactly वही किस्म का इंसान हूँ जिससे आप expect करेंगे कि वह notification architecture पर article लिखे), एक pattern उभरा। लगभग 200 daily pings में से, जो genuinely एक घंटे के अंदर action की जरूरत थी, वे पाँच categories में आते थे:
- कोई आपसे block हो रहा है। आपके code पर PR review request, एक सवाल जो केवल आप answer कर सकते हैं, एक decision जो आपके input का इंतजार कर रहा है। यह एकमात्र category है जहाँ delay का compound cost है – हर घंटे जो आप respond नहीं करते, वह एक घंटा है जो कोई और काम नहीं कर सकता।
- आपने जो deploy किया वह टूट गया है। आपके branch पर CI failures, आपके merge के बाद error spikes, एक revert request। "आपका code जल रहा है" category।
- एक decision लिया गया जो आपके current work को affect करती है। एक design change, एक API contract update, product side से priority shift। ये rare हैं लेकिन miss करना costly है (देखें: मेरा rejected PR, ऊपर)।
- एक deadline बदल गई। Sprint scope बदल गई, एक demo आगे खिसक गई, एक dependency slip हो गई। Calendar-altering events।
- किसी को help चाहिए और आप सही इंसान हैं। हर @channel नहीं। हर @here नहीं। वे specific जहाँ आपकी expertise genuinely relevant है – और तब भी, केवल तभी जब कोई और answer नहीं कर सकता।
बाकी सब कुछ – status transitions, automated bot messages, "sounds good" emoji reactions, branches पर CI passes जो आप watch नहीं कर रहे – ऐसी जानकारी है जो eventually useful हो सकती है लेकिन उस function को interrupt करने की जरूरत नहीं है जो आप लिख रहे हैं। Notification industrial complex ने हमें convince कर दिया है कि ये सभी equal urgency deserve करते हैं। वे नहीं करते।
200 daily notifications में से, लगभग पाँच categories वाकई आपके काम को interrupt करने को justify करती हैं। बाकी ऐसी जानकारी है जो eventually useful हो सकती है – लेकिन tools सब कुछ equally urgent मानते हैं, जिसका मतलब है कि कुछ भी नहीं है।
architecturally betrayed के लिए एक triage framework
यहाँ एक framework है जिसे आप आज से use करना शुरू कर सकते हैं – कोई tools नहीं चाहिए, बस discipline और setup के लिए लगभग 20 मिनट। यह architectural problem को fix नहीं करेगा (deduplication layer से कम कुछ भी नहीं कर सकता), लेकिन यह bleeding रोकेगा जब तक आप longer-term solutions evaluate करते हैं।
दिन में दो बार sweep: Notifications को continuously check करने की बजाय, उन्हें दो sweeps में batch करें – एक बार mid-morning, एक बार mid-afternoon। हर sweep के दौरान, अपनी GitHub notifications, Linear inbox और Slack unreads scan करें, और प्रत्येक को तीन buckets में से एक में sort करें:
| Bucket | नियम | Action | |--------|------|--------| | अभी act करें | कोई block है, कुछ टूटा है, या एक decision आपकी जरूरत है | तुरंत handle करें | | Batch करें | Important लेकिन time-sensitive नहीं | "बाद में respond करें" list में add करें, दिन के अंत में handle करें | | Archive करें | Bot chatter, status updates, resolved threads, duplicates | Read mark करें, आगे बढ़ें |
Slack में channel-level defaults set करें: हर channel के लिए decide करें: क्या यह एक "अभी act करें" channel है (आपकी team का working channel, incident channels) या एक "batch" channel (general announcements, cross-team updates)? Batch channels को mute करें और उन्हें केवल अपने sweeps के दौरान check करें। हाँ, यह technically muting है, जिसका मैंने दो paragraphs में मजाक उड़ाया – फर्क यह है कि आप उन्हें एक schedule पर check करते हैं बजाय यह pretend करने के कि वे exist ही नहीं करते।
GitHub के notification filters use करें: github.com/notifications?query=reason:review-requested bookmark करें – वह URL केवल आपको explicitly assigned PR reviews दिखाता है, subscribed/CI noise पूरी तरह cut करता है। Email के लिए, GitHub एक reason header (review_requested, mention, subscribed, ci_activity) include करता है जिस पर आप filter कर सकते हैं: "subscribed" और "ci_activity" को auto-archive करें और आप कुछ नहीं खोएंगे जो आपको actually चाहिए। यह कि GitHub इस useful metadata को notification UI में expose करने की बजाय email headers में दफन कर देता है, आपको इन systems के consumption side के बारे में कितना सोचा गया है यह सब कुछ बताता है।
यह approach contextual signals को catch नहीं करेगी (याद है वह Figma comment जिसने मेरा PR torpedo किया था? दिन में दो बार sweep ने भी उसे catch नहीं किया होता)। लेकिन यह noise को 60 से 70 percent तक कम कर देगी, जो compulsive alt-tabbing रोकने के लिए काफी है जब तक आप evaluate करते हैं कि problem real solution justify करती है या नहीं।
एक deduplication layer को वास्तव में क्या करना होगा
यहीं यह architecturally interesting हो जाता है – और यहीं मैंने इसे notification settings problem की बजाय classification problem के रूप में सोचना शुरू किया।
Naive approach keyword matching और mention detection है। अगर आपका नाम दिखे, उसे surface करें। अगर यह आपको assigned review request है, उसे surface करें। यह obvious cases को catch करता है लेकिन contextual ones को पूरी तरह miss करता है – वह design decision एक thread में जहाँ किसी ने आपको @mention नहीं किया क्योंकि उन्हें realize नहीं हुआ कि आप उस component को build कर रहे थे जिसे वह affect करती है। (यह मुझे कुछ समय तक haunting करेगी।)
आपको वास्तव में एक relationships graph चाहिए होगा: कौन से tasks आपके हैं, कौन से PRs किन issues से relate करते हैं, कौन से Slack threads किन features के बारे में हैं, कौन से लोग किन topics पर आपका input चाहते हैं। जब एक नया सिग्नल arrive होता है – एक Slack message, एक GitHub event, एक Linear transition – आप उसे उस graph के against classify करते हैं। "क्या इसमें Chris का जिक्र है?" नहीं, बल्कि "क्या यह किसी ऐसी चीज़ को affect करता है जिस पर Chris actively काम कर रहा है, जिसका इंतजार कर रहा है, या जिसके लिए responsible है?"
Classification कुछ इस तरह break down होनी चाहिए:
| Classification | इसका क्या मतलब है | Action | |----------------|-------------------|--------| | Urgent | आप किसी को block कर रहे हैं, या कुछ टूटा है | तुरंत surface करें | | Important | आपके current work को affect करता है, लेकिन time-critical नहीं | Daily digest में batch करें | | Informational | जानना अच्छा है, कोई action नहीं चाहिए | अगर आप खोजें तो available है | | Noise | Duplicates, bot chatter, resolved threads | पूरी तरह filter out |
मुश्किल हिस्सा यह है कि classification confidence binary नहीं है। एक Slack message एक channel में जिसे आप कभी visit नहीं करते, फिर भी urgent हो सकती है अगर यह आपको assigned issue को reference करती है। एक GitHub notification एक ऐसे repo के बारे में जिसे आपने months से नहीं छुआ, important हो सकती है अगर किसी ने अभी एक bug reopen किया जिसे आपने fixed समझा था। आपको दो layers की जरूरत है जो concert में काम करें: एक event normalisation layer जो हर incoming webhook को एक composite key – repo, issue ID, actor, event type – के against hash करती है और एक TTL'd dedup window के against check करती है (basically एक sliding window of recent event fingerprints), और उसके पीछे एक live relationship graph जो task ownership, PR linkages, thread participants और recent activity patterns map करती है। आप essentially team के पूरे working state का एक read model build कर रहे हैं, near-real-time में update होता है, और हर inbound सिग्नल पर query होता है। Dedup layer obvious duplicates catch करती है। Graph harder सवाल का जवाब देता है: "क्या यह specifically आपके लिए, अभी, relevant है?"
Core classification loop clear cases को अच्छी तरह handle करती है, और वह अकेला ही noise को substantially कम कर देता है – लेकिन genuinely ambiguous signals (जहाँ आप suppress करने के लिए confident नहीं हैं लेकिन surface करने के लिए भी confident नहीं हैं) अभी भी एक open problem हैं। हम उन्हें एक "maybe" digest में batch करने के साथ experiment कर रहे हैं, लेकिन मैं pretend नहीं करूंगा कि हमने इसे nail कर लिया है।
जब flood रुकता है तो क्या बदलता है
जो मुझे expect नहीं था – मैंने genuinely सोचा था कि benefit बस "कम pings" होगा – वह यह है कि जब tools आप पर चिल्लाना बंद करते हैं तो आपका tools के साथ relationship कितना profoundly बदल जाता है।
जब हर notification important हो सकती है, आप unread counts के बारे में एक low-grade anxiety develop करते हैं। Bold channel names के साथ Slack sidebar। GitHub bell। Linear inbox। आप compulsively check करते हैं, इसलिए नहीं कि आप कुछ urgent expect करते हैं, बल्कि इसलिए कि कुछ miss करने की cost 50 चीजें check करने की cost से ज्यादा लगती है जो noise निकलती हैं। मैं एक function signature और उसके body लिखने के बीच Slack पर alt-tab करता था। कोई conscious decision नहीं – बस एक reflex, जैसे आप red light पर mirrors check करते हैं।
Preemptive self-interruption शायद notifications से भी बुरी है, क्योंकि आप कोई ping आने से पहले ही अपनी concentration तोड़ रहे हैं। आप permanent partial attention की state में जी रहे हैं, और आप इसे उस code में महसूस करते हैं जो आप लिखते हैं – शallower reviews, safer architectural choices, least resistance का path सही approach की बजाय, क्योंकि आपको trust नहीं है कि आपको इसे सोचने के लिए 45 uninterrupted minutes मिलेंगे।
जब flood रुकता है – जब आपको trust हो कि important signals आपको find करेंगे और noise नहीं करेगी – वह reflex fade होता है। तुरंत नहीं, क्योंकि पुरानी आदतें stubborn होती हैं। लेकिन कुछ हफ्तों में आप notice करते हैं कि आप compulsive alt-tab के बिना अपने editor में longer stretches बिता रहे हैं। आप thoughts finish करने लगते हैं। आप बेहतर code लिखते हैं, इसलिए नहीं कि आप suddenly smarter हो गए, बल्कि इसलिए कि आपने एक ऐसे notification system की तरफ से प्रति घंटे 30 कॉन्टेक्स्ट स्विचिंग के लिए volunteer करना बंद कर दिया जिसने आपसे कभी नहीं माँगा।
Notifications में डूबना बंद करें। Sugarbug Linear, GitHub और Slack के हर सिग्नल को relevance के आधार पर classify करता है – और केवल वही surface करता है जिसे वास्तव में आपकी जरूरत है।
Q: क्या Sugarbug Linear, GitHub और Slack की अत्यधिक सूचनाओं को कम करता है? A: हाँ। Sugarbug API के जरिए Linear, GitHub और Slack से जुड़ता है और हर सिग्नल को urgency और relevance के आधार पर classify करता है। हर notification forward करने की बजाय, यह केवल वही surface करता है जो आपके ध्यान की जरूरत है – आमतौर पर सैकड़ों daily pings को उन मुट्ठी भर में बदल देता है जो genuinely आपकी जरूरत है।
Q: क्या Sugarbug GitHub PR notifications को मेरे मौजूदा काम के आधार पर prioritize कर सकता है? A: Sugarbug आपके tasks, PRs और conversations का एक नॉलेज ग्राफ़ बनाता है। यह जानता है कि कौन से PRs आपके मौजूदा काम से संबंधित हैं और उनके लिए review requests, merge conflicts और CI failures को पहले surface करता है – जबकि बाकी को चुपचाप archive कर देता है।
Q: Sugarbug, Slack की built-in notification settings से कैसे अलग है? A: Slack की settings channels को mute करने या keywords set करने की अनुमति देती है, लेकिन वे tools के बीच context नहीं समझ सकतीं। Sugarbug Linear, GitHub और Slack को एक साथ पढ़ता है, इसलिए यह जानता है कि आपके लिखे PR के बारे में एक Slack thread urgent है, भले ही वह आपके muted channel में हो।
Q: इंजीनियरिंग टीमों के लिए notification overload की असली कीमत क्या है? A: UC Irvine में Gloria Mark की research बताती है कि interruption के बाद गहरी concentration वापस पाने में लगभग 23 मिनट लगते हैं। Pings से परे, वे जो compulsive checking behaviour पैदा करते हैं, वह जटिल engineering काम के लिए जरूरी sustained concentration को तोड़ता है।
अगर आपकी engineering team की notifications "informed रहने" से "anxious रहने" की line पार कर गई हैं, तो यह शायद इस बात का संकेत है कि architecture को fix करने की जरूरत है, न कि आपकी notification preferences को।