I’m not a fan of new badges being turned on by default.
We don’t use most of the native Discourse badges so I have them turned off, but there was an awkward situation just now when someone received this:
I knew nothing about it and his ‘um, wow, thanks’ response was a bit awkward.
I think it’s an awesome initiative and will go down well in lots of communities, but it’s not something that we’ll use and I don’t think it should be enabled by default – at least not without notifying the CM.
Discourse changes all the time. I like to think I keep abreast of things by spending a lot of time reading here. But I understand that most don’t have that luxury.
At one time I considered trying to write a plugin that compared an existing site_settings.yml against the newer file, but it’s still on my “maybe someday” todo list.
Do you think something like that would be adequate to prevent most serious gotchas?
i.e. These Settings are new - be aware!
It would be helpful for me, yes.
I remember having a convo with someone about this a while back. I’d love it if Discourse had a What’s New / News widget on Dashboard like WP does.
I think the easiest to implement would be a link to “commits since your version”.
But I don’t see that as being the most user friendly. Kind of like sending a newbie to a W3C RFC. Everything needed is there, but can it be digested?
I guess we could petition the Discourse team to use descriptive commit tags so they could be filtered.
But I’m thinking changes in the site_settings.yml file would catch most things that would be important to forum users.
That already exists
And on the upgrade page
However, if you are hosted by Discourse (and I believe @hawk is), they sort of handle upgrading you… so you still might not get a chance to see what changed.
Out of curiosity @hawk, do you have all badges disabled or just a select number of them? As I know there is a global setting for ALL badges, setting is enable badges
Hmm if badges were disabled globally this is a bug. But I don’t think you disabled badges globally? You should disable badges globally if you don’t want badges.
Otherwise this is very much by design.
I think there is merit for a badge system is on but no stock badges are enabled by default, mode, but it is a rather rare use case
My personal preference would be that new badges (and other such changes) be preffed off by default, but that when an admin/leader logs in after the update, they have the option to enable them.
As an alternative, could it perhaps be that the preferences become available a week or so before the functionality (with a “what’s changing” notice), so that admins have the opportunity to pre-emptively disable them? I’d be happy if this was a way to set preferences by typing in a key (like Firefox’s about:config), and these were communicated via email (or announcement here) ahead of the release.
Would there be merit in something like this?
In that scenario, do users ever advance through trust levels automatically? I’m curious if the trust level badge contains the logic for advancing, or if the badge merely triggers on some other test succeeding.
In any case, I think defaulting to badges off is not such a great idea, but I can see merit in a setting for the default badge status:
Badges default to: [ enabled | disabled ]
And then a list of all the badges with current settings:
Nice Post: [ explicit enabled | explicit disabled | site default ]
Great Post: [ explicit enabled | explicit disabled | site default ]
…
I’m with @HAWK on this one. I’d love to see a better (more interactive) system for badges that are added. Two of my sites are closed, log in only environments, with one using SSO. As such, we’ve disabled a number of badges that are unobtainable in this setup, like shares and invites. One has no reply-by-email, so the email badge is disabled.
The most recent badge may be an extreme example (first badge to send a PM), released near end of month so it was awarded quickly - but it caught me by surprise too when I saw the PM in email logs. Some type of “a new badge has been added, check it out here” on the admin dashboard would likely be enough.
أنا أيضاً أقضي وقتاً طويلاً في القراءة هنا، لكنني أجد نفسي أحياناً أفوت بعض المواضيع الحاسمة جداً. وقد طرأت عليّ هذه الميزة الجديدة تماماً دون أن أنتبه، وكان أول ما سمعت عنها هو في هذا الموضوع. شكراً لك @HAWK على لفت انتباهنا إليها! أنا الآن أستكشفها مع فريق المشرفين لدينا لنقرر ما إذا كنا سنحتفظ بها مفعّلة أم لا.
ربما يمكن لفريق Discourse أن يحاول أن يكون أكثر يقظة في إخطارنا جميعاً (وخاصة عملاءهم المدفوعين) بالميزات الجديدة التي سيتم “فرضها” على مجتمعاتنا وقد تحتاج إلى تعطيلها.
ومع ذلك، أنا ممتن بعمق لفريق Discourse على عملهم المستمر والجاد في تطوير هذا البرنامج الرائع وتطوره، وأنا سعيد جداً به وبسرعة ونطاق التحسينات. ليس لدي أي شكاوى على الإطلاق بشأن الاتجاه الذي يسير فيه، وأثق تماماً بـ Discourse، وأتأثر إعجاباً كبيراً كل يوم بما يحدث مع البرنامج.
أيضاً، لست عميلاً مدفوعاً، لذا أنا مستعد جداً لقبول الطريقة التي تظهر بها التغييرات عبر فيضان مستمر من عمليات git commits، وأن إعادة بناء موقعي غالباً ما تولد سلسلة من عمليات إعادة البناء خلال الأيام القليلة التالية بينما يتم تعديل الميزات الجديدة وإصلاح الأخطاء. إنه أمر ممتع (بطريقة تشبه البحث عن بيض الفصح) البحث عن التغييرات والميزات الجديدة، والإبلاغ عن الأخطاء ورؤيتها تُصلح بسرعة. يمكنني حصر عدد المرات التي حصلت فيها على مفاجأة غير سارة بعد تحديث ما على يد واحدة أو حتى بأصابع قليلة. وحتى حين حدث ذلك، لم يكن الأمر كبيراً وتم حله بسرعة. لم تتردد أي شكاوى من مجتمعي.
سيحزنني أن تتباطأ وتيرة الإبداع في التحسينات لأن الفريق يضطر إلى التشكيك في كل ميزة جديدة وقضاء وقت أطول في النظر إلى الخلف والقلق بشكل مفرط بشأن تأثيرها على التثبيتات الحالية.
أعتقد أن الحل بالنسبة لي سيكون مراقبة فئة Contribute > Feature لأكون مُعلَّماً بكل منشور جديد في تلك الفئة، حتى لو كان ذلك يعني بعض الإشعارات الإضافية حول طلبات الميزات التي لا أحتاج إلى رؤيتها.
We have all native badges disabled but use custom badges.[quote=“codinghorror, post:6, topic:61371”]
You should disable badges globally if you don’t want badges.
[/quote]
I definitely do want badges. 
But I want to be able to choose which ones, and I don’t want new ones that I don’t know about to be activated by default.
This is such a rare use case though. Can’t say when we would get to that.
It’s a big change to make new badges not activated by default?
It’s not on our roadmap for the forseeable future, no.
/me does the PR-welcome dance, with full ruffles and flourishes
Ok, fair enough.
Is there an easy way to know when new badges will be added?
Actually my real issue here isn’t so much the badges but the fact that users are receiving messages from me that I wasn’t aware were being sent.
What are the criteria that kick this message off?
You can learn everything there is to know about the new feature that prompted this topic over here:
في الواقع، تحول هذا الأمر إلى العديد من الإشعارات غير الضرورية بالنسبة لي، لذا سأقوم بإيقاف متابعة فئة Contribute > Feature مرة أخرى.
لا تبطئوا بالتأكيد من وتيرة التطوير، ولكن إذا أمكنكم، فيرجى محاولة إيجاد طرق للتواصل بشكل رسمي حول الميزات التي يتم تنفيذها فعليًا وسيظهر بعضها في فرع tests-passed.
