Our project currently does synchronous IRC-based daily (M-F) Scrum standups for people who:
Are currently hacking on the project, and
Are available at the designated time.
This is less than ideal for a global team for various reasons, so I’m trying to think of how to re-create something like Flock but using Discourse. (The less tools, the better!)
For those not familiar with the report, the standard items mentioned include:
What was done the previous day
Plans for the upcoming day
Any issues blocking the person from proceeding with their work
I’ve been thinking about how to use the following features to make it happen:
Dedicated sub-category
Auto-close topics after N hours for the sub-category
Category-based topic templates
Specifying content in URL’s to pre-populate topics
The problem seems to be conceptualizing how this should look. Should each person create a topic for each day they have a report to make? A topic for each day that everyone contributes to? Ideally, someone could just go to a standard link or URL to create their report with minimal clicks.
Is this interesting to anyone else who would like to brainstorm a way forward? Thanks in advance.
Seems like a topic per “stand up” with multiple replies, one from each team member, would work fine. Use a unique category and put a category template in so people have some idea of what info to include.
I personally dislike any “mandatory meeting every day” scheme as we try to keep mandatory meetings to an absolute minimum.
also wondering @downey. Our volunteer community have:
Slack for our Dev’s (as they are there for work anyway)
Discourse for the rest of the community, which i plan to sync with the main channel in Slack so the devs are more a part of the community
Trello for project management.
Timetreeapp for a team calendar.
Github for issues, coding, and often conversations occur here also
It is definitely not optimal spreading the team across so many platforms. By design Discourse is the central hub, and ways of bringing our team closer into it would be very useful.
Our main issue is being a community of volunteers. Devs want to remain on the platform they use as standard for work, getting them to switch proved difficult. syncing the main channels between the two seems the best middle-ground.
I’ll add to the mix that the Edgeryders community look to be using Discourse quite effectively for documentation, but that requires switching to the Categories view homepage, which would take away from the interaction on our forum. I’m looking now to see if there’s a way to combine the two views on the homepage so we can have our documentation on Discourse
You can do some charting with the Discourse Graphviz plugin, but we usually avoid that. I have not seen a kanban plugin yet, but it does sound like an interesting idea for a theme component or plugin.
At Discourse we do our project management very differently to the traditional sense. We kick off TODOs on our dev instance or just directly assign topics from meta. In our weekly calls managers and team leaders help prioritise stuff. We are always shipping features so there is not “deadline in 3 months” we are working towards.
كيف تستخدمونه بالضبط، أو ما المقصود بـ “مؤقت” على وجه التحديد؟ أسأل لأننا حصلنا على ترخيص غير خاص مثلكم. الآن، النقاش يدور حول ما يجب أن يحدث وأين، أي الدردشة مقابل المنتدى.
“هناك كعك في غرفة الاستراحة” شيء عابر؛ فبمجرد انتهاء اليوم أو انتهاء الكعك، لا يحتاج أحد إلى معرفتها. مثل هذه الأمور يُفضل بكثير طرحها في أداة دردشة بدلاً من نشرها على منصات مثل discourse.
أي شيء له قيمة مشروعة على المدى المتوسط أو الطويل ليس عابرًا، لذا انشره في مكان يمكنك هيكلة المحتوى فيه لسهولة الوصول إليه مستقبلاً.
إذن، بعد أكثر من 4 سنوات، إليك لمحة عن كيفية استخدام فريق الذي أعمل فيه لمنصة Discourse في الاجتماعات اليومية القصيرة (Daily Scrums).
الإطار التنظيمي
فريق مشروع يعمل على مبادرات مفتوحة المصدر متنوعة بصفته “عملاء خارجيين”، لكنه يقع ضمن مؤسسة كبيرة.
تملك المؤسسة الأكبر أدواتها الخاصة للمُستندات، وإدارة المشاريع، والدردشة (Slack) وغيرها، وكانت تاريخياً غير راغبة في التحول إلى أدوات مفتوحة المصدر أو مشاركة أعمال المؤسسة علناً.
يجب أن يكون عمل هذا الفريق (أ) متوافقاً مع معايير الإبلاغ داخل المؤسسة الأكبر، و(ب) متاحاً للجمهور.
الإطار التقني
منتدى Discourse يتيح للفريق التفاعل مع الجمهور والأطراف الخارجية الأخرى.
فئة مخصصة لإدارة المشاريع يمكن للجميع قراءتها، لكن فقط الفريق يمكنه الكتابة فيها.
فئة فرعية بعنوان “الوقوفات اليومية” (Daily Standups) تابعة لتلك الفئة، يمكن للفريق فقط الكتابة فيها، ومُعدّة لإغلاق المواضيع تلقائياً بعد 23 ساعة.
قمنا بإعادة تسمية @discobot وتأكّدنا من حصوله على صلاحية الوصول إلى الفئة.
الحل (الحالي حتى الآن)
نستخدم Zapier للتحكّم الآلي، رغم التردد، لأن الإضافات المتاحة في Discourse أو الأدوات مفتوحة المصدر لم تكن كافية بعد.
من الاثنين إلى الجمعة، ينشئ Zapier موضوعاً جديداً في فئة “الوقوفات اليومية” باسم المستخدم الآلي، في وقت مُحدّد كل يوم، مع تضمين التاريخ الحالي في عنوان الموضوع.
يرسل Zapier تذكيرات عبر Slack (وهي ميزة تسمح بتأجيل التذكير أو تجاهله) لكل مشارك في الوقوفة في وقت يقارب بداية يوم عمله، مرفقاً برابط مباشر إلى موضوع الوقوفة الخاص بتلك اليوم.
يراقب Zapier المنشورات في تلك الفئة، ويستثني أي منشور صادر عن البوت، أو المنشور الأول لأي موضوع، كما يستثني الإغلاق التلقائي الذي قد يُفعّل عن طريق الخطأ. ثم يعيد صياغة المنشور بشكل جذري باستخدام أدوات Zapير لنشره في قناة Slack، محاكياً التنسيق الذي تستخدمه أعضاء فرق أخرى، مع إضافة رابط المنشور في السطر الأول من رسالة Slack (وهو التاريخ المُولّد تلقائياً). اضطررنا إلى فعل ذلك لأن إضافة تكامل الدردشة (Chat Integration Plugin) كانت تُنتج بيانات وصفية إضافية مزعجة للمستخدمين الآخرين في القناة.
في مرحلة ما، نضيف التاريخ يدوياً إلى إضافة التقويم (Events Plugin)، بحيث يظهر تقرير الوقوفة على الصفحة الرئيسية /calendar مع الأنشطة الأخرى.
نتأكد من أن إضافة تكامل الدردشة تستبعد (تُصمّت) فئة الوقوفة هذه لمنع تكرار نفس الوقوفة في مكان آخر ضمن مساحة عمل Slack المعنية.
قائمة أمنيات Discourse
ما سيكون رائعاً في يوم ما، حتى لا نضطر لاستخدام Zapier:
جدولة دورية للمنشورات التلقائية، مع إمكانية استخدام قوالب نصية تتضمن متغيرات مثل التاريخ.
إضافة تكامل الدردشة: إمكانية تحرير قالب ما يُرسل عبر إضافة تكامل الدردشة إلى قنوات مختلفة، بطريقة مشابهة لقوالب البريد الإلكتروني.
إضافة التعيين (Assign): السماح بتعيين عدة أشخاص لموضوع واحد، وتحديد فترات التذكير لكل فئة، والسماح بإجراء التعيينات عبر واجهة برمجة التطبيقات (API) أو كجزء من قالب الإنشاء التلقائي المذكور أعلاه.