[Suggestion] Smarter new user restrictions


I understand (and approve of) the need to hesitate trusting new users, but as one I found the restrictions a little limiting.

Good feature requests and posts in general are encouraged to have links to relevant atom components, gists of sample code, etc, as well as demonstrative images or gifs. So why should a new user, eager to create the best possible post, be limited to one link and no images? It seems counterintuitive.

Perhaps better restrictions can be implemented, such as post/comment frequency throttling, rather than post/comment quality-throttling?

Perhaps more than just user age could be a criteria to remove the restrictions, such as number of likes or views?

Perhaps some of these are already in place but not documented? Certainly the flash messages telling you you can’t do something ought to link to an explanation of why and how to change things.

Maybe we could make better use of github integration, pulling information from there to help determine the venerability of a user?

I’m just spitballing here. The current mechanic feels poorly designed, though.


Actually, the default difference between a “new” user and a “basic” user are very small:

I don’t know if the Atom board here has customized the thresholds, but by the defaults if you essentially spend 15 minutes on the board reading* posts … then you have all the restrictions that you’re finding confounding removed. Also note that it doesn’t require you to have posted a single thing. You can lurk and still reach “basic” trust level.

I don’t think requiring someone to spend a little time looking around is too much to ask before allowing them to post whatever they like. This is essentially a heuristic to prevent spamming, by my best guess.

* I’m also not entirely clear on the definition of “reading” … but I’m certain one of the mods can clarify.

Blank screen 0.8.5

Good to know. Apparently I did more reading before I created my account than I imagined, and that’s a brilliant metric.

Also, didn’t realize discuss.atom.io was Discourse powered! Cool. I should have realized as much by that familiar screaming avatar!

I suppose in light of that, the restrictions make more sense. Didn’t realize the threshold was so low. I still maintain that that

  • The flash messages should be more informative or link to information.
  • In the context of Atom, limiting links and posts is counterintuitive; and if configurable, I’d tweak that.

Both of those really belong more on a meta-Discourse thread than an Atom one, though. Thanks, @leedohm!


I don’t know what this means, can you be more specific and provide examples?

New users are limited to 2 links per post (and no images because… I have seen things on the Internet that no human should have seen :eyes:), but some domains can be whitelisted. There are some rate limits on new users and actually all users again because spammers. Can you be much more specific about what you are referring to and what you saw?


Certainly! I tend verbose, so… no TLDR’s on this one. You asked for specificity…

What I saw

After perusing discuss.atom.io for a while, I decided to register and propose some features that had occurred to me over the last couple of days of playing with the product.

I made my first post without incident, but ran into trouble making my second post. This one was a little more detailed: it linked to a gist, contained an image of the desired effect, and then referenced cross-sub-domain documentation (atom.io rather than discuss.atom.io), alongside several relevant git repos.

As I was composing it, I tried to drag and drop the screenshot I’d taken, to receive a dismissible yellow ‘alert’ popover/tooptip informing me that I couldn’t that as a new user. The overlay appeared right above the editor, overlapping the blue overlay popover how to write good posts.

Leaving placeholder text where I wanted to put the image when I became an old user, I finished the composition and hit ‘Create Topic’, only to receive a similar popover informing me I had too many links (I think it mentioned I was limited to two only). Kinda naively I ‘un-markdownified’ most of my links, and got the same result. Finally, I removed the ‘http://’ from them and submitted my post feeling a little frustrated.

What I’d rather see

Primarily, when told I can’t do something, even though I understand there needs be limitations, I’d like to understand those limitations. Targeted, contextualized warning messages letting me know what I did wrong is great, but I’d love to see them contain a link to a canonical page documenting what it means that I’m a new user, when that will go away, and what I can’t do as one. Similar to what @leedohm linked me to above, but with the link provided as a part of the error message, and possibly handcrafted around any site-specific settings.

That would have cut my three failed attempts to post down to one, reducing my barrier to entry and the general churn of navigating the new user restrictions without a map.

Furthermore, I’d have been able to read that the restrictions were contingent on my time spent perusing the site, and happily continued to do so to earn my wings the way I’d already been doing for a few hours, sidestepping any frustration altogether. Instead, I felt sufficiently undermined and frustrated to come make a post here, seeking information that could have been presented to me.

From an actual site-admin standpoint, I’d also whitelist atom.io, gist.com, and github.com, given the option. Although those gists can be risque.

Finally, since I assumed that new-usership was a factor of site reputation rather than time, more similar to Stack Overflow, I was frustrated that the tools necessary to gain reputation by crafting high-quality posts were withheld from me until I acquired a reputation. This catch-22 was a misunderstanding on my part, but could have been cleared up easily with a little more right-when-I-needed-it direction on how to become a trusted user.

Perhaps on authenticated, real-world-identity sites, especially ones like this one, I feel as if the restrictions themselves should be lighter. On the other hand, I imagine what horrors you’ve witnessed in the call of duty and shudder. It’s a hard tradeoff, but as long as it’s configurable by the per-site Discourse instance, new-usership isn’t reputation driven, and restrictions are clear, I’m comfortable letting the eyes more scarred than mine make those calls.


I’m quite excited to be using Discourse! I’ve been subscribed to the Boing Boing BBS digest for some time, which always baffles me because I never read the stuff. Then I notice it’s sent from info@discourse.org and remember I only subscribed because I was interested in seeing your product.

On the whole, I have to say I’m delighted. This has been my only issue with it so far, and only frustrating in the Daoist sort of way where the rest of my experience has been so smooth it stuck out in comparison. I hope this helps! Keep setting the bar high!


I think this is the main thing to do next, @sam added support for this in white_listed_spam_host_domains, and he’s also a big believer in “show people how to level up”. I am too – it just takes a lot of time to get there.

I need to see these gists because I am clearly looking in the wrong place, all I find in gists is boring old source code :blush:

Right now the white_listed_spam_host_domains contains the values atom.io,github.com and it really should be pipe delimited like our other list settings…

Also I don’t think gist.com is a GitHub domain, I recall something about them creating a new domain for that sort of thing due to some security vulnerabilities from hosting it on the main github.com domain. Can’t find it at the moment…?

Great to hear, we are still evolving what Discourse is, and conversations like these (with lots of specifics!) are a big help in doing so. Discourse is 100% open source, come join the fun. :wink:


Check out some of the artist tenderlove’s stuff. With spicy entries like bring_it_on.rb, sausagebox.r, and probes.d, you gotta look over your shoulder before clicking.

Found it! It was pages.github.com, which makes sense.

Poking around the composer ember views, I found the translations for the messages I was seeing. However, simply inserting a link to the best reference I could find into the en.yml hardly seems a robust solution. I’ll kick around some other ideas and see if a good actionable issue comes out of it.