كثرة الإشعارات: Linear و GitHub و Slack
هل ترهق إشعارات Linear وGitHub وSlack فريقك الهندسي؟ تحليل لسبب فشل البنية – و5 إشارات تستحق الاحتفاظ بها.
By Chris Calo · 2026-03-13
المشكلة ليست في أنك تتلقى عدداً كبيراً جداً من الإشعارات. المشكلة هي أنك تتلقى العدد الصحيح تماماً – من ثلاث أدوات مختلفة، حول نفس الحدث، في نفس الوقت.
يتم إطلاق كل خطاف ويب (webhook) بشكل صحيح. يقدم كل تكامل بالضبط ما وعد به. يخطرك GitHub حول PR. يخطرك Linear حول المشكلة التي يغلقها PR. يخطرك Slack لأن شخصاً ما، في وقت ما (ربما أنت، منذ ثلاثة أشهر، في نوبة من التفاؤل في غير محله حول "الرؤية")، قام بتوصيل روبوت بقناة المشروع. ثلاث أدوات، ثلاثة إشعارات، حدث واحد، وكلها تعمل تماماً كما تم تصميمها. الهندسة لا تشوبها شائبة. التجربة بائسة.
إشعارات Linear و GitHub و Slack الخاصة بك ليست مرهقة لأن شيئاً ما معطل. إنها مرهقة لأنه لا يوجد شيء معطل. تنفذ كل أداة بأمانة عقد الإشعارات الخاص بها دون أي وعي بوجود الأدوات الأخرى. لا يوجد ناقل أحداث مشترك. لا توجد طبقة إزالة التكرار. لا يوجد مفهوم، في أي مكان في الحزمة، لـ "هذا الإنسان يعرف بالفعل عن هذا". أنت لا تعاني من خطأ في التكوين. أنت تعاني من النهاية المنطقية لتوصيل ست أدوات في نفس سير العمل والسماح لكل منها بالصراخ بشكل مستقل في الفراغ.
"نظام الإشعارات لا يفشل. إنه ينجح بشدة لدرجة أنه يدفنك." – كريس كالو
تقدم.
تشريح عملية دمج واحدة – فحص التكرار
دعني أستعرض معك حدثاً واحداً – دمج PR واحد – وأتتبع ما يحدث في طبقة الإشعارات. ليس لأنه غير عادي، ولكن لأنه عادي بشكل محبط.
يقوم زميل في الفريق بدمج PR على GitHub. إليك التسلسل:
- يطلق GitHub خطاف ويب إلى صندوق وارد الإشعارات الخاص بك. لقد قمت بتأليف مراجعة على هذا PR، لذا فأنت مشترك. هذا هو الإشعار الأول.
- يكتشف تكامل GitHub في Linear المشكلة المرتبطة وينقل حالتها تلقائياً من "قيد التقدم" إلى "تم". ينشئ Linear إشعاراً لكل من يراقب المشكلة – والذي يشملك، لأنك في نفس الفريق. هذا هو الإشعار الثاني.
- ينشر روبوت Slack (الذي قمت بتوصيله في نوبة التفاؤل تلك التي ذكرتها) ملخص دمج في #frontend. إذا تفاعل أي شخص مع تلك الرسالة برمز تعبيري أو تعليق، فإن Slack ينشئ إشعار سلسلة رسائل. هذا هو الإشعار الثالث، وربما الرابع.
- يعمل CI على التزام الدمج. يطلق GitHub خطاف ويب آخر. إذا نجح CI، فربما لا تهتم، لكنك تتلقى الإشعار على أي حال لأن نموذج الاشتراك في GitHub ثنائي – إما أنك تراقب أو لا تراقب. هذا هو الإشعار الخامس.
خمسة إشعارات. حدث واحد. وكنت في المكالمة حيث تمت مناقشة الدمج، لذلك كنت تعرف عنه بالفعل قبل وصول أي منها.
اضرب هذا في كل PR، وكل انتقال لمشكلة، وكل تشغيل CI لفريق مكون من ستة أشخاص، وستنظر إلى 30 إلى 40 حدثاً مكرراً لكل شخص يومياً قبل أن تحسب الإشارات الجديدة حقاً. نظام الإشعارات لا يفشل. إنه ينجح بشدة لدرجة أنه يدفنك.
لماذا يعتبر الكتم مجرد ضمادة على نزيف
النصيحة القياسية هي الكتم العدواني. قم بإيقاف تشغيل إشعارات البريد الإلكتروني من GitHub. اضبط Slack للإشعار فقط عند الإشارات المباشرة. قم بإلغاء متابعة جميع مشكلات Linear باستثناء تلك المعينة لك. هذا هو المعادل الإشعاري لعلاج كسر في المعصم عن طريق خلع ساعتك – من الناحية الفنية، لقد قللت من التعقيد المتعلق بالمعصم، لكنك فقدت أيضاً القدرة على معرفة الوقت.
لقد جربت نهج الكتم (بالطبع فعلت – كلنا نفعل ذلك، إنه أول شيء يجربه الجميع، قبل الشيء الثاني الذي يجربه الجميع مباشرة، وهو سلسلة Zapier التي تجعل الأمر أسوأ بطريقة ما). لقد ذهبت بقوة: قتلت رسائل البريد الإلكتروني من GitHub تماماً، وكتمت كل قناة Slack لم تكن قناة عمل فريقي، وألغيت متابعة كل شيء في Linear باستثناء مشكلاتي الخاصة. نعيم لمدة ثلاثة أيام تقريباً.
ثم فاتني مراجعتان معرقلتان لـ PR لأن المناقشات حدثت في قنوات قمت بكتمها. المهندسون الذين احتاجوا إلى مراجعتي أرسلوا لي رسائل مباشرة (DM) في النهاية – وهو مجرد إشعار بخطوات إضافية وجانب من الطاقة السلبية العدوانية "مهلاً، هل رأيت رسالتي؟". بعد أسبوع، هبط قرار تصميم في سلسلة تعليقات Figma غيّر تماماً المكون الذي كنت في منتصف بنائه، ولم أكتشف ذلك حتى تم رفض PR الخاص بي. وهو ما كان ممتعاً.
المشكلة الأساسية في الكتم هي أنه يطبق قواعد ثابتة على سياق ديناميكي. إعدادات الإشعارات الخاصة بك من يوم الثلاثاء الماضي لا تعرف عن الخطأ العاجل الذي هبط هذا الصباح. وكلما زادت عدوانية الكتم، زادت الفجوات في وعيك – الفجوات التي يملأها زملاء الفريق برسائل مباشرة "أتحقق فقط من أنك رأيت...". والذي، إذا كنت تحتفظ بالنتيجة، يعني أن الكتم العدواني لا يقلل من إشعاراتك. إنه يحولها فقط من الروبوتات (التي لا تحكم عليك) إلى البشر (الذين يفعلون ذلك بالتأكيد).
الإشارات الخمس التي تبرر المقاطعة حقاً
بعد تسجيل الإشعارات لبضعة أسابيع (في ملف نصي عادي، لأنني بالضبط نوع الشخص الذي تتوقع أن يكتب مقالاً حول بنية الإشعارات)، ظهر نمط. من بين حوالي 200 تنبيه يومي، الإشعارات التي تطلبت اتخاذ إجراء حقاً في غضون ساعة وقعت في خمس فئات:
- شخص ما محظور بسببك. طلب مراجعة PR على كود تملكه، سؤال لا يمكن لأحد غيرك الإجابة عليه، قرار ينتظر مدخلاتك. هذه هي الفئة الوحيدة التي يكون للتأخير فيها تكلفة مضاعفة – كل ساعة لا ترد فيها هي ساعة لا يستطيع فيها شخص آخر العمل.
- شيء قمت بنشره معطل. إخفاقات CI على فرعك، ارتفاع الأخطاء بعد الدمج، طلب تراجع. فئة "الكود الخاص بك يحترق".
- تم اتخاذ قرار يؤثر على عملك الحالي. تغيير في التصميم، تحديث لعقد واجهة برمجة التطبيقات، تحول في الأولوية من جانب المنتج. هذه نادرة ولكن تفويتها مكلف (انظر: PR المرفوض الخاص بي، أعلاه).
- تحرك موعد نهائي. تغير نطاق السبرينت، تم تقديم عرض توضيحي، انزلقت تبعية. أحداث تغير التقويم.
- شخص ما يحتاج إلى مساعدة وأنت الشخص المناسب. ليس كل @channel. ليس كل @here. تلك المحددة التي تكون فيها خبرتك ذات صلة حقاً – وحتى ذلك الحين، فقط إذا لم يتمكن أحد غيرك من الإجابة.
كل شيء آخر – انتقالات الحالة، رسائل الروبوت الآلية، تفاعلات الرموز التعبيرية "يبدو جيداً"، نجاح CI على الفروع التي لا تراقبها – هو معلومات قد تكون مفيدة في النهاية ولكنها لا تحتاج إلى مقاطعة الوظيفة التي تكتبها. لقد أقنعنا المجمع الصناعي للإشعارات بأن كل هذه تستحق نفس القدر من الإلحاح. إنها لا تستحق ذلك.
من بين 200 إشعار يومي، هناك خمس فئات تقريباً تبرر مقاطعة ما تفعله. الباقي عبارة عن معلومات قد تكون مفيدة في النهاية – لكن الأدوات تعامل كل شيء على أنه عاجل بنفس القدر، مما يعني أنه لا يوجد شيء كذلك.
إطار فرز لمن تعرضوا لخيانة معمارية
إليك إطار عمل يمكنك البدء في استخدامه اليوم – لا يتطلب أدوات، فقط الانضباط وحوالي 20 دقيقة من الإعداد. لن يصلح المشكلة المعمارية (لا شيء أقل من طبقة إزالة التكرار يمكنه فعل ذلك)، لكنه سيوقف النزيف بينما تقيم حلولاً طويلة الأجل.
المسح مرتين يومياً: بدلاً من التحقق من الإشعارات باستمرار، قم بتجميعها في مسحتين – واحدة في منتصف الصباح، وواحدة في منتصف فترة ما بعد الظهر. خلال كل مسحة، افحص إشعارات GitHub، وصندوق وارد Linear، ورسائل Slack غير المقروءة، وقم بفرز كل منها في واحدة من ثلاث دلاء:
| الدلو | القاعدة | الإجراء | |--------|------|--------| | تصرف الآن | شخص ما محظور، أو شيء ما معطل، أو قرار يحتاجك | تعامل معه على الفور | | تجميع | مهم ولكن ليس حساساً للوقت | أضفه إلى قائمة "الرد لاحقاً"، وتعامل معه في نهاية اليوم | | أرشفة | ثرثرة الروبوتات، تحديثات الحالة، السلاسل التي تم حلها، التكرارات | حدد كمقروء، وامضِ في حياتك |
تعيين الإعدادات الافتراضية على مستوى القناة في Slack: لكل قناة، قرر: هل هذه قناة "تصرف الآن" (قناة عمل فريقك، قنوات الحوادث) أم قناة "تجميع" (الإعلانات العامة، التحديثات عبر الفرق)؟ اكتم قنوات التجميع وتحقق منها فقط أثناء مسحاتك. نعم، هذا من الناحية الفنية كتم، والذي قضيت للتو فقرتين في السخرية منه – الفرق هو أنك لا تزال تتحقق منها وفقاً لجدول زمني بدلاً من التظاهر بعدم وجودها.
استخدم مرشحات إشعارات GitHub: ضع إشارة مرجعية على github.com/notifications?query=reason:review-requested – يعرض عنوان URL هذا فقط مراجعات PR المعينة لك صراحةً، مما يقطع ضوضاء المشتركين/CI تماماً. بالنسبة للبريد الإلكتروني، يتضمن GitHub رأس سبب (review_requested، mention، subscribed، ci_activity) يمكنك التصفية بناءً عليه: أرشفة تلقائية لـ "subscribed" و "ci_activity" ولن تفقد أي شيء تحتاجه بالفعل. حقيقة أن GitHub يدفن هذه البيانات الوصفية المفيدة في رؤوس البريد الإلكتروني بدلاً من كشفها في واجهة مستخدم الإشعارات تخبرك بكل شيء عن مقدار التفكير الذي يذهب إلى جانب الاستهلاك في هذه الأنظمة.
لن يلتقط هذا النهج الإشارات السياقية (هل تتذكر تعليق Figma الذي دمر PR الخاص بي؟ المسح مرتين يومياً لم يكن ليلتقط ذلك أيضاً). لكنه سيقلل الضوضاء بنسبة 60 إلى 70 بالمائة، وهو ما يكفي لإيقاف التبديل القهري (alt-tabbing) بينما تكتشف ما إذا كانت المشكلة تبرر حلاً حقيقياً.
ما الذي ستحتاج طبقة إزالة التكرار إلى القيام به حقاً
هنا يصبح الأمر مثيراً للاهتمام من الناحية المعمارية – وحيث توقفت عن التفكير في هذا كمشكلة إعدادات إشعارات وبدأت في التفكير فيه كمشكلة تصنيف.
النهج الساذج هو مطابقة الكلمات الرئيسية واكتشاف الإشارات. إذا ظهر اسمك، أظهره. إذا كان طلب مراجعة معيناً لك، أظهره. هذا يلتقط الحالات الواضحة ولكنه يفتقد تماماً الحالات السياقية – قرار التصميم في سلسلة رسائل لم يشر إليك فيها أحد لأنهم لم يدركوا أنك كنت تبني المكون الذي يؤثر عليه. (هذا سيطاردني لفترة من الوقت.)
ما ستحتاجه بالفعل هو رسم بياني للعلاقات: أي المهام هي مهامك، وأي PRs تتعلق بأي مشكلات، وأي سلاسل Slack تدور حول أي ميزات، وأي الأشخاص يميلون إلى الحاجة إلى مدخلاتك في أي مواضيع. عندما تصل إشارة جديدة – رسالة Slack، حدث GitHub، انتقال Linear – تقوم بتصنيفها مقابل هذا الرسم البياني. ليس "هل يذكر هذا كريس؟" بل "هل يؤثر هذا على شيء يعمل عليه كريس بنشاط، أو ينتظره، أو مسؤول عنه؟"
سيحتاج التصنيف إلى التقسيم إلى شيء مثل:
| التصنيف | ماذا يعني | الإجراء | |---------------|---------------|--------| | عاجل | أنت تحظر شخصاً ما، أو شيء ما معطل | إظهار على الفور | | مهم | يؤثر على عملك الحالي، ولكن ليس حرجاً للوقت | تجميع في ملخص يومي | | إعلامي | من الجيد معرفته، لا حاجة لاتخاذ إجراء | متاح إذا ذهبت للبحث | | ضوضاء | تكرارات، ثرثرة الروبوتات، سلاسل تم حلها | تمت تصفيته بالكامل |
الجزء الصعب هو أن الثقة في التصنيف ليست ثنائية. قد تظل رسالة Slack في قناة لا تزورها أبداً عاجلة إذا كانت تشير إلى مشكلة معينة لك. قد يهم إشعار GitHub حول مستودع لم تلمسه منذ أشهر إذا أعاد شخص ما فتح خطأ اعتقدت أنه تم إصلاحه. أنت بحاجة إلى طبقتين تعملان بتناغم: طبقة تسوية الأحداث التي تقوم بتجزئة كل خطاف ويب وارد مقابل مفتاح مركب – المستودع، معرف المشكلة، الفاعل، نوع الحدث – وتتحقق منه مقابل نافذة إزالة تكرار TTL (بشكل أساسي نافذة منزلقة لبصمات الأحداث الأخيرة)، وخلف ذلك، رسم بياني حي للعلاقات يعين ملكية المهام، وروابط PR، والمشاركين في السلسلة، وأنماط النشاط الأخيرة. أنت تقوم أساساً ببناء نموذج قراءة لحالة عمل الفريق بأكمله، يتم تحديثه في الوقت الفعلي تقريباً، والاستعلام عنه عند كل إشارة واردة. تلتقط طبقة إزالة التكرار التكرارات الواضحة. يجيب الرسم البياني على السؤال الأصعب: "هل هذا ذو صلة بك تحديداً، الآن؟"
تتعامل حلقة التصنيف الأساسية مع الحالات الواضحة بشكل جيد، وهذا وحده يقلل الضوضاء بشكل كبير – لكن الإشارات الغامضة حقاً (حيث لست واثقاً بما يكفي للقمع ولكن لست واثقاً بما يكفي للإظهار أيضاً) لا تزال مشكلة مفتوحة. نحن نجرب تجميعها في ملخص "ربما"، لكنني لن أتظاهر بأننا أتقناها.
ما الذي يتغير عندما يتوقف التدفق الهائل
الشيء الذي لم أتوقعه – اعتقدت حقاً أن الفائدة ستكون مجرد "تنبيهات أقل" – هو مدى التغيير العميق في علاقتك بأدواتك عندما تتوقف عن الصراخ في وجهك.
عندما يكون كل إشعار مهماً، فإنك تطور هذا القلق المنخفض الدرجة بشأن الأعداد غير المقروءة. شريط Slack الجانبي بأسماء قنواته الغامقة. جرس GitHub. صندوق وارد Linear. أنت تتحقق بشكل قهري، ليس لأنك تتوقع أي شيء عاجل، ولكن لأن تكلفة تفويت شيء ما تبدو أعلى من تكلفة التحقق من 50 شيئاً يتبين أنها ضوضاء. اعتدت على التبديل (alt-tab) إلى Slack بين كتابة توقيع الدالة وجسمها. لم يكن قراراً واعياً – مجرد رد فعل، بالطريقة التي تتحقق بها من مراياك عند الضوء الأحمر.
يمكن القول إن المقاطعة الذاتية الاستباقية أسوأ من الإشعارات نفسها، لأنك تكسر تركيزك قبل وصول أي تنبيه. أنت تعيش في حالة من الاهتمام الجزئي الدائم، ويمكنك أن تشعر بذلك في الكود الذي تكتبه – مراجعات ضحلة، خيارات معمارية أكثر أماناً، مسار المقاومة الأقل بدلاً من النهج الصحيح بالفعل، لأنك لا تثق في أنك ستحصل على 45 دقيقة متواصلة للتفكير في الأمر.
عندما يتوقف التدفق الهائل – عندما تثق في أن الإشارات المهمة ستجدك وأن الضوضاء لن تفعل ذلك – يتلاشى هذا الانعكاس. ليس على الفور، لأن العادات القديمة عنيدة. ولكن في غضون أسبوعين تلاحظ أنك تقضي فترات أطول في محرر الكود الخاص بك دون التبديل القهري. تبدأ في إنهاء الأفكار. تكتب كوداً أفضل، ليس لأنك أصبحت فجأة أكثر ذكاءً، ولكن لأنك توقفت عن التطوع لـ 30 عملية تبديل سياق في الساعة نيابة عن نظام إشعارات لم يطلب منك ذلك أبداً.
cutting through inbox and channel noise notification fatigue the Slack notification strategy for busy teams توقف عن الغرق في الإشعارات. يصنف Sugarbug كل إشارة من Linear و GitHub و Slack حسب الصلة – ويُظهر فقط ما يحتاجك بالفعل.
س: هل يقلل Sugarbug من الإشعارات المرهقة من Linear و GitHub و Slack؟ ج: نعم. يتصل Sugarbug بـ Linear و GitHub و Slack عبر واجهة برمجة التطبيقات ويصنف كل إشارة حسب الإلحاح والصلة. بدلاً من إعادة توجيه كل إشعار، فإنه يُظهر فقط الإشعارات التي تتطلب انتباهك – مما يقلل عادةً من مئات التنبيهات اليومية إلى الحفنة التي تحتاجك حقاً.
س: هل يمكن لـ Sugarbug تحديد أولويات إشعارات PR في GitHub بناءً على ما أعمل عليه؟ ج: يبني Sugarbug رسم بياني معرفي لمهامك، و PRs، ومحادثاتك. إنه يعرف أي PRs تتعلق بعملك الحالي ويُظهر طلبات المراجعة، وتعارضات الدمج، وإخفاقات CI لتلك أولاً – بينما يحفظ الباقي بهدوء.
س: كيف يختلف Sugarbug عن إعدادات الإشعارات المدمجة في Slack؟ ج: تتيح لك إعدادات Slack كتم القنوات أو تعيين الكلمات الرئيسية، لكنها لا تستطيع فهم السياق عبر الأدوات. يقرأ Sugarbug عبر Linear و GitHub و Slack معاً، لذلك فهو يعرف أن سلسلة Slack حول PR قمت بتأليفه هي عاجلة حتى لو كانت في قناة قمت بكتمها.
س: ما هي التكلفة الحقيقية لكثرة الإشعارات للفرق الهندسية؟ ج: تشير أبحاث جلوريا مارك في جامعة كاليفورنيا في إيرفين إلى أن استعادة التركيز العميق بعد المقاطعة تستغرق حوالي 23 دقيقة. وراء التنبيهات نفسها، فإن سلوك التحقق القهري الذي تخلقه يجزئ التركيز المستمر الذي يتطلبه العمل الهندسي المعقد.
إذا تجاوزت إشعارات فريقك الهندسي الخط الفاصل بين "البقاء على اطلاع" و "البقاء قلقاً"، فربما تكون هذه علامة على أن البنية بحاجة إلى إصلاح، وليس تفضيلات الإشعارات الخاصة بك.