عند الرد على هذا الموضوع، يرجى مراعاة أن الفكرة ليست تقديم حل لمرة واحدة، بل توفير نهج مثير للاهتمام لمجتمع البرمجيات الحرة للتكامل مع أدوات التطوير خارج Github. يتم إعطاء الأولوية لـ Forgejo لأنه أصبح الخيار الأول خارج Github و Gitlab، على سبيل المثال، يعمل في Codeberg.org. ولكن يمكن أيضًا النظر في SourceHut لأنه سيكون واجهة أمامية رائعة لهذا المسبك المصغر القائم على البريد الإلكتروني للمتسللين.
في الأصل، كنت أعتزم أن يكون هذا الموضوع في #marketplace، حيث أردت من شخص ما أن يأخذ ملحق التذاكر، ولكني أدرك أن هناك حاجة لمناقشة مسبقة قبل أن يحدث ذلك.
على وجه الخصوص، أود أن أعرف كيف تستخدم Discourse بالاشتراك مع، أو كبديل لـ، متتبع المشكلات الخاص بك أو مدير مشروعك. نرحب بتعليقات فريق Discourse!
نعم، يمكن أن يكون توسيع أو استخدام المكون الإضافي Assign مفيدًا. نظرًا لأن @angus مشغول في مكان آخر، فقد أردت أيضًا اختبار المياه ومعرفة ما إذا كان هناك شخص مهتم بالقيام بمثل هذا العمل. مع استمرار منح NGI Zero، يمكن تمويل هذا العمل.
لقد نشرت اقتراحًا مشابهًا لـ Forgejo نظرًا لأن لديهم مناقشة حول استخدام متتبع المشكلات كمساحة للنقاش. أعتقد أن تكامل Discourse سيجلب أفضل ما في العالمين.
من ذاكرتي، ستكون المواصفات الوظيفية كالتالي:
دعم مستودعات متعددة
(ربما منظمات متعددة)
إنشاء مواضيع تلقائيًا عند إنشاء المشكلات
(ربما يقتصر على المشكلات المصنفة كمناقشة)
إنشاء مشكلة تلقائيًا عند إنشاء موضوع مصنف
(ربما كتذكرة)
دمج المستخدمين عن بُعد إما من خلال تسجيل الدخول الموحد (SSO) (مثل Oauth2) أو ActivityPub (إذا كان مكون ActivityPub الإضافي موجودًا)
توفير لوحة تحكم بسيطة على Discourse
مع إمكانيات التصفية
ربما مع دعم kanban
بالطبع، سيتطلب هذا المزيد من المناقشة والتنقيح قبل أن نتمكن من التوصل إلى مشروع مناسب.
أوه! لقد نشرت للتو Using discourse to track issues? اعتقدت أن هذا كان شيئًا بالفعل.\n\n سأكون على استعداد لاستخدام مثيل Discourse الخاص بي لنمذجة أي أفكار أو اقتراحات.
نظرًا لأن المشروع لديه مشاكل طويلة الأمد مع سلاسل المناقشة الطويلة، أعتقد أنني سأقوم بإنشاء بعض الفئات والمواضيع على خادم Discourse الخاص بي ومنحنا فرصة للعمل من خلال بضع دورات حتى نتمكن من تحديد المتطلبات.
يبدو أن إضافة التذاكر قد توقفت وتعاني من بعض الأخطاء البسيطة التي من غير المرجح إصلاحها دون تدخل أكثر دقة. ومع ذلك، أنا مهتم أكثر باستخدام خطافات الويب (web hooks) والتكامل مع Forgejo، حيث أن هذا هو الغرض منها وتدعم تكامل التعليمات البرمجية. ولكن يبدو أن مجتمعي Discourse و Forgejo قد تجاهلا الاقتراح.
لقد واجهنا عددًا من تعارضات الطبقة 9 من OSI (السياسة)، لذلك لم نحرز أي تقدم. ومع ذلك، سأنظر إلى الروابط من @merefield ( ) باهتمام كبير لأنه حتى الآن يبدو أنه يفهم الأمر حقًا.
في أخبار أخرى، يقوم مجتمع #fedora بإيقاف استخدام forge الخاص بهم ويبحث في طرق محمولة لدمج سير العمل في مضيف git المفضل (forgejo، codeberg، إلخ). هناك اهتمام كبير بتقليل الاعتماد على github.com، لأسباب.