قبل ثلاثة أسابيع، فتح شخص ما مشكلة في مستودع محرك التنسيق، وأصلح خطأ كنت أتجاهله لمدة شهر، وأغلق جهاز الكمبيوتر المحمول الخاص به دون أن يقول كلمة أخرى.
لم أحصل على أسمائهم مطلقًا على Dev.to. أنا أعرفهم فقط كمقبض GitHub. لقد ساهمت هذه العلاقات العامة في خدمة PostAll أكثر من أي شيء كتبته في ملاحظات الإصدار الأربعة الأخيرة مجتمعة.
هذه هي اللحظة التي أدركت فيها أنني أتعامل مع "البناء في الأماكن العامة" كبث في اتجاه واحد. انشر التصميم، وانشر الأرقام، وانشر الإخفاقات - وفقط... آمل أن يقرأها الناس. في الواقع لم أطلب أي شيء مرة أخرى. لذلك هذا المنصب هو السؤال.
إذا كنت قد قرأت أيًا من سلسلة PostAll - الغوص العميق في محرك التنسيق، وانهيار بوابة الجودة، والقياس بعد الوفاة - فأنت تعرف بالفعل أين يقف المشروع. 100 مستخدم تجريبي، محرك التنسيق مفتوح المصدر، وبوابات عالية الجودة تلتقط 50% من المخرجات منخفضة الجودة قبل شحنها. هذه المشاركة ليست خلاصة لذلك. إنها أربعة أشياء محددة أحتاج للمساعدة فيها، وما الذي ستحصل عليه بالفعل في المقابل.
الجزء الكبير التالي من خريطة طريق PostAll هو حلقة تعليقات الأداء - باستخدام بيانات المشاركة الحقيقية لضبط أوزان تسجيل بوابة الجودة ديناميكيًا بدلاً من الحدود الثابتة التي قمت بضبطها يدويًا منذ الإطلاق. لقد حددت هذا باعتباره العنصر الأكثر تعقيدًا والأكثر خطورة في خريطة الطريق لسبب ما: ليس لدي إجابة واضحة لكيفية تجنب مكافأة النظام لأي شيء كان النموذج جيدًا في ذلك الأسبوع، بدلاً من مكافأة ما يقرأ جيدًا بالفعل.
لا أريد أن أبني هذا في فراغ وأكتشف عند 500 مستخدم أنني أخطأت في إشارة التعليقات. إذا قمت بإنشاء أي شيء باستخدام نظام تسجيل يتكيف بناءً على الأداء النهائي - تصنيف التوصيات، ومرشحات البريد العشوائي، ونقاط جودة الإعلان، أو أي شيء - أريد أن أعرف كيف تجنبت (أو لم تتجنب) حلقات التعليقات التي تكافئ التلاعب بالمقياس على الهدف الفعلي.