لهذا السبب تسمح لهم بالتقديم. إذا لزم الأمر، يمكن إلغاء الوصول. أما بالنسبة للثقة؟ حسنًا، هذا يعتمد على المجتمع. ![]()
ما الذي سمح لهم بالتقديم؟ لا حاجة للتفكير في الفئات القديمة. يجب أن يكون الجميع متساوين. إذا لاحظ شخص ما خطأ في النص وقرر إصلاحه، فهل يجب عليه تقديم طلب؟ أنا لا أعرف هذا المستخدم، ولا أريد منحه الوصول إلى كل المحتوى. ولماذا؟ إذا كان الإشراف المعتاد يحل جميع المشاكل المتعلقة بجودة المحتوى. علاوة على ذلك، مع تغيير المحتوى باستخدام markdown، سيواجه المستخدم صعوبات مقارنة بالمحرر المرئي المعتاد، فمن السهل ارتكاب خطأ. لا يمكن لأحد أن يضمن أن المستخدمين لا يرتكبون أخطاء.
يجب أن يكون الأمر أشبه بـ github. يمكن لأي شخص اقتراح تغييرات، ولكن لا يمتلك الجميع وصولاً كاملاً.
إذا لاحظ شخص ما وجود خطأ، فيمكنه إرسال رسالة إلى المجموعة التي تحتفظ بقاعدة البيانات. هذا يقلل من الحاجة إلى الإشراف المكثف على قاعدة المعرفة. إذا أراد شخص ما أن يصبح مسؤول صيانة نشطًا، فيمكنه ذلك؛ وإلا فإنه يقدم التغيير إلى المجموعة التي تحتفظ بالويكي.
في تجربتي، لن يبلغ أحد عن خطأ. هناك الكثير من الإجراءات للمستخدم العادي. من السهل بما فيه الكفاية إصلاح أو إضافة محتوى. لا يريد المستخدم الانضمام إلى مجموعات أو أن يصبح مشرفًا، بل يريد فقط إصلاح أو إضافة محتوى. يريد القيام بذلك مرة واحدة. افترض هذا المنطق. لا يريد جميع المستخدمين أن يكونوا أعضاء نشطين في المجتمع. لكن يمكنهم المساهمة. لقد ذكرت بالفعل GitHub كمثال.
إذًا، هذه مشكلة مجتمعية مع المجتمع المذكور. من السهل جدًا إضافة زر/رابط لـ “مستخدم عادي” لتقديم تغيير مقترح لهذا المنشور/الموضوع، مع وجود زر/رابط ثانوي إذا أراد هذا المستخدم العادي الانضمام إلى فريق من المشرفين.
النقطة هنا هي أنه إذا كانت هناك مشكلة مع الأشخاص الذين يفسدون قاعدة معارفك ولا ترغب في الاضطرار إلى استخدام إشراف مكثف؛ فإن وجود مجموعة من المشرفين الذين يمكنهم إجراء التغييرات منطقي. في عالم مثالي، لن يحتاج المرء إلى القلق بشأن الأشخاص عديمي الضمير الذين يسببون مشاكل غير ضرورية. ![]()
![]()
![]()
في الوقت الحالي، يتم إرسال إشعار تعديل إلى مالك الموضوع وأي شخص يتابع الويكي عند حدوث أي تعديل، لذلك أعتقد أنه من السهل جدًا تتبع التغييرات اعتمادًا على كيفية إعداد الإشعارات الخاصة بك.
ومع ذلك، شخصيًا، لست ضد فكرة إرسال التعديلات إلى قائمة انتظار المراجعة / نوع ما من قائمة انتظار مراجعة جماعية قبل النشر. لا أعرف مقدار العمل الذي سيتطلبه ذلك للبناء؟
شكراً لتفهمك. أنا أقوم بإنشاء مجتمع تقني، ولا أحد يريد أن يكتب المستخدمون عن طريق الخطأ بعض الهراء. أهم شيء يميز أي قاعدة معرفية هو دقة المعلومات. هذا هو أساس كل شيء. بخلاف ذلك، لا فائدة من القيام بذلك. الإشراف السليم على قاعدة المعرفة لا يقل أهمية عن المحتوى نفسه.
في الواقع، أنت تبحث عن تعديلات مشتركة إذن. لأنه ما لم تكن تعرف المحرر مسبقًا وتقوم بالإشراف المسبق، فعندما تعمل الويكي مع الإشراف اللاحق، ستواجه صعوبة في تحقيق ذلك:
لا. هذا مختلف تمامًا
كيف يختلف الأمر؟ أنت لا تسمح بالتحرير المجاني، لأنك لا تثق في أن الزائر العشوائي يعرف ويمكنه ذلك. لهذا السبب تريد استخدام حقوق تحرير محدودة بحكم الأمر الواقع عبر الإشراف المسبق. لديك متطلبات للجودة والمعرفة،
أنت تسميها ويكي بموافقة الموظفين. ومع ذلك، فهو تحرير مشترك لمجموعة - ولهذا لديك بالفعل أدوات وإعدادات.
لقد شوهت كلماتي. أريد أن يتمكن الجميع من تعديل قاعدة المعرفة، بما في ذلك المستخدمون العاديون وغير الرسميين. للقيام بذلك، يجب أن يكون هناك وظيفة تتكون من وظيفة واحدة: قبول التغييرات أو رفضها. هذا يكفي
من الناحية العملية، كيف ستكون حالة قائمة الانتظار إذا كان هناك أكثر من تعديل واحد في انتظار؟ في الوقت الحالي، يتم حفظ التعديل في وقته ويكون الويكي جاهزًا للشخص التالي لإجراء تعديل (وإذا حاول شخصان التعديل في نفس الوقت، فستحصل على بعض رسائل “x يكتب” وبعض التحذيرات عند الحفظ، على ما أعتقد). هل سيحتاج الويكي إلى القفل حتى يتم قبول/رفض الموافقة الواحدة؟
هذا ليس صحيحًا. لقد كتبت ذلك.
أنت لا تحب الإجابة لأنك قررت أنها يجب أن تمر عبر الويكي. هذا وضع مختلف تمامًا عن التحريف.
نظرًا لأن هذا نقاش ميتا حول الويكي، فأنا نوعًا ما ضد التعديل المسبق الأكثر صرامة لأنه توجد أدوات مناسبة بالفعل. إذا لم يتبع الويكي القواعد العامة، فيجب تغيير ذلك، إن أمكن. الويكي هو مجرد موضوع آخر بعد كل شيء. لكن الويكي لا يحتاج إلى أدوات تعديل أكثر صرامة من المواضيع الأخرى.
وفكرة الويكي ليست محدودة بحقوق التحرير. يجب أن تكون متاحة للجميع، ولكن بدون قتال على طريقة الغرب المتوحش، لذلك يجب أن يكون هناك تحكم أساسي. وهو موجود بالفعل.
أعتقد أنك قد أسأت الفهم. إنه يدعم بالفعل الإشراف على منشورات Free-4-All.
الحقيقة البسيطة هي أن Discourse Meta يدعم كلا الطريقتين ويجب على كل مجتمع أن يقرر أي طريقة تعمل بشكل أفضل. سواء كان ذلك إصلاحات إشرافية لاحقة أو عملية موافقة استباقية باستخدام خيارات أمان الفئة لحقوق المجموعة لقواعد المعرفة المخصصة.
أي من الطريقتين تعمل بشكل جيد وكما هو الحال مع التخصيص المفتوح لـ Discourse Meta، يمكن القيام بذلك.
قاعدة المعرفة والمناقشات المفتوحة شيئان مختلفان تمامًا. في قاعدة المعرفة، دقة المعلومات هي الأولوية الأولى، ويمكنك كتابة أي شيء في المناقشات.
بشكل أساسي، سيكون هناك شكل من أشكال تفرع الإصدارات خلف هذا، وعمليات الدمج وما إلى ذلك. البديل هو كما تقول مع القفل، وهو أمر غير مفضل حقًا.
بدلاً من ذلك، هل سيكون من الممكن تقديم النسخة المعدلة كرسالة خاصة للمؤلف، ويكون المؤلف هو من يمكنه دمج التعديل أو رفضه؟ يمكن أن تكون العملية مثل:
- أقوم بتحرير الويكي
- أنقر على إرسال
- يحصل المالك على رسالة خاصة بالإصدار الأحدث من الويكي
- يمكن للمالك قبول الإصدار الجديد - سيحل هذا محل الإصدار الأصلي بالإصدار الموجود في الرسالة الخاصة
يمكن للمالك أيضًا الرد على الإرسال في الرسالة الخاصة واقتراح تعديلات أو رفضه تمامًا. لا يزال بإمكان المستخدم تعديل إرساله عن طريق تحرير الرسالة الخاصة - يظل هذا كـ “فرع” ويتم “دمجه” فقط عندما يقبله المؤلف الأصلي. عند قبوله، يتم أرشفة الرسالة الخاصة (ربما يتم تحويلها أيضًا بطريقة ما إلى تنسيق أكثر شفافية؟)
لاحظت أن مستخدمي invision يطلبون أيضًا من المطورين إضافة وظائف مماثلة منذ عام 2015. لذا فهذه المشكلة ليست فقط لمستخدمي discourse
https://invisioncommunity.com/forums/topic/423493-wiki-like-editing-is-useless-at-this-moment/?tab=comments
Bump on this one. @SystemZ I think this is an important feature to give more support for that hybrid community/wiki sort of setup. Also happy to contribute to code to get something across the line.
أنا أستخدم Discourse كأساس لمجتمع لتعلم اللغات. لدينا قسم للمقالات يمكن للأشخاص المساهمة فيه، ومع ذلك، حتى المتعلمون للغة في المستوى المتوسط يمكن أن يكونوا واثقين بشكل مفرط في تقييمهم لمهاراتهم وينتهي بهم الأمر بنشر معلومات مضللة.
ميزة كهذه ستكون رائعة للسماح لنا بإضفاء الطابع الديمقراطي على تحرير محتوى الويكي على موقعنا مع التأكد من الحفاظ على دقة معلوماتنا. كما أنها تمنع سوء الاستخدام المحتمل لميزة التحرير.
لو كنت شخصًا ثريًا ولدي منزل صيفي لكنت سأرسل رشاوى إلى Discourse لتنفيذ ذلك. للأسف، أنا مجرد شخص عشوائي في مكان عشوائي. ![]()
أعتقد أيضًا أنها قد تكون ميزة جيدة. لقد نقلنا وثائقنا من Docusaurus إلى Discourse وهناك كنا نستخدم git للتحكم في الإصدارات والموافقات. الآن، لا نريد أن يتمكن الجميع من تعديل المنشور الأول. ولكن للموافقة، نريد نحن المشرفين مراجعة التعديلات التي يجريها الكتاب (مجموعة مخصصة).
في الوقت الحالي، أنا ببساطة أثق في الكتاب لنشر تغييراتهم أثناء التحقق من إشعارات “التعديل” التي أتلقاها من هذا الموضوع لاحقًا.
