# New badges shouldn't be on by default
**URL:** https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371
**Category:** Feature
**Created:** [April 21, 2017, 2:54am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371 "2017-04-21T02:54:00Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@HAWK](https://meta.discourse.org/u/HAWK)
#### Post date: [April 21, 2017, 2:54am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/1 "2017-04-21T02:54:00Z")
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.
---
### Author:  [@Mittineague](https://meta.discourse.org/u/Mittineague)
#### Post date: [April 21, 2017, 3:04am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/2 "2017-04-21T03:04:49Z")
> [@HAWK](#):
>
> p.s. Are there other things like this that might catch me out?
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!
---
### Author:  [@HAWK](https://meta.discourse.org/u/HAWK)
#### Post date: [April 21, 2017, 3:07am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/3 "2017-04-21T03:07:16Z")
> [@Mittineague](#):
>
> Do you think something like that would be adequate to prevent most serious gotchas?
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.
---
### Author:  [@Mittineague](https://meta.discourse.org/u/Mittineague)
#### Post date: [April 21, 2017, 3:18am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/4 "2017-04-21T03:18:20Z")
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.
---
### Author:  [@cpradio](https://meta.discourse.org/u/cpradio)
#### Post date: [April 21, 2017, 3:33am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/5 "2017-04-21T03:33:22Z")
> [@Mittineague](#):
>
> I think the easiest to implement would be a link to “commits since your version”.
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`
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [April 21, 2017, 3:36am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/6 "2017-04-21T03:36:21Z")
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.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [April 21, 2017, 4:06am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/7 "2017-04-21T04:06:39Z")
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
---
### Author:  [@barryvan](https://meta.discourse.org/u/barryvan)
#### Post date: [April 21, 2017, 4:11am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/8 "2017-04-21T04:11:17Z")
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?
---
### Author:  [@elijah](https://meta.discourse.org/u/elijah)
#### Post date: [April 21, 2017, 4:50am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/9 "2017-04-21T04:50:44Z")
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]
…
---
### Author:  [@jomaxro](https://meta.discourse.org/u/jomaxro)
#### Post date: [April 21, 2017, 5:53am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/11 "2017-04-21T05:53:18Z")
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.
---
### Author:  [@tobiaseigen](https://meta.discourse.org/u/tobiaseigen)
#### Post date: [April 21, 2017, 4:04pm UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/12 "2017-04-21T16:04:42Z")
> [@Mittineague](#):
>
> 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.
I also spend alot of time reading here, but I somehow manage to miss some really crucial topics. This new feature completely snuck up on me too and the first I heard of it was in this topic. Thanks @HAWK for bringing it to our attention! I’m now exploring it with my moderator team to decide whether to keep it enabled or not.
Maybe the discourse team could try to be a little more vigilant about notifying all of us (and esp their paying customers) of new features that will be “imposed” on our communities that may need to be disabled.
That said, I am deeply grateful to the discourse team for their continued and diligent work to develop and evolve this amazing software, and I am really happy with it and with the velocity and scope of improvements. I have no complaints at all about the direction and have full trust in discourse, and am crazy impressed every day with what’s happening with the software.
Also, I’m not a paying customer, so am very willing to accept the way changes appear via an ongoing flood of git commits and that frequently one rebuild of my site spawns a series of rebuilds over the next few days as new features get tweaked and bugs get fixed. It’s fun (in an easter egg hunt sort of way) to look for changes and new features, and to report bugs and see them get fixed quickly. I can probably count on one hand or even with just a few fingers the number of times I had an unpleasant surprise after an update. Even then it was not a big deal and was quickly resolved. Nary a complaint from my community.
I’d be sad if the pace and creativity of the improvements slowed down because the team has to second guess every new feature and spend more time looking backwards and worrying excessively about the impact on the existing installs.
I think the answer for me will be to watch the #Contribute > Feature category so I am notified of every new post in that category, even if it means some extra notifications about feature requests that I don’t need to see.
---
### Author:  [@HAWK](https://meta.discourse.org/u/HAWK)
#### Post date: [April 22, 2017, 12:09am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/13 "2017-04-22T00:09:45Z")
> [@cpradio](#):
>
> Out of curiosity @hawk, do you have all badges disabled or just a select number of them?
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.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [April 22, 2017, 12:10am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/14 "2017-04-22T00:10:32Z")
This is such a rare use case though. Can’t say when we would get to that.
---
### Author:  [@HAWK](https://meta.discourse.org/u/HAWK)
#### Post date: [April 22, 2017, 12:11am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/15 "2017-04-22T00:11:18Z")
It’s a big change to make new badges not activated by default?
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [April 22, 2017, 12:12am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/16 "2017-04-22T00:12:00Z")
It’s not on our roadmap for the forseeable future, no.
---
### Author:  [@mpalmer](https://meta.discourse.org/u/mpalmer)
#### Post date: [April 22, 2017, 12:13am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/17 "2017-04-22T00:13:10Z")
`/me does the PR-welcome dance, with full ruffles and flourishes`
---
### Author:  [@HAWK](https://meta.discourse.org/u/HAWK)
#### Post date: [April 22, 2017, 12:13am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/18 "2017-04-22T00:13:19Z")
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.
---
### Author:  [@SouperC](https://meta.discourse.org/u/SouperC)
#### Post date: [April 27, 2017, 2:24am UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/19 "2017-04-27T02:24:17Z")
What are the criteria that kick this message off?
---
### Author:  [@tobiaseigen](https://meta.discourse.org/u/tobiaseigen)
#### Post date: [April 27, 2017, 5:33pm UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/20 "2017-04-27T17:33:30Z")
> [@SouperC](#):
>
> 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:
> [@Weekly or monthly "best new user" badge](https://meta.discourse.org/t/weekly-or-monthly-best-new-user-badge/60065):
>
> We know that healthy communities are always growing, through an influx of new users. Without a steady stream of new users, a community can only hope for, at best, stagnation. Discourse can’t magically deliver new users to your site. However, it should help you reward and appreciate the great new users that do arrive on your site! For the 1.8 #releases we’re building in a way to automatically reward your best new users. [image] Sort of a “rookie of the month” kind of badge that says … hey tha…
---
### Author:  [@tobiaseigen](https://meta.discourse.org/u/tobiaseigen)
#### Post date: [April 27, 2017, 5:36pm UTC](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371/21 "2017-04-27T17:36:57Z")
> [@tobiaseigen](#):
>
> I think the answer for me will be to watch the #Contribute > Feature category so I am notified of every new post in that category, even if it means some extra notifications about feature requests that I don’t need to see.
This is in fact turning into many new extraneous notifications for me so I will be turning off watching of #Contribute > Feature again.
By all means do not slow down the pace of development, but if you can do please try to find ways to communicate in an official way about features that are actually being implemented and will show up in the tests-passed branch.
[Next page](https://meta.discourse.org/t/new-badges-shouldnt-be-on-by-default/61371.md?page=2)