آسفون إذا كان هذا هو المكان الخاطئ لنشر هذا، لكن هل هناك أي خطة لإدراج وظيفة مشابهة لـ GitHub Issue → Discourse migrator مرة أخرى؟ نود استخدام هذا في مشروع kubernetes وبعض مشاريع المصادر المفتوحة الأخرى التي أعرفها.
نغلق قضايا الدعم المنشورة على GitHub ونطلب منها إعادة النشر في منتدى Discourse. إذا كانت هناك إمكانية هجرة مدمجة، فيمكننا إضافة أمر بوت لنقلها تلقائيًا عند وضع علامة عليها وتوفير رابط للمستخدم.
أوه، يبدو أنك تبحث عن حل أكثر ديمومة هنا. يمكننا أن نقوم بفحص قائمة المشكلات بانتظام وننسخها ونغلقها.
أعتقد أن الحل الجيد من حيث سير العمل هو أن تقوم أنت بوضع علامة kind/support على الأمور، ثم إذا رأينا أي مشكلات دعم جديدة، سنقوم بإغلاقها على GitHub وفتحها على Discourse، مع إضافة منشور يحتوي على رابط لـ Discourse.
سيكون هناك الكثير من العمل اللازم لجعل شيء من هذا القبيل يحدث، سنحتاج إلى توسيع إضافة Discourse ↔ GitHub (GitHub - discourse/discourse-github · GitHub) التي نقوم بها حاليًا فقط بالارتباط العكسي. ولكن من الممكن بالتأكيد تحقيق ذلك.
لا أعتقد أن هذا يناسب إضافة مراجعة الكود، لذا سأقوم بإعادة الوسم.
هل هذا هو نوع العمل الذي تفكر في رعايته؟ إذا كان الأمر كذلك، يمكنني نقل هذا إلى صندوق بريد فريقنا.
أعتذر عن التأخير في الرد.
تنبيه: لست على دراية كبيرة بكيفية عمل إضافة discourse-github، لكن قد تكون هناك فكرة محتملة وهي أنه إذا كان بإمكان مشروع ما تشغيل استدعاء (webhook) يحتوي على رقم المشكلة المعني، فهل يمكنه جلب المشكلة/إنشاء منشور كمنشور رئيسي/ثم نشر رابط في المشكلة يعود إلى المنشور الرئيسي؟
بهذه الطريقة، يكون من مسؤولية صاحب المستودع تحديد ما يُفعّل إجراء جلب المشكلة والتعليقات. يمكن أن يكون ذلك إجراءً على GitHub أو إضافة probot وما إلى ذلك. كما يمكنهم أيضًا تحديد ما إذا كانوا يريدون إغلاق المشكلة تلقائيًا أو تركها مفتوحة.
للإجابة على الجزء الأخير، ليس بعد في الوقت الحالي… لكن ربما في المستقبل.