Let’s take a step back here. The words “security violation” seem to have been introduced by @codinghorror when splitting this topic off from its original.
The original concern expressed by @watchmanmonitor (and me) is that a leaderboard sets the wrong tone for some communities, and we felt there should be a way to hide/disable it. (Maybe CSS hacks are enough.) No one was actually claiming security violations, and no one was saying that the same information couldn’t be gleaned elsewhere.
Just that it was inappropriate for some of our communities to introduce this type of competitiveness. That’s all.
Yeesh, for a second I didn’t even think about that…
And yes… yes it’s foolish. It’s an extension of the recent debacle about email address disclosure via registration and/or the password reset feature. Some users are concerned about it but fail to properly explain why, techhead users rant that bandaid fixes are stupid and pointless but fail to explain that a comprehensive solution is really f-ing hard to implement and ain’t nobody got time for that… and it all goes downhill from there…
Again, I’m talking about the original expressed concerns from the original topic, not the artificial edge case that @codinghorror brought up in the 2nd post of this (current) topic.
The Point (emphasis added):
This is about how real (i.e., non-hacker) humans react to the leaderboard. Not about what’s theoretically possible given some amount of coding skills.
In its first day, I’ve already had a few people ask that we disable it because (in its current configuration and data set) it sets the wrong message about trying to collaborate vs. compete.
Provide actual evidence that this is the case, please.
We’re not announcing this feature, so I don’t even know how people would find it. Nor is it listed in topnav anywhere, nor are we planning to. It’s just a user directory, that’s all.
I am open to introducing such a disable setting once we gather more feedback, but you guys have provided absolutely zero concrete evidence that this is in fact a problem. Because you don’t have any. Because the feature is too new, and we’re still looking at it.
So, let’s do the science first before concluding ipso facto “it must be disabled because <waves hands>reasons”
What counts as evidence? One of my users already figured out there was a link in the hamburger menu and is now complaining that he can see a list of my clients.
I coach public speakers (for TEDx, etc.). When they work in groups, Discourse is used to exchange experiences online. Most of my clients don’t want anyone to know they hired me, because it might make it look like they’re not good enough. So there is no public category, only private categories for each group.
While I completely love the user list, in this case I really want to hide (or disable) it. And I believe that this use case is not that rare.
Have a site setting to disable it. I know this adds another option to the admin CP and to make vB all the more worried it has to someday fight for most bloated back end (harhar). I can see some legit legal reasons why, biz wise.
However, I’m politely calling chicken little on the idea that this will create distractions for a dedicated user group. As the owner of such a group, I can say with a level of healthy authority on this subject that a list of the most productive or popular users will not create a sudden arms race and negative feedback in a user’s motivation to get on that list.
Have some faith in your users. Double that if this is a dedicated group with a private or semiprivate community. At the very least it will show those users that are productive. Let your new users see them and follow by healthy example.
Show the work of your community elders and they will want to continue giving that work in strides. Let them have a little spotlight.
If it worries so much then explain to your users against that kind of behavior. Communication is great in any measure.
This depends 100% on the type of community. And there are lots of types of communities. Failure to recognize that when designing systems will lead to a system that works great for the type the designers think about, and either lots of hacks or lots of stress for the other types.
I am thinking about the case of a segmented user population with low overlap. Might be a strict segregation with groups & permissions but could be just a result of how categories are organized. In some cases it could be considered an invasion of privacy to be able to see that some other user (whom I’ve never encountereed and never posts in the topics that I frequent) is very active … so that I can follow that user’s profile and stalk their topics.
But worrying about this stuff doesn’t make any of the concerns well-founded until we’ve seen how it works in the real world. It’s a lovely feature and should be left in & evolved and only restricted when there’s good reason to do so.
I agree 100% with that which goes back to @codinghorror’s contention that it’s too early to call up the concept that a high percentage of communities running on Discourse have a predisposition to react in a profoundly negative way to the user directory’s features that warrants a hard coded switch in the admin CP to turn it off.
My initial response aligns with Design To Thrive’s methods of keeping elder members for longer. Those who equal to higher trust levels on a Discourse-run community and maintain that position by creating original content and/or engaging the other users in a way that should be exemplified in a constructive manner. Everyone wants a little attention for their efforts. Using the in-system metrics to show that is something worth exploring which is why I am initially positive to the user directory and its presentation.
Yeah but someone who posts only in a private category would not show up in these stats, would they @eviltrout? I would say you need at least one post in a public category to be included in the users list.
