دراسة حالة لمؤلف إضافة هاوٍ

أتفهم ذلك تمامًا.[1] أنا أعشق Discourse حقًا، وكتبت هذا المنشور لأنني أريد استمرار نجاح Discourse.

شيء تعلمته هو أن المجتمعات لا تهتم بالتغيير، لكنها تكون أكثر انفتاحًا عليه إذا شعرت بأنها تملك القدرة على التأثير. هناك طرق لا حصر لها لمنح الناس هذه القدرة. على سبيل المثال، يمكن تحويل الدليل إلى منشورات ويكي حتى يتمكن أشخاص مثلي من تحديثها. كما أن تنفيذ خطة الإصدار المدعوم طويل الأمد (ESR) يساعد أيضًا لأنه يمنح الناس خيار عدم إجراء تغييرات على الفور.[2] كما أن قدرتي على كتابة تجربتي ورؤيتها من قبل الأشخاص الذين يديرون مشروع المصادر المفتوحة تساعد أيضًا. خاصة أن الأشياء التي اشتكيت منها تم إصلاحها بين عشية وضحاها. :wink:

في مقالة “هل الاستماع إلى المستخدمين ضار؟”،[3] كتبت كاثي سييرا:

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

نادرًا ما تأتي الابتكارات الحقيقية مما يقوله المستخدمون مباشرة.

كما قلت، لست مطور واجهات أمامية. لا أفهم حقًا سبب إجراء هذه التغييرات أو كيف ستفيدني.[4] وهذا مقبول إذا كانت هذه التغييرات ستجعل Discourse أفضل في النهاية.

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

  1. تجربة تطوير أفضل بكثير
  2. ستمكن من تحسينات كبيرة في الأداء في إصدارات Discourse المستقبلية

يبدو جيدًا، أعتقد؟ لم ألاحظ #1 بشكل خاص، و #2 يمكن أن تعني أشياء كثيرة. سيكون أكثر فاعلية بالنسبة لي شيئًا مثل (وأنا أختلق هذا تمامًا):

  1. عندما حولنا إضافات Discourse الرسمية، وجدنا أن ذلك قلل من X% من أسطر الكود. بوضع القالب في نفس الملف مع جافا سكريبت، يصبح الكود أسهل في الفهم والتعديل في المستقبل.
  2. قمنا بإعداد فرع لاختبار إزالة Handlebars تمامًا واكتشفنا أن هذا التغيير جعل تحميل الصفحة أسرع بنسبة X%. ليس هذا فحسب، بل رأينا تحسينًا محتملًا يمكنه القضاء على [مشكلة معينة أثارها المستخدمون].

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


  1. لدى OpenSSL ديناميكية مماثلة. لدينا شركة (حوالي 15 شخصًا) تبيع عقود دعم، ومؤسسة (10 أشخاص، بما في ذلك أنا) تهتم بالمصالح غير التجارية. تتأخر وثائقنا أيضًا. أثناء كتابة المنشور الأصلي، لاحظت أننا ما زلنا نشير إلى ميزات تم إزالتها الشهر الماضي. أعمل على طلب سحب (PR) لذلك. وقمنا أيضًا بإجراء بعض التغييرات التي انتقدها بشدة مشاريع تالية. ↩︎

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

  3. موقعها الإلكتروني لم يعد موجودًا على الإنترنت، لكن هناك أرشيف PDF. ↩︎

  4. ليس لأنني مهم جدًا في المخطط الكبير للأمور. أنا أتحدث عن نفسي كبديل لأشخاص آخرين يعتمدون على Discourse. أعرف نفسي أفضل من معظم الناس، بعد كل شيء! ↩︎