كيف تكتب release notes يقرأها الناس

لكتابة release notes يقرأها الناس فعلًا: إدخال واحد لكل تغيير يراه المستخدم، وقدرة القارئ الجديدة أولًا، وسطر ثابت للنسخة والتاريخ، ورابط واحد إلى الصفحة التي تشرح. القصير أفضل. الـ release notes إعلان عن نسخة، وليست سجل تغييرات ثانيًا.

معظم الـ release notes تفشل لسبب عادي. تكتب ما فعله الفريق، بالترتيب الذي فعله به، وبالأسماء الداخلية للفريق. القارئ يريد معرفة شيء واحد: هل أستطيع اليوم فعل شيء لم أستطع فعله أمس؟ اكتب لهذا الشخص، وسيرتب الشكل نفسه تقريبًا.

لماذا تتحول release notes إلى سجل تغييرات

سجل التغييرات سجل متراكم. والـ release notes إعلان قصير يخص نسخة واحدة. يختلطان لأن الاثنين يُكتبان بعد النشر نفسه، بواسطة الشخص نفسه، من قائمة المهام نفسها. عندما تصبح القائمة هي المخطط، يتحول الإعلان إلى يوميات تنفيذ.

يلخص Keep a Changelog الفرق في سطر واحد: سجل التغييرات للناس لا للآلات، وسكب رسائل الالتزام ليس سجل تغييرات (keepachangelog.com، اطُّلع عليه في 2026-10-18). الاختبار نفسه ينطبق على الـ release notes. إذا كان الإدخال لا يُفهم إلا لمن يعرف الاسم الداخلي للخدمة، فهو ليس جاهزًا للقارئ.

التغيير الذي لا يراه المستخدم يذهب عادة إلى سجل التغييرات، لا إلى الإعلان.

أجزاء إدخال release notes الأربعة

كل تغيير مرئي يجيب عن أربعة أسئلة بهذا الترتيب: ما الذي تغيّر، ومن يتأثر، وما الذي على القارئ فعله، وأين يقرأ المزيد. الأولان جملة لكل واحد. الثالث غالبًا «لا شيء»، وهذا مقبول. الرابع رابط واحد، لا فقرة شرح.

الترتيب يطابق طريقة المسح السريع. يقرأ الشخص أول كلمات كل سطر، ويتوقف عند السطر الذي يبدو معنيا به، ثم يقرر النقر. «أعدنا هيكلة خدمة الفوترة» لا يعطي سببًا للتوقف.

القالب الذي يمكن نسخه

هذا هو المخرج كله. ضع الترويسة الثابتة في الأعلى، ثم كتلة لكل تغيير. يمكن حذف العناوين الصغيرة إذا كان الجمهور يعرف الشكل، لكن لا تغيّر الترتيب.

## 2026-10-18 · v1.4.0

**جديد**
- تصدير ملف تعريف المنتج بصيغة CSV. متاح في كل الخطط. لا حاجة إلى تفعيل.
  التفاصيل: /help/export-product-profile

**محسّن**
- إرسال الأدلة يحتفظ الآن بتاريخ آخر فحص. لا إجراء مطلوب.

**مُصلح**
- لم تعد قائمة الإطلاق تُعاد إلى الصفر بعد تحديث الصفحة.

**إجراء مطلوب**
- إذا ربطت نطاقًا مخصصًا قبل 1 أكتوبر، فأعد فحص سجل DNS.
  التفاصيل: /help/custom-domain

قاعدتان تحفظان القالب في نسخة حقيقية. النسخة والتاريخ في الترويسة فقط، لا في كل سطر. كل إدخال يبدأ بقدرة القارئ، لا باسم المكوّن. «تصدير ملف تعريف المنتج بصيغة CSV» ينجح. «مُصدّر CSV v2» لا ينجح.

ما يدخل وما يبقى خارجًا

قرّر بنوع التغيير، لا بحجم الفرق في الشيفرة. إصلاح من سطر واحد يغيّر ما يراه القارئ يدخل. أسبوع من العمل الداخلي لا يغيّر شيئًا مرئيًا يبقى خارجًا.

تغيير السعر يستحق إعلانًا مستقلًا لأنه يغيّر قرارًا، لا شاشة. إذا دُفن في قائمة فات الجميع، ورسالة الدعم التي تأتي بعده تكلف أكثر من الإعلان الإضافي.

الأمن يحتاج حكمًا. قل ما يجب فعله وأي النسخ تأثرت. لا تنشر وصفة إعادة إنتاج قبل وصول الإصلاح إلى الجميع. وإذا لم تستطع قول الجزء الثاني بأمان، قل أقل واربط بالتنبيه الرسمي.

إعادة استخدام release notes واحدة في قنوات متعددة

اكتب مرة واحدة، وغيّر الوعاء لا الحقائق. صفحة سجل التغييرات تحتفظ بكل الإدخالات. رسالة داخل التطبيق تحتفظ بما يخص الشاشة الحالية. البريد يحتفظ بالإدخال الذي يغيّر قرارًا. بطاقة دليل أو منشور مجتمعي يحتفظ بما يفهمه قارئ جديد بلا سياق.

هنا تصنع الفرق نسختين من الحقيقة. أبقِ التاريخ ورقم النسخة متطابقين في كل مكان. إذا قال السجل إن v1.4.0 صدرت في 18 أكتوبر، فلا يمكن للبريد أن يقول «هذا الأسبوع» من دون ذكر التاريخ في مكان ما.

أين تنكسر release notes

الأخطاء متوقعة، ولكل واحد علامة ظاهرة.

1. الإعلان سجل التزامات. العلامة: أسماء خدمات أو فروع أو تذاكر. الإصلاح: أعد الكتابة من شاشة القارئ إلى الخلف.
2. كل نسخة «مثيرة». العلامة: الصفات الثلاث نفسها كل شهر. الإصلاح: احذف الصفة وأبقِ الفعل.
3. الإعلان يصل بعد صندوق الدعم. العلامة: يسأل المستخدمون لماذا تغيّر شيء قبل النشر. الإصلاح: انشر مع النسخة، لا بعد الشكاوى.

هناك خطأ رابع أصعب في الرؤية: الإعلان عن تغيير لا يجده أحد. إذا كانت القدرة الجديدة خلف ثلاث قوائم والإعلان لا يقول أين، فهو دقيق وغير مفيد. أضف المسار، أو لقطة شاشة، أو رابطًا إلى الصفحة التي تعرض المسار.

ما لم نقسه

لم نقس ما إذا كانت release notes الأفضل تغيّر الاحتفاظ أو الترقية أو حجم الدعم. لم نجد دراسة عامة يمكن التحقق منها تعزل هذا الأثر، ولن نخترع واحدة. ما يمكن قوله أضيق: الإعلان المكتوب بترتيب القارئ أسرع في المسح، والإدخال الذي فيه سطر إجراء ينتج ردودًا أقل من نوع «وماذا أفعل الآن؟». هذا حكم كتابة، لا نتيجة مقيسة.

أسئلة شائعة

كم يجب أن يكون طول release notes؟

بقدر ما تتطلبه التغييرات المرئية، ولا أكثر. تغيير واحد قد يكفي له ثلاثة أسطر. عشرة تغييرات قد تتسع في شاشة إذا كان كل إدخال جملة. إذا احتاج الإعلان إلى فهرس، فهو غالبًا صفحة سجل تغييرات، لا إعلان.

هل أكتب واحدة لكل عملية نشر؟

لا. اكتب واحدة لكل نسخة يمكن للقارئ ملاحظتها. عملية نشر لا تغيّر شيئًا مرئيًا لا تحتاج إعلانًا. عملية تغيّر نص زر تحتاج، لأن أحدًا سيلاحظ ويتساءل هل ذاكرته خانتْه.

هل تساعد في تحسين البحث أو إجابات الذكاء الاصطناعي؟

قد تساعد، لكن ليس بسبب كلمة «release». الصفحة المؤرخة التي تسمي الميزة والخطة والإجراء هي صفحة وصول مفيدة لمن يبحث عن الميزة لاحقًا. صفحة أرقام نسخ بلا أسماء ميزات تعطي محرك البحث مادة قليلة جدًا. لم نقس زيادة في الاستشهاد، فهذه حجة بنيوية لا وعد.

أين أنشر الإعلان؟

رابط أساسي واحد لكل نسخة، والتاريخ في الصفحة وفي الرابط إن سمح النظام. أعد نشر النسخة القصيرة في القنوات التي تحتاجها، لكن أبقِ الصفحة الأساسية وجهةً للرابط. خمس نسخ بخمسة تواريخ تعني خمسة مصادر للحقيقة.

الخطوة التالية

خذ آخر نسخة نشرتها وأعد كتابة إدخال واحد بالترتيب الرباعي. إذا صار أقصر وأكثر تحديدًا، فالقالب يعمل. وإذا طال، فأنت غالبًا تشرح التنفيذ بدل القدرة.

الـ release notes مدخل من مداخل سير عمل المحتوى. الكتابة نفسها التي تبدأ من القارئ تنطبق على خطة المحتوى التي تسلمها إلى كاتب، والمنطق نفسه ينطبق حين تكيّف وصف المنتج لكل قناة. عندما يكون الإعلان جاهزًا، انشره حيث يعيش المنتج، وأبقِ سير عمل المحتوى في مكان واحد حتى لا تبدأ النسخة التالية من صفحة بيضاء.