for the first posts of a user, which may need to be approved (based on a forum policy), a reason for rejection may be good.
when an admin reject a “waiting for approval” post, it’d be good (educational for users) to add the reason so that this reason goes to the user directly.
currently we message users about the reason their post is not accepted. it’s a bit of work, as in a message you need to say hi and bye .
I’m not sure if this can work, but when admins click on reject button, a window like the flag window can open and admins can write the reason or choose among the list:
In my case, new members must submit one high-quality submission before they are given full access to the community. Thus, it would be really great to give them some feedback on their submission if it wasn’t accepted, as to encourage them to try again. Alternatively, if their submission is good but we have some edits, we would like to share some comments on how to improve the post before officially accepting it.
With premoderation of new users/topics this is highly valuable as it’s often the first interaction with the community. And if someone tries to post and just gets a rejection it’s likely that they’ll never come back. The most common case for us is that we need to redirect them from our discourse based discussion forum to our Q&A website.
To that end we have a policy of the following:
Create a message to the user with subject "Re:
Tell them the reason for the rejection (copy and paste reasons stored in our moderation guidelines for convenience)
Copy their content into the bottom of the message so that they have a copy of their question that they might have spent non-trivial time to create.
Send the message
Then reject their post
The benefits of this workflow are that the user gets a reason and can be nudged in the appropriate direction. If we’re already reviewing it knowing the reason makes sense.
In addition we added the copy and pasting of the content because when the post is rejected it’s no longer viewable. And if it’s a good question but misdirected or something else that needs editing and with some iteration would be valuable content, it’s frustrating for the users to lose access to it when we reject the post.
I keep hitting this issue on my forum. It would be nice to have the same kind of options that are available with flagging when rejecting new posts, as each time I reject I have to manually go message the user to inform them why I’m rejecting.
We are also looking for this feature, if the team can pull this off will be great help, our community is very large, need this rejection thing to manage everything, rightnow we have to manually PM every user regarding post rejection.
هذا شيء نحتاجه. نحن نستخدم آلية الموافقة على تقارير الأخطاء (مع أكثر من 150 ألف مستخدم، يميلون إلى النشر أولاً وقراءة التفاصيل لاحقًا). لدينا منتدى عام “للدعم” نشجّع فيه الناس على طرح أسئلة “كيف أفعل”. وإذا تعطل شيء ما، نطلب منهم النشر في قسم تقارير الأخطاء. والمشكلة هي أنه إذا تم رفض نشرهم (سواءً كان تكرارًا أو لعدم احتوائه على المعلومات المناسبة، إلخ)، فإنهم لا يعرفون ذلك… فالبوست يختفي ببساطة، ولا يعرفون ما إذا كان قد نُشر من الأساس أم لا.
هذا يشجّعهم على نشر تقارير الأخطاء في منتدى الدعم ذي الاحتكاك الأقل، وغالبًا ما يكون النص مطابقًا وبدون المعلومات التي نحتاجها منهم لإعادة إنتاج المشكلة. وهذا يخلق المزيد من العمل لنا. أود أن أتمكن من الرفض مع تقديم سببٍ، لتثقيفهم حول كيفية تقديم تقرير خطأ بشكل مناسب، أو ربطه بتقرير موجود، على سبيل المثال.
إليك المنطق المتبع لمستخدم يبلغ عن هذه المشكلة:
الطريقة التي تعمل بها منشورات قسم تقارير الأخطاء حاليًا، قد لا ترى أبدًا أي شيء يوضح بوضوح أن منشورك قد استُلم. فمثل هذه المنشورات تحتاج إلى موافقة من المشرف قبل أن تظهر — وهذا منطقي. فقد يؤثر الخطأ على العديد من الأشخاص، وبدون آلية الموافقة قد تنشأ العديد من المواضيع المختلفة. كما أن الأمر قد لا يكون خطأً فعليًا. وإذا كان مقصد منتدى تقارير الأخطاء أن يعمل أيضًا كقائمة بالأخطاء، فهذا سبب آخر لضرورة موافقة المنشورات.
ومع ذلك، إذا لم يظهر المنشور في النهاية، فلا يبدو أن هناك أي تأكيد واضح على أن المنشور قد استُلم حتى. وحتى لو ظهر (أو تقرير مشابه) في النهاية، فقد يستغرق ذلك وقتًا طويلاً. وإذا استمرت المشكلة، قد تجد نفسك تفكر: “هل استُلم المنشور أصلاً؟ هل يجب أن أنشر مرة أخرى؟”. ويمكنك أيضًا قضاء وقت في التحقق مما إذا ظهر أي شيء.
هذا مُحبِط.
أما إذا نُشر في قسم الاقتراحات والتغذية الراجعة، فسيظهر المنشور على الأقل، بحيث يمكنك رؤية أنه قد استُلم. وحتى لو تم نقله أو حذفه لاحقًا، فإنك على الأقل تعرف أنه لم يضيع أثناء النقل.
هذا أقل إحباطًا.
ومن وجهة نظر شخص يحاول المساعدة من خلال لفت الانتباه إلى مشكلة، يبدو إذن أن النشر في قسم الاقتراحات والتغذية الراجعة أفضل من النشر في قسم تقارير الأخطاء. فعند النشر في تقارير الأخطاء، يجب أيضًا تزويدك بوسم واحد على الأقل، مما يشجّع أيضًا على عدم النشر هناك. كما يُطلب منك تقديم الكثير من المعلومات التي قد لا تكون ذات صلة حتى.
عمليًا، نحن نشجّع من خلال سلوك المنتدى على الإبلاغ عن المشكلات في قسم الاقتراحات والتغذية الراجعة بدلاً من قسم تقارير الأخطاء.
قد يُقال إن هذا قد يؤدي إلى إنشاء مواضيع مكررة، وهو ما تهدف آلية الموافقة إلى تجنبه. ومع ذلك، من المفترض بالفعل البحث عن مواضيع موجودة قبل النشر، ومن السهل الانتظار قليلًا قبل النشر لإتاحة الفرصة لمنشورات أخرى للظهور.
لذا، عندما نضع كل ذلك معًا، لا يزال يبدو أن النشر في قسم الاقتراحات والتغذية الراجعة أفضل (من وجهة نظر شخص يريد تقديم تقرير).
كانت هذه مطلوبة بالأمس. أرفض الكثير من المواضيع الجديدة يوميًا لأنها مكررة لمواضيع موجودة، لكن أولئك المستخدمين لن يحصلوا أبدًا على حتى كلمة واحدة توضح سبب رفض موضوعهم.
ليس لدي الوقت لـ:
مراسلتهم عبر الرسائل الخاصة والتعامل مع النقاش الذي يلي ذلك
الموافقة على المواضيع ثم إخفاؤها وقفلها فورًا
الموافقة على الموضوع ثم فتحه لرفعه كـ “مكرر”
عند الرفض، أود تقديم سببٍ وإنهاء الأمر في تلك اللحظة نفسها. يمكن أن يكون هذا سببًا قياسيًا (مكرر، خارج نطاق المجتمع، كتابة ضعيفة، غير لائق)، يليه اختياريًا رسالة قصيرة.
عدم توفر هذه الميزة محبط جدًا لمستخدمي المنتدى الجدد.
أتفق معك. إذا قمت برفض منشور أو موضوع ولم يظهر أبدًا للمستخدم دون تقديم شرح، فإن ذلك يترك انطباعًا سيئًا ما لم ترسل له رسالة خاصة لاحقًا. أود حقًا أن يتم تنفيذ هذه الميزة. بالإضافة إلى ذلك، فإن الانتقال من قائمة الانتظار للإشراف إلى ملفه الشخصي لإرسال رسالة يستغرق وقتًا أطول. لو كانت كل هذه الأمور في مكان واحد لكان ذلك أكثر ملاءمة.
أعتقد أننا بحاجة على الأقل لإخطار المستخدم إذا تم رفض منشور. حاليًا، يترك المستخدمون دون أي معلومات.
عملية الموافقة على الإشراف حاليًا هي:
ينشر المستخدم في فئة خاضعة للإشراف
بعد النشر، يرى المستخدم js.review.approval.description (نافذة منبثقة فقط، لا رسالة من الطاقم)
إذا تم رفض المنشور، لا يتلقى المستخدم أي إشعار.
أعتقد أن الوظيفة الأساسية يجب أن تكون رسالة تفيد برفض المنشور (ربما من الطاقم). لا أحتاج بالضرورة إلى شرح مفصل - يمكننا مثلاً تعديل js.review.approval.rejected.message وإضافة الأسباب الأكثر شيوعًا هناك. هذه مجرد فكرة.
أتفق مع ذلك بشرط أن يكون المستخدم شرعيًا ونرغب في إخباره بأسباب رفض منشوره.
ومع ذلك، في حالة وجود مرسل رسائل مزعجة (سبام)، أرى أن عدم إرسال إشعار يكون مبررًا. فليس من المرغوب فيه إخبار المرسل بأن منشوره قد رُفض (حُذف) ثم يعود ليحاول مرة أخرى.
يجب ألا يُرسل إشعارًا عند اختيار سبب “رسائل مزعجة”. أما بالنسبة للأسباب الأخرى، فيجب إرسال الإشعار.
في حالة الرسائل المزعجة، يمكننا ببساطة حذف المستخدم. أما في حال الرفض، فيمكننا اللجوء إلى حل بسيط كما اقترحت في منشوري السابق. هذا هو الحل الأسرع والأسهل للفريق. بافتراض أن الفريق لا يهتم بالطلب الكامل وأن هناك موضوعًا في Marketplace مفتوحًا لذلك، كما أن هذا المنشور يعود لعام 2020..
ما يعادلها في Mailman 2 هو “رفض” (يمكن اختيار إعطاء سبب) و"تجاهل" (بدون إشعار على الإطلاق) - بالإضافة إلى “تأجيل” (القرار لاحقًا) و"قبول".
كما يوجد خيار “تجاهل جميع الرسائل المصنّفة كمؤجلة”. التأجيل هو الخيار الافتراضي، لذا بمجرد قبول أو رفض الرسائل الحقيقية، فإن ما تبقى في الصفحة هو على الأرجح كل البريد المزعج الذي ترغب في تجاهله دفعة واحدة.
هناك المزيد من التفاصيل غير هذه، لكن هذه هي الخيارات الأكثر قابلية للمقارنة المباشرة.
.
