كتابة توثيق فعال لـ Discourse

:information_source: يتم حالياً مراجعة وتحرير وثائق Discourse لتتوافق مع دليل الأسلوب هذا. لا تتطابق جميع موضوعات الوثائق الحالية مع هذا الدليل - نحن نعمل على تحقيق ذلك بأقصى سرعة ممكنة.

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

المبدأ التوجيهي وراء دليل أسلوب هذه الوثائق هو مراعاة قراءك واحتياجاتهم عند كتابة الوثائق: ما الذي يريدون إنجازه؟ ما هو هدفك من تقديم المحتوى؟

:eyes: قائمة تحقق سريعة عند تطبيق دليل الأسلوب:

  1. وجود كتلة التعريف (Meta block) وصحتها
  2. العنوان موجّه نحو الإجراء
  3. جميع العناوين تستخدم حالة الجملة (sentence case)
  4. استخدام الوسوم والفئات الصحيحة
  5. هيكلية المستند منطقية

عند إكمال مستند، راجعه للتأكد من استيفاء جميع هذه المعايير.

يرجى الانتباه إلى إرشادات تنسيق النص التالية:


معلومات التعريف (Meta information)

  • يجب أن ينتمي المستند إلى فئة واحدة فقط من الفئات التالية:
    • استخدام Discourse
      • أدلة عامة للمستخدمين للمهام غير الإدارية
    • إدارة الموقع
      • الإعدادات، الإضافات، المحتوى، والإدارة العامة للموقع
    • التكاملات
      • أدلة لدمج منصات أخرى مع Discourse
    • العملاء المستضافون
      • أدلة ذات صلة فقط بالعملاء المستضافين
    • الاستضافة الذاتية
      • أدلة ذات صلة فقط بالمواقع المستضافة ذاتياً
    • أدلة المطورين
      • أدلة تقنية للتطوير فوق Discourse، بما في ذلك إنشاء السمات، مكونات السمات، والإضافات
    • المساهمة
      • أدلة للمساهمة في مشروع Discourse مفتوح المصدر
  • يجب أن ينتمي المستند إلى وسم واحد فقط من أنواع المستندات/الوسوم التالية:
    • #how-to
    • #explanation
    • #reference
    • #tutorial
  • قد يحتوي المستند على أي وسوم أخرى ذات صلة، بحد أقصى مطلق هو 5 وسوم في مستند واحد

كتلة التعريف (Meta block)

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

:bookmark: هذا دليل يصف جميع إعدادات الموقع المخفية المتاحة، وكيفية تمكينها، ولماذا قد ترغب في تعديلها.

:person_raising_hand: مستوى المستخدم المطلوب: مدير

:computer: الوصول إلى وحدة التحكم مطلوب

العناوين والعناوين الفرعية

  • اجعل عناوين المستندات موجّهة نحو الإجراء
    • غير صحيح: “كيفية تمكين العناوين التلقائية لمواضيع الدردشة”
    • صحيح: “تمكين العناوين التلقائية لمواضيع الدردشة”
  • لا يجب أن تكون عناوين المستندات طويلة جداً
  • لمواضيع “كيفية القيام بذلك” (how-to)، اجعل العنوان موجهاً نحو الهدف
  • يجب أن تكون جميع العناوين محددة وفريدة
  • لا تستخدم علامات الترقيم أو الأحرف الخاصة في عناوين المستندات، باستثناء الفواصل
  • لا تتضمن رموز تعبيرية (emojis) في عناوين المستندات
  • استخدم حالة الجملة (sentence case) للعناوين والعناوين الفرعية - وهذا يعني أن الكلمة الأولى فقط تبدأ بحرف كبير، بالإضافة إلى الأسماء الصحيحة وأي كلمات أخرى تُكتب عادة بحرف كبير
  • لا تستخدم علامة & في العناوين، بل استخدم الكلمة الكاملة (“and”)

إرشادات الكتابة العامة، النبرة، والقواعد النحوية

  • استخدم صوت الضمير الثاني (second-person) عند الإشارة إلى الأشخاص الذين يقرؤون المستند - أي استخدم “أنت”، وليس “نحن”
  • استخدم الصيغة الفاعلة (active voice) قدر الإمكان
    • غير صحيح: “يجب الضغط على الزر”
    • صحيح: “اضغط على الزر”
  • عرّف الاختصارات والاختصارات عند استخدامها لأول مرة، وإذا لزم الأمر، قدم رابطاً خارجياً يوفر المزيد من المعلومات
  • استخدم جمل قصيرة، وقسّم النص باستخدام فقرات أقصر، وعناوين، وقوائم
  • يمكنك استخدام **عريض** و*مائل* لتسليط الضوء على عبارات أو كلمات رئيسية، لكن لا تفرط في استخدامها
  • تجنب استخدام المصطلحات التقنية أو المصطلحات المتخصصة دون شرح - إذا كنت متردداً، فاعتمد على الشرح
  • استخدم لقطات الشاشة عند وصف واجهة مرئية، مثل عنصر واجهة مستخدم (UI)
  • لا توثق أو تحاول الكشف عن ميزات أو منتجات أو خدمات Discourse المستقبلية ما لم يُسمح بذلك صراحة
  • استخدم كلمات انتقالية مثل لذلك، على الرغم من، وعلاوة على ذلك.
  • استخدم الاختصارات الشائعة: إنها، ستفعل، أنت، نحن، دعنا
  • استنتج الخلود في الوثائق - تجنب كلمات مثل قريباً، جديد، الآن، الأحدث، وما إلى ذلك التي تصبح غير ذات صلة بسرعة
  • لا تُنسب الصفات البشرية إلى البرامج أو الأجهزة
    • مثال: “إذا مررت عدداً صحيحاً إلى هذه الواجهة البرمجية، فسوف تغضب وترفع خطأً”
    • مثال: “روبوتنا الذكي الودود والطموح سيساعد في حل جميع مشاكلك”
  • عند اقتباس نص (بما في ذلك من واجهة مستخدم Discourse)، استخدم “علامات الاقتباس”
  • عند اقتباس عنوان URL، استخدم أقواس خلفية
  • عند استخدام نطاق مثال، استخدم discourse.example.com
  • إذا كان ذلك مفيداً، يمكنك استخدام الرموز التعبيرية (emojis) في بداية الفقرة لتسليط الضوء عليها. لا تستخدم أكثر من اثنين أو ثلاثة منها في موضوع واحد. إليك بعض الأمثلة على الرموز التعبيرية التي يمكنك استخدامها:
    • :information_source: - ملاحظة معلوماتية
    • :mega: - إعلان أو إشعار
    • :warning: - رسالة تحذير
    • :exclamation: - معلومات مهمة جداً
  • تجنب:
    • الاستعارات أو الفكاهة غير الضرورية
    • المراجع الثقافية والإقليمية
    • فرض أوامر الإجراءات بنبرة متعالية - مثل يجب عليك الضغط على نشر أو تحتاج إلى الضغط على نشر
    • أن تكون مهذباً بشكل مفرط. على سبيل المثال، يرجى الضغط على نشر
    • استخدام علامات التعجب إلا عند الضرورة القصوى
    • كتابة الكلمات بحروف كبيرة حيث لا داعي لذلك
    • الإفراط في استخدام العبارات والضمائر نفسها

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

لوثائق المطورين والوثائق التقنية:
حافظ على نبرة مباشرة ودقيقة. استخدم نفس النبرة التي تستخدمها لوثائق المستخدم، لكن يمكنك افتراض مستوى أعلى من المعرفة التقنية لدى قرائك.

الهيكلية

  • اذهب إلى النقطة بسرعة - ابدأ بأهم شيء
  • أضف الكلمات المفتاحية المهمة في بداية المستند
  • اجعل خيارات القارئ والخطوات التالية واضحة
  • استخدم دائماً تنسيقاً خفيفاً (light markup) لكتابة الوثائق (تم دمج هذا بالفعل في Discourse مع Markdown-it).
  • نظّم وثائقك بتسلسل منطقي - ابدأ بنظرة عامة، تليها أقسام مفصلة، ثم ملخص أو خاتمة إذا لزم الأمر
  • استخدم العناوين والعناوين الفرعية لتنظيم محتواك، مما يسهل على القراء التصفح والعثور على معلومات محددة - استخدم تسلسلاً هرمياً تنازلياً في العناوين، بدءاً من h2، ولا تتخطى المستويات
  • قدم روابط لمواضيع أو أقسام ذات صلة داخل وثائقك - هذا يساعد المستخدمين على العثور على معلومات إضافية دون عمليات بحث غير ضرورية

الروابط

  • استخدم نصاً ذا معنى في الروابط
    • غير صحيح: “اضغط هنا لقراءة الدليل”
    • صحيح: “اقرأ الدليل
  • ما لم يكن تنسيق عنوان URL مهماً أو توضيحياً، لا تستخدم عنوان URL كنص للرابط - بدلاً من ذلك، استخدم عنوان الصفحة أو وصفاً للصفحة
  • اربط بالمواقع والمصادر الخارجية بدلاً من اقتباس أو إعادة كتابة الوثائق الموجودة
  • تأكد من أن المواقع التي تربط بها ذات جودة عالية
  • إذا كان الرابط يقوم بتنزيل ملف، اذكر ذلك صراحة - كما حدد نوع الملف الذي يتم تنزيله وتقديراً تقريبيًا لحجم الملف

الكود في الوثائق

  • استخدم كتل الكود مع تمييز بناء الجملة الخاص باللغة عند الإمكان لأمثلة الكود الكبيرة
  • إذا لم يكن المثال واضحاً بذاته، قدمه بجملة تمهيدية تثير المثال التالي - إذا كنت متردداً، فاعتمد على الشرح
  • يجب أن تتبع أمثلة الكود أفضل الممارسات لكتابة الكود للغة البرمجة ذات الصلة
  • استخدم كوداً مضمنًا (inline code) للتعبير عن سمات الكود الأساسية أو عندما لا تكون كتلة كود كاملة ضرورية، مثل:
    • أسماء وقيم السمات
    • أسماء الفئات
    • أسماء أدوات سطر الأوامر
    • أنواع البيانات
    • أسماء متغيرات البيئة
    • أسماء الملفات، امتدادات الملفات، والمسارات
    • المجلدات والدلائل
    • أفعال HTTP، أكواد الحالة، وقيم نوع المحتوى
    • أسماء وقيم معاملات الاستعلام
    • إدخال النص
  • عند استخدام نموذج نائبة في أمثلة الكود، أو الأوامر، أو نصوص أخرى، قم بتضمين شرح لما تمثله النائبة
    • اكتب شرحاً لأول مرة تستخدم فيها النائبة؛ إذا كانت هناك نائبات متعددة أو خطوات بعد الاستخدام الأول لتلك النائبة، يمكنك شرح النائبة مرة أخرى
  • وفّر طريقة سهلة للمستخدمين أو المطورين لنسخ الكود وتشغيله.
    • اعرض الناتج المتوقع، إما في قسم منفصل بعد مثال الكود أو باستخدام تعليقات الكود داخل مثال الكود
  • اكتب كوداً آمناً - لا تقم أبداً بتشفير كلمات المرور، مفاتيح واجهة برمجة التطبيقات (API Keys)، أو المعلومات الآمنة في الكود

الإجراءات والأدلة خطوة بخطوة

  • صغ الإجراءات بشكل متناسق، بحيث يمكن للقراء العثور عليها بسهولة عن طريق التصفح
  • استخدم إدخالاً رقمياً منفصلاً لكل خطوة
  • أضف الإجراءات التي تُنهي خطوة، مثل أزرار “موافق” أو “تطبيق”
  • إذا ظهرت التعليمات في نفس واجهة المستخدم حيث يحدث الإجراء، فعادة لا يكون من الضروري تقديم تفاصيل الموقع
  • إذا كنت بحاجة إلى التأكد من أن القارئ يبدأ من المكان الصحيح، قدم عبارة مختصرة في بداية الخطوة

إمكانية الوصول والشمولية

  • استخدم لقطات الشاشة، المخططات، أو الفيديوهات حيث تضيف قيمة، خاصة لشرح خطوات معقدة أو إظهار أجزاء من واجهة المستخدم
  • يجب استخدام الصور لدعم معلومات النص، وليس لاستبدالها
  • استخدم دائماً سمات alt للصور
  • قدم دائماً تسميات توضيحية أو نصوصاً منقولة للفيديوهات
  • استخدم صور GIF فقط إذا كنت تستطيع شرح المحتوى بالكامل في النص
  • اختر صوراً بسيطة وقصّ التفاصيل الزائدة
  • استخدم لغة بسيطة وتجنب المجازات أو التعابير التي قد لا تكون مفهومة عالمياً
  • ضع في اعتبارك أن مستندك سيتم استخدامه على مجموعة متنوعة من الأجهزة
  • استخدم لغة محايدة جنسانياً. لا تستخدم هو، له، منه، هي، لها، منها عند الإشارة إلى الأشخاص - للكتابة حول الضمائر، يمكنك:
    • إعادة الصياغة باستخدام الضمير الثاني (أنت)
    • إعادة صياغة الجملة لتصبح ذات اسم جمع وضمير جمع
    • استخدام كلمات شخص أو فرد
    • استخدام أدوات النكرة الـ، أ، أو بدلاً من الضمير
    • استخدام ضمير جمع مثل هم، لهم، أو، حتى لو كان يشير إلى فرد واحد
  • عندما تكتب عن شخص حقيقي، استخدم الضمائر التي يفضلها ذلك الشخص
  • كن شاملاً للهوية الجندرية، العرق، الثقافة، الدين، القدرة، العمر، التوجه الجنسي، والطبقة الاجتماعية - أضف مجموعة واسعة من المهن، الثقافات، البيئات التعليمية، المناطق، والبيئات الاقتصادية في الأمثلة
  • تجنب المحتوى السياسي - في الحالات التي يجب فيها تضمين محتوى سياسي، حافظ على الحياد
  • لا تصدر أي تعميمات حول الأشخاص، الدول، والثقافات، حتى لو كانت تعميمات إيجابية أو محايدة
  • لا تكتب محتوى متحيزاً أو تمييزياً ضد أي مجتمعات، خاصة الأقليات
  • تجنب المصطلحات النوعية المتعلقة بالأحداث التاريخية
  • تجنب استخدام المصطلحات والاستعارات المرتبطة بالعنف والعمليات العسكرية
8 إعجابات

@hugh / @SaraDev
أرى بعض عدم الاتساق هنا بشأن العناوين.

لدينا هذه الأمثلة:

ولكن بعد ذلك نقول هذا:

إذا قمت بتمرير المثال “الصحيح” عبر المحول، أحصل على هذا بدلاً من ذلك:

Enable Automatic Titles for Chat Threads

هل يجب علينا تحديث مثالنا ليتطابق؟

aside

لو كان الأمر متروكًا لي وحدي، لكنت أعتقد أننا سنختار حالة الجملة، ولست متأكدًا من سبب وجود “Chat Threads” مكتوبة بأحرف كبيرة في عنوان الموضوع الحالي، لذلك شخصيًا أفضل رؤية هذا:

Enable automatic titles for chat threads

لكن الاتساق أكثر أهمية في النهاية وسأفترض أن لديكم سببًا وجيهًا لاختيار التوصية الحالية.

إعجاب واحد (1)

هذه ملاحظة جيدة - لم أقم بهذا الربط، ولكن من السهل تحديثه. ومع ذلك:

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

3 إعجابات

ألاحظ أيضًا أنهم يقولون استخدام حالة الجملة للعناوين وال الرؤوس. (أنا في نفس الفريق).

يبدو أننا لا نحدد حاليًا تفضيلنا للعناوين. دعنا نضيف ذلك أيضًا أثناء قيامنا بذلك.

إعجاب واحد (1)

أتفق - سأضيف ذلك هنا لتحديده بشكل صريح.

إعجاب واحد (1)

حسنًا، بما أنني في حالة جيدة هنا…

أحب أن نقول هذا:

ولكن في الدليل، لدينا هذا المثال حاليًا:

رأيي هو أنه من غير الضروري كتابة “Hidden Site Settings” بأحرف كبيرة هنا. (appeal to authority)

إعجابَين (2)

أنا أقدر هذا الاحتكام :smile:

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

إعجاب واحد (1)

لقد أجريت بعض التعديلات على دليل الأسلوب هذا الآن بناءً على المحادثة أعلاه.

  • تم تغيير عنوان الموضوع إلى حالة الجملة
  • تم تغيير العناوين إلى حالة الجملة
  • تمت إزالة حالة الأحرف غير الضرورية (Syntax)
  • تم استبدال علامات العطف (&) في العناوين بـ “and”
  • تم استبدال الشرطات المائلة (/) في العناوين بفواصل أو حروف عطف

لم تتم مناقشة التغييرين الأخيرين - أخبرني إذا بدت زائدة عن الحاجة أو تتعارض مع الدليل (أو بدلاً من ذلك، ما إذا كان ينبغي التقاط تلك الإرشادات في الدليل).

إعجابَين (2)

أعجبني آخر اثنتين - فهما بالتأكيد تتماشى مع روح بقية الدليل، وتستحقان الإدراج في الدليل نفسه. سأضيفهما الآن.

إعجاب واحد (1)

أفترض أن الأعلام لتسمية المستندات بلغات أخرى هي استثناء.

إعجاب واحد (1)

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

علاوة على ذلك؟

في مرحلة ما، بدأنا (ربما أنا) في استخدام رموز مضمنة للإشارة إلى إعدادات الموقع. على سبيل المثال: “تمكين إعداد الموقع discourse connect”. قد يكون هذا هو النهج الصحيح، ولكنه يبدو نوعًا ما مطورًا.

قد يكون من المفيد استخدام اسم عنصر نائب متسق للإشارة إلى مواقع Discourse. ربما discourse.example.com؟ هناك بعض الوثائق هنا تشير إلى موقع Discourse باسم sitename.com. لقد أربكتني حقًا.


بعض النصائح العامة للكتابة: اقرأ ما كتبته كما لو كنت عضوًا في جمهورك المستهدف (انظر كيف تكون الاختصارات صعبة). تأكد من أن افتراضاتك حول المعرفة المسبقة للجمهور معقولة.

بقدر ما أقدر عدم وجود عدد كبير من مواضيع المستندات المنسوبة إليّ، فإن استخدام Discourse كمؤلف لجميع مواضيع مستندات الفريق يبدو باردًا بعض الشيء.

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

6 إعجابات

أهلاً سيمون! :blob_wave:

كنت سأرى كيف سيسير الأمر، ولكن نعم أنا على نفس المنوال، أحاول تجنب الاختصارات.

هاهاها، نعم… لن أستخدم أيًا من هذه الكلمات في المستندات، لئلا أكشف عن :face_with_monocle:.

بالتأكيد: Example Domains

هذه هي النقطة التي جئت لمناقشتها! :smiley:

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

إليك سبب اعتقادي بأنه مهم: يحتاج إنتاج الوثائق إلى أن يكون متاحًا لأكبر عدد ممكن من أعضاء مجتمعنا، بما في ذلك (خاصة؟) أعضاء فريق Discourse لدينا.

Discourse هو برنامج محادثة اجتماعي. وبعض الوثائق هي في الواقع محادثة مستمرة. إذا كنت أشارك ممارسة حول كيفية توجيه الأعضاء إلى مجتمعي، فسأرغب في تقديمي كـ “مالك” لهذا الموضوع، حتى أتمكن من الإجابة على الأسئلة وتوسيع الموضوع.

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

أيضًا، إذا أنتجنا وثائق خارج Discourse (تكامل أو إنتاج من تعليقات الكود أو أي شيء آخر)، فإن وجود “مستخدم وثائق” من المحتمل أن يكون أسهل كتفصيل تنفيذي. :thinking:

لا أعتقد أن هذا الدليل سيمنع الناس من إدخال صوتهم وشخصيتهم، واستضافة المناقشة. ولكن سيكون من الرائع إذا ساعد المزيد من الأشخاص على ممارسة التوثيق، الذين لولا ذلك لما فعلوا (ومن ثم يمكننا دفعهم ليكونوا أكثر شخصية!) :smiley:

3 إعجابات

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

أعتقد أن هذا النوع من الأشياء له آراء وتفضيلات مختلفة في كلا الاتجاهين، ولكن بالنسبة لدليل الأسلوب هذا، فإننا نتبع المعايير الصناعية المقبولة. مرة أخرى، تتفق كل من أدلة Google و Microsoft على أن الاختصارات الشائعة أفضل استخدامًا.

ومع ذلك، فقد قرأت بعض المشاركات التي تقترح أن استخدام الاختصارات السلبية (مثل “can’t”) قد يجعل الفهم أكثر صعوبة للمتحدثين غير الإنجليز. سنتعمق في هذا الأمر أكثر، وإذا لزم الأمر، سنقوم بتحديث دليل الأسلوب وفقًا لذلك.

لقد قمت بإزالة هذا المثال! :smile:

نعم - هذا شائع جدًا (ليس فقط في Discourse)، ولكني أتفق على أنه ليس صحيحًا تمامًا. سيكون استخدام علامات الاقتباس أفضل، لذلك أعتقد أنني سأجعل ذلك صريحًا في دليل الأسلوب.

هذه نقطة رائعة - سأضيفها إلى دليل الأسلوب!

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

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

كل هذه الملاحظات محل تقدير كبير :slight_smile:

إعجابَين (2)

فيما يتعلق بجزء metablock من الدليل. على الرغم من أن مواضيع التوثيق تحتاج إلى واحد وفقًا للدليل أعلاه، إلا أنه ليست كل المواضيع تحتوي على واحد [1] وهي ليست دائمًا متسقة، إليك بعض الأمثلة من بعض الأدلة التي وجدتها.

شخصيًا، أحب “جميع المستخدمين”.

لم أرغب في تغيير هذا في المواضيع قبل جمع بعض التعليقات :smiley:


  1. ربما يعتمد على سياق الموضوع؟ ↩︎

4 إعجابات

جارٍ العمل على جميع وثائق @Discourse وسيتم الانتهاء منها جميعًا على أمل أن يكون هناك وثيقة في وقت ما (:crossed_fingers:). نقطة جيدة حول عدم الاتساق على الرغم من ذلك. لست متأكدًا من أي وثيقة سنستقر عليها، لكننا بالتأكيد سنتأكد من اختيار واحدة والالتزام بها. :slight_smile:

4 إعجابات

يجب أن أضيف أيضًا أنه بالنسبة لأي شيء تراه يتضمن كتلة المعلومات الجديدة، فهذا يعني أنها مرت بـ “المرحلة الأولى” وهي في مرحلة المراجعة - لذا إذا قرأت شيئًا وظننت “هذا ليس صحيحًا” أو “هذا يفتقد بعض المعلومات” وتشعر بالكرم بما يكفي لتقديم بعض الملاحظات، فيرجى إضافة أفكارك إلى منشور. :heart: :slight_smile:

5 إعجابات

ما هو الغرض من معلومات مستوى المستخدم المطلوبة في الأعلى؟ اعتقدت أنها ستوفر معلومات حول ما إذا كانت الوثيقة ذات صلة بي أم لا. حتى أتمكن من قراءتها واتخاذ قرار “أنا لست xxx، لذا فهي غير ذات صلة”.
ولكن يبدو أنه يتم استخدامه بشكل مختلف، لأنه على سبيل المثال، يمكن للمستخدمين الذين تقل رتبتهم عن TL3 تعديل الويكي، لذا فهي ذات صلة بالآخرين أيضًا.

3 إعجابات

شكراً لتسليط الضوء على ذلك يا @Moin - تم تحديث هذا الموضوع لتصحيح مستوى المستخدم المطلوب.

فهمك لما هو الغرض من هذه المعلومات صحيح - يجب أن يوضح مستوى المستخدم أو نوعه القادر على أداء الإجراءات المشروحة في المستند.

إعجاب واحد (1)