اليوم، الجزء الأكثر إهمالاً في مجتمعنا هو الطريقة التي ندير بها المشكلات في مجتمعنا. للسياق، ندير مجتمعًا يقوده المنتج لمستخدمي المنتجات التي تبنيها شركتنا. يمكن أن تشير المشكلات بالطبع إلى الأخطاء، أو طلبات الميزات، أو المشكلات العامة — تمامًا مثل مشكلة GitHub، في الواقع. مشكلات عبر العديد من المتجهات المختلفة، مثل:
- مشكلات GitHub للكود/الأدوات التي نمتلكها (فريقنا) أيضًا
- مشكلات GitHub لسوق المصادر المفتوحة الخاص بنا (50+ مستودع/موضوع متزايد)
- مشكلات/ملاحظات/أخطاء عامة مقدمة حول منتجنا
- مشكلات داخل المجتمع نفسه (طلبات ميزات المجتمع، إلخ)
- مشكلات داخلية يتم تقديمها إلى فريقنا من وحدات أعمال أخرى (اليوم يرسلون هذه في Slack)
- مشكلات التوثيق
فيما يلي بعض أفكاري الحالية غير المنظمة حول إدارة هذا الأمر، لكنني فكرت في معرفة ما يفعله الآخرون في مجتمعاتهم في هذه الأثناء. إذن، كيف تفعل ذلك؟
- جزء من هذه المعادلة هو صراعك الأبدي الكلاسيكي بين الفئات مقابل العلامات من حيث التنظيم العام
- يشعر المستخدمون بالإرهاق بشكل عام بسبب عدد العلامات الممكنة، وقد لا يعرفون بطبيعتهم العلامة التي يبحثون عنها، أو في معظم الحالات لا يحاولون حتى وضع علامة. (ويتطلب وضع علامات متعددة منهم عادةً بذل الحد الأدنى من الجهد في وضع علامة)
- يمكن أن يساعد نموذج تقديم شامل في تخفيف عملية التقديم لهذا، بافتراض أنك اخترت أكثر من فئة واحدة أو اثنتين.
- ميزة قوية يمكن أن يضيفها Discourse هي ربط العلامات بحقول القائمة المنسدلة المطلوبة في قوالب النماذج التجريبية. بهذه الطريقة، على سبيل المثال، إذا كان سؤال القائمة المنسدلة هو “ما هو المتصفح الذي تستخدمه؟”، فستكون هناك علامات Discourse مرتبطة بالإجابات Chrome، Arc، إلخ.
- إحدى أكبر مشكلاتي لهذا هي “عرض إداري” لهذا الحل. أعتقد أن إضافة التذاكر (على الرغم من أن لقطات الشاشة معطلة، لذلك لا يمكنني تحديث ذاكرتي) قد تكون حالة استخدام جيدة لهذا.
- سأحتاج حقًا إلى التصرف بناءً على الكثير من البيانات الوصفية حول الموضوع في هذا الصدد. تاريخ التقديم، الحالة الحالية، العلامات المرتبطة، المعين(ين)، القدرة على إغلاقها، إلخ.
