هذه هي بالضبط المشكلة مع وثائق ديسكورس.
بقدر ما يمكن أن يكون “حسناً” للبعض البحث عن المواضيع، فهذه ليست وثائق. إنها تجعل المستخدمين، والأسوأ من ذلك، المسؤولين/المشرفين يضطرون للبحث عن المعلومات.
إعجاب واحد (1)
لا، ليست كذلك. وكان هذا ولا يزال أكبر نقص في Discourse. لا أعرف ما إذا كنت فظًا جدًا الآن أو شيئًا ما، ولكن الميل إلى التصرف هنا يركز كثيرًا على المطورين - إذا كنت لا تعرف يمكنك دائمًا قراءة المصدر على GitHub. ليس لدى CDCK الكثير من الدافع لبدء بناء وثائق جيدة للمستخدمين - بما في ذلك المسؤولين بالطبع - لأن هدفهم هو الشركات الكبيرة المستضافة. لذلك بالنسبة لهم كان الحد الأدنى من المساعدة المجتمعية للمتسلقين (الذين يقومون بجزء كبير من البحث عن الأخطاء واقتراحات تجربة المستخدم ؛)) كافيًا. باستثناء ذلك سنحتاج إلى استخدام العلامات بحرية أكبر …
كان كافيًا لم يكن مجرد خطأ إملائي أو مهارات لغة إنجليزية منخفضة المستوى. بدأ CDCK/الفريق في بناء وثائق أفضل وأنا متأكد تمامًا أنه بعد بعض الوقت ستكون الموضوعات الجانبية مثل هذه مجرد أصداء من الماضي.
4 إعجابات
بالنسبة لمجتمعات المطورين/المستخدمين، فإن “ديسكورس” (Discourse) أفضل بكثير من المتوسط. يبدو أن الأخطاء يتم تصحيحها بسرعة، ولا يتم تجاهل طلبات الميزات، خاصة إذا كان هناك حالة استخدام معقولة لها، والموظفون عبر الإنترنت (مدفوعون أو متطوعون، لست متأكدًا كيف يمكنك التمييز بينهما) جيدون جدًا وصابرون إلى حد ما في توجيهنا كجدد.
نعم، تحتاج الوثائق إلى العمل، لكن كتابة وثائق جيدة مكلفة وتستغرق وقتًا طويلاً. علاوة على ذلك، غالبًا ما لا يكتب المطورون وثائق جيدة لأنهم قريبون جدًا من المنتج، ولا يرونه كما يراه المستخدمون. القرب الشديد من الكود هو أيضًا مشكلة في اختبار المنتج، على الرغم من أن مجتمع المستخدمين في العديد من مشاريع المصادر المفتوحة يقوم بعمل جيد في اختبار الأشياء.
5 إعجابات
بالتأكيد. وكذلك كتابة كود جيد. غالبًا ما يكون العمل البشري الجيد مكلفًا. لكن الكود والوثائق مرتبطان ببعضهما البعض، وتبدأ الوثائق في أن تكون مكلفة في تلك المرحلة عندما لا يقوم بها أحد. بخلاف ذلك، فهي مجرد جزء أساسي من المنتج مثل البرمجة بما في ذلك الاختبار والتصميم وتجربة المستخدم/واجهة المستخدم وما إلى ذلك. لكن المطورين غالبًا ما يكرهون الوثائق لأنهم يكرهون القيام بها، ولا يوجد شيء جذاب فيها، بالإضافة إلى أنهم غالبًا ما يكونون سيئين جدًا فيها 
ولكن لأن أصحاب الشركات والمشرفين الآخرين هم مطورون مشابهون، فهم لا يهتمون بأن الرجال يختارون ما يفعلونه وما لا يفعلونه.
لكنني الآن أنحرف إلى أمور عامة جدًا وخارج الموضوع. لذا سأبتعد وأشير إلى Documentation لأنها تتطور حاليًا.
إعجاب واحد (1)
أتفق تمامًا مع هذا. أنا مطور لدي خبرة تزيد عن 20 عامًا في هذه المرحلة، حتى لو تحولت إلى هندسة المنصات في السنوات الأخيرة.
هذا واضح جدًا هنا عندما تطلب اقتراحًا ويأتي المطورون (أفترض؟ لا يمكنني رؤية سوى أنهم جزء من ديسكورس نفسه في ألقابهم) ويخبرونك أنه ليس كذلك ولن يكون كذلك لأنهم قرروا ذلك.
خارج الموضوع من هنا
لقد قلت هذا بالفعل: هناك فرق بين أن تكون متعصبًا في مجموعة التكنولوجيا الخاصة بك وأن تكون متعصبًا في منتجك. يجب أن يلبي منتجك حالات استخدام المستخدمين، في حدود المعقول، وليس أن يكون “كرتك وإذا لم يعجب الآخرون فيمكنهم الذهاب إلى مكان آخر”.
لقد بدأت بالفعل 5 مشاريع جديدة ولله الحمد كان لدينا شخص في مجتمعنا يعرف القليل عن Ruby وسيشرح لنا بعض الأساسيات لتدفق ديسكورس في الأيام القادمة حتى نتمكن من البدء في كتابة بعض الإضافات التي توفر الميزات التي نحتاجها. أهمها، جعل تعديلات الفئة ليست مزحة.
تم تطوير موضوع الدعم Users are receiving emails even when everything is set up to not send email notifications قليلاً، لذلك قمت بفصله إلى موضوعين جديدين في فئات أخرى لإعطاء كل منهما مساحة للتنفس. 
إعجابَين (2)
أعتقد أن هناك مشروعًا مفتوح المصدر واحدًا حيث يميل المطورون إلى العمل على الأشياء التي يهتمون بها، وليس على الأشياء التي قد تجعل الحياة أسهل لمستخدمي هذا المنتج. حالة الاستخدام هي دائمًا مسألة منظور، لدى مستخدمي المنتجات وجهة نظر مختلفة لحالة الاستخدام عن المطورين. يميل المطورون إلى التفكير في الأشياء التي يفعلها المستخدمون على أنها “مجرد بيانات إضافية”، وغالبًا لا يرون كيف يمكن لتغيير صغير أن يحدث فرقًا كبيرًا في سهولة الاستخدام. (لقد قمت بنصيبي من تطوير الأنظمة، وأنا متأكد من أنني كنت أمتلك هذا الموقف في بعض الأحيان.)
حتى الآن لا يمكنني القول إنني رأيت هذا النوع من المواقف مع تطوير Discourse، لكنني هنا منذ شهر واحد فقط.
أما بالنسبة لكوني قريبًا جدًا من المنتج، فأنا حاليًا أتابع التمارين في كتاب حول تطوير Ruby، استغرق تطبيق “hello world” البسيط مني 3 ساعات للعمل أمس، ويرجع ذلك أساسًا إلى أن الكتاب افترض معرفة ببيئة AWS IDE (cloud9) التي لم أكن أمتلكها بعد، لذلك كنت أنقر على شيء ما وسيقوم بإلغاء التغييرات التي قضيت 10 دقائق في كتابتها.
ثم كانت هناك مشكلة في عرض معاينة للتطبيق العامل على متصفحي، والتي يبدو أنها بسبب قيود الأمان التي فرضها كل من Firefox و Chrome على متصفحاتهما منذ آخر تحديث للكتاب. بعد حوالي ساعة من البحث على الويب عن حلول، نجحت في إضافة عنوان IP الخاص بجهاز الكمبيوتر المحمول والمكتبي إلى القائمة البيضاء، على الرغم من أنني ما زلت بحاجة إلى المرور بخطوة إضافية لعرض المعاينة.
إعجاب واحد (1)