Rename STAFF category to MODERATORS


(Tobias Eigen) #1

Can I recommend that we rename the special, preconfigured STAFF category to MODERATORS category? On a site I am setting up for an organization there is a bit of confusion around what this is for. I can explain the difference between this STAFF category and our other internal (e.g.“orgname staff”) categories but it would be nice not to have to do that in the first place.

Continuing the discussion from How to rename a Category? (safely):


(Michael Downey) #2

I agree “Staff” is confusing, as many communities/companies/organizations already have a “staff” that is not necessarily the same as the Discourse moderator/admin “staff”. Same confusion happens in some of the flag dialog text.


(Tobias Eigen) #3

I looked into this a bit more and see that the STAFF group in discourse actually includes both admins and mods. Technically speaking having a group that includes both makes some sense. But I honestly don’t really care about that and would rather have the category called MODERATORS, unless there is something I am missing. It makes more sense to me.


(Neil Lalonde) #4

Yes, it’s safe to rename the category, and kinda important if a site isn’t using english.


(Tobias Eigen) #5

Thanks, Neil! Glad to see this can be changed on individual discourse sites. My suggestion is to actually change this in discourse so that the name is changed from STAFF to MODERATORS for all new discourse sites by default.


(Jeff Atwood) #6

I completely disagree with that. Staff is admins and moderators.


(Mittineague) #7

Some of our members have been confused, or at least unaware of the distinction, between SitePoint Staff (i.e. employees) and SitePoint Forum Staff (i.e. with the exception of HAWK, volunteer forum moderators).

But not all forum staff are moderators i.e. “Mentors”.

TBH though, it has never been much of a problem where it was felt the distinction needed to be made more obvious.


(Kane York) #8

Perhaps “Forum Staff” would be appropriate for you, then?


(Caue Rego) #9

I’m not sure I follow this.

Right now we have staff, moderators and admins. I find this very confusing, but renaming staff to an existing moderators would be even more confusing.

And why do we need staff anyway? Wouldn’t be simpler to just remove it?

For instance, I’ve created an editors group. That’s staff too, but it won’t be included unless I manually include them as well. I mean, the whole concept is just a mess and the way it’s implemented is too gimmicky.

Or maybe I’m missing something there.


(cpradio) #10

Staff is just giving us a way to quickly include Admins and Moderators in a mention/group.

Otherwise, you’d have to include admins and moderators separately.


(Dave McClure) #11

In our case, all Admins are also Moderators, so mentioning moderators would do the same thing. If we did have admins who were not moderators, I’d probably just want to mention moderators anyway in most cases.

I see good reason for keeping staff an a union of these groups in the code base for permissions checking, but maybe its not necessary as a user facing concept.


(Caue Rego) #12

From what I read, staff exists just for mentions then. Makes some sense. Except I don’t seem to be able to mention @staff here. What you mean exactly? Or why would I want, as a site admin, enabling any user to call attention of the whole @staff with a mention?


(cpradio) #13

I’d have to double check (regarding the mention), but it can be used for category permissions too and Discourse Meta


(Kane York) #14

It’s also used in places in the code.


(Caue Rego) #15

Category permission is set just once per category. It wouldn’t be too much trouble setting it “twice” for every single one, if that was the case. Discourse Meta leads to the exact same as Discourse Meta and Discourse Meta so that’s also a bad excuse for staff's existence. Even if it were different, why would anyone care for that grouped list?

I doubt we have access to any other variable being used in the code that doesn’t appear to have any utility such as this.

There must be a blind spot for this, somewhere…


(Jeff Atwood) #16