هذا سؤال حول مدى إمكانية تخصيص وظائف منصة Discourse، وحجم العمل المتوقع لذلك.
أنا جزء من الفريق التقني في منظمة لكتاب خيال علمي محترفين، وتعتمد المنظمة بشكل كبير على برنامج منتديات كتبه مؤسسها الذي غادر المؤسسة منذ ذلك الحين. يعمل البرنامج حاليًا على بنية تقنية قديمة تعتمد على asp.net وخادم SQL، ونحن حريصون على الانتقال إلى منصة مختلفة.
تُعد إحدى أكثر الميزات شعبية في البرنامج هي وظيفة نقد القصص. حيث يمكن للمستخدمين رفع مستند يحتوي على عنوان وعدد كلمات. وهناك صفحة محددة تعرض جميع القصص التي تبحث حاليًا عن تغذية راجعة. يحتوي البرنامج على بعض عناصر التحفيز البسيطة: فرفع قصة يبدأ تلقائيًا موضوع نقاش، ويحصل أي شخص ينشر ردًا يتجاوز 750 حرفًا على نقاط. وعندما يتلقى المستخدم عددًا كافيًا من الردود، يمكنه منع أي شخص آخر من تنزيل الملف.
على صفحة تنزيل القصة، وبجانب اسم كل مستخدم، يمكن رؤية عدد نقاط النقد التي كسبها، وعدد النقاط التي حصلت عليها قصصه. ومن المفترض الحفاظ على توازن تقريبي بينهما، لكن النظام يعتمد كليًا على مبدأ الشرف؛ فبحسب علمي، لم يتم تحذير أي شخص قط عن تلقي نقود دون تقديم نقد. ويعمل النظام بشكل جيد جدًا (باستثناء البنية التقنية القديمة التي تعمل بشكل متعثر، كما هو موضح أعلاه).
في بعض الأحيان، يكون المستخدمون القدامى قد جمعوا عددًا مذهلًا من الرصيد، ونحن حريصون جدًا على نقل هذه الرصيد إلى المنصة الجديدة بدلاً من مسح نقاط الجميع.
سؤالي هو: إلى أي مدى سيكون من السهل دمج وظائف مثل هذه في منتدى Discourse؟ هل من المرجح أن يكون ذلك ضمن نطاق إضافة مخصصة (plugin)، أم أننا سنحتاج إلى تطبيق منفصل يتفاعل مع Discourse عبر واجهة برمجة التطبيقات (API)؟ سأقدر أي توجيه يمكنكم تقديمه.
أي رد يتجاوز 750 حرفًا يحصل على نقاط (من الممكن كتابة منشور غير نقد في موضوع نقدي بإدراج عبارة “هذا ليس منشورًا نقديًا”، لكنني لا أعتقد أنني رأيت ذلك مستخدمًا من قبل). إذا قام المؤلف بنشر رد يتجاوز 750 حرفًا في موضوعه النقدي الخاص، فلا ينبغي أن يُمنح أي نقاط.
يحدده مؤلف القصة. يمكنهم تحديد متى تلقوا ما يكفي من التعليقات على قصتهم.
نعم، الملف هو القصة (وثيقة Word أو ملف RTF أو أي تنسيق آخر). يوجد زر يمكن للمؤلف الضغط عليه في أي وقت لتعطيل التنزيلات الإضافية. يمكنهم الضغط عليه قبل أن يقوم أي شخص بتنزيل الملف إذا تغيرت نواياهم بشأن مشاركته.
بدلاً من محاولة تلخيص ذلك، إليك جملة SQL:
CASE WHEN WordCount < 1001 THEN 0.5
WHEN WordCount BETWEEN 5000 AND 9999 THEN 1.5
ELSE Round([WordCount] / 10000, 0) + 1 END
في الواقع، نادرًا ما يقوم الأشخاص برفع قصة تزيد عن 10 آلاف كلمة.
كما قال ريتشارد، أي شيء ممكن في الإضافات. ما تقترحه يتطلب على الأرجح بضع ساعات من العمل. قد تكون هناك بعض الاختصارات المتاحة لتناسب ميزانيتك. كما أن الشارات المخصصة قد تساعد أيضًا. بالتأكيد يمكنك كتابة الإضافة الجديدة ثم استيراد البيانات إليها عند إجراء عملية الترحيل.
لا تخلط بين نسخ النظام القديم وبين إنشاء أفضل نظام ممكن.
يمكنك استخدام الإضافة الجاهزة أو الوسوم لتعطيل وقت المراجعة.
إذا كان نظامك بالكامل مخصصًا، فإن أداة استيراد مخصصة تكلف عادةً حوالي 1500 دولار، وستحتاج على الأرجح إلى مبلغ مماثل تقريبًا للإضافة المطلوبة.
يمكنك أيضًا التوقف عن التمييز بين إسهامات القصة وإسهامات النقد، وإعادة استخدام ميزة الإعجاب في Discourse (مشاركة القلوب) لمشاركة الإسهامات. سيؤدي ذلك إلى جعل عملية الهجرة والتنفيذ مباشرة إلى حد كبير. لكن قد أغفل ميزة فصل الإسهامات؟
الفكرة هي أنك تساهم في المجتمع. إذا كان الآخرون يقرأون عملك ويعطونك ملاحظات حول كيفية تحسينه، فيجب عليك أيضًا قراءة أعمال الآخرين ومنحهم ملاحظات. سيكون رائعًا لو أمكن رصد ذلك باستخدام ميزة مدمجة في Discourse، لكنني لا أرى كيف يمكن ذلك.
يمكنك تشغيل استعلامات أكثر تفصيلاً حول الإعجابات التي يتلقاها المستخدمون. على سبيل المثال، يمكنك التمييز بين الإعجابات التي يتلقاها المستخدمون عند نشر قصص أو عند مشاركة ملاحظات من خلال استعلام الإعجابات على المنشورات الأولية واللاحقة في فئة القصص.
يمكنك بعد ذلك تصميم شارات (مع ألقاب المستخدمين والزخارف) سيتم منحها عند الوصول إلى أعداد معينة.
المشكلة، كما أفهمها، هي أن الإعجابات تُستخدم لإظهار شعبية المنشور، لكن النظام الذي أحاول الترحيل إليه يهدف إلى رصد ما إذا كان المستخدمون قد حققوا مستوىً أساسيًا من الجهد. لذا، لو أمكن أن يتم الإعجاب تلقائيًا مرة واحدة فقط بكل منشور في سلسلة قصصية يحتوي على عدد معين من الأحرف ولم يكن من تأليف مؤلف القصة، لكان ذلك مناسبًا لنظامنا. لكن يبدو أن هذا لا يتوافق جيدًا مع طريقة عمل الإعجابات.