/about listing of Admins vs Moderators is confusing

Some people are admin + mod. Others are only admin or only mod.

When a user visits /about, they see all the admins under Our Admins, regardless of mod status.

Some admins may not want to be moderators. They help with technical things and have admin power, but they don’t want the responsibility to do moderation (and we may not want them involved there).

How to hide admins from /about page is relevant but I’m not specifically talking about hiding anyone. I’m talking about identifying which admins are also mods.

Maybe all of the listed people could be put under “Staff” and then a little mark or badge identify admin and/or mod (show both for those who are both)?

The real point is to make it easy for users to identify which individuals they might go to if they need a moderator (especially for the unlikely case that they have a concern about violations from a moderator themselves and want to contact a different moderator). I don’t want that user to end up contacting admins who aren’t wanting to deal with such issues…


I think you are making a fair point, but the problem is that the terms “moderator” and “admin” have a different (more technical) meaning in discourse. They simply refer to two levels of privileges: admins have all privileges and mods have limited privileges (only what they need to to their moderation job).

The discourse team will correct me if I’m wrong, but I can’t think of any easy way to achieve what you want by modifying the /about page.

However, what you could do is create new groups that correspond to your definition of admin and mod (or only mod) and direct people to that group’s membership list.

Actually, it doesn’t matter that admins have 100% of the power that mods have, they are separate groups. I can see as an admin by looking at the other admins — some are in the mod group and some aren’t.

So, there’s no need to change anything besides the display of the About page. Certainly there’s no need for new groups.

You’re right, I was making some wrong assumption and wrote nonsense.

In that case I don’t understand your problem. The about page already distinguishes between mods and admins…

If a person is a mod and and admin, they are only shown in admins. If someone is not a mod but is an admin, they are shown there too.

In short: there’s nothing on /about that allows people to see which of the admins are mods


I feel like Discourse team has a plugin that hides users from being listed on that page… maybe one of them can speak to it.

I totally agree. I am an admin on dozens of sites but am not a moderator on any (maybe one?).

Several times I have been contacted by a user about something that I could not help with or had the site owner express concern that I was listed on the about page.


We do. We’re admins on lots of hosted sites for support reasons but we don’t show up on the About page.

1 Like

Hiding people entirely would only sorta solve my concern (it would help avoid contacts to people who don’t want it, but they’d lose being honored as part of the staff). I want clarity about the admins who are mods so that it’s obvious that they are options when mods specifically are needed. I think I don’t want to hide the non-mod admins though. I’d still like them to be honored as being staff in our case.

I think the About page just could use a rethinking in how staff are presented overall. I could see several different ways to do it. One thought: flip the current approach, just maybe show all mod+admin folks under mod, but give them a special badge noting that they are admins. Another thought: Show it like a Venn diagram somehow so that everyone is in a big list but a section are highlighted mods and a section admins and show an overlapping section. I’m sure good UX folks could have other ideas.

The goal is just to have more clarity for the multiple purposes that we show who the staff are (knowing who to contact for things, honoring people for their work and positions…)

1 Like

Just found this

It should help give you an idea on how it could be implemented in a plugin.


Is this something that can be released?

1 Like

We will never release that plugin since it’s our secret sauce, but that feature is easy to do :wink:

add_to_serializer(:about, :admins) do
  object.admins.reject do |user|
    # your criteria for removing users from the admins list

From the I-don’t-really-understand-serializers department. . .

  # remove pfaffman from admins
  puts "now Adding to serializer"
  add_to_serializer(:about, :admins) do
    object.admins.reject do |user|
      puts "USER::: #{user}"
  puts "end Adding to serializer"

I get no output between “now…” and “end…”.

I thought that # your criteria for removing users from the admins list would seem like I’d put something like user.username=='pfaffman' in there, but it doesn’t seem like anything is happening. Except that now no admins are displayed.

edit: This also removes moderators (I tried false too).

  add_to_serializer(:about, :moderators) do
1 Like

add_to_serializer is a function which takes three arguments.

  1. Name of the serializer (:about)
  2. Name of the variable you want to serialize (:admins)
  3. A block. Think of this as a section of code that will be executed at some point in the future

So that is expected. The block you gave to add to serializer has not been executed yet. In fact, it will only be executed when the serializer is used. If you go and request about.json, you should then see "USER::: #{user}" appear in your console. And it will appear every single time you make the request.

Yes, that sounds like it should work. Remember it is case sensitive.