Discord Channel Emojis

Community
1

Premise: Weights of specific emojis are decided based on channel in discord.

Implementation:

If a discord channel has an emoji in the channel name, that emoji is worth as much as the sourcecred emoji (or just larger weight) only in that given channel.

Who, What, Where, How, Why:

From a Crediquette perspective, this is really easy to explain and sell to users. It’s literally in the name and people would most likely infer when to use the emoji. One sentence explanation could say, “If a channel has an emoji in its name, that emoji is weighted higher in that channel” (WIP).

From a Community perspective, I feel like this makes sense. It’s difficult to choose which emojis to weight more (even the simple ones like :heart:, :+1:, :fire: etc) mainly because its impossible to narrow down/explain use cases. This would both narrow down and explain the use cases in one fowl swoop, while adding minimum stress to community organizers who have to decide on weights.

From a Technical perspective, we are just recursively applying the “one emoji to rule them all” practice to channels instead of the whole discord. This also takes some weight off the one emoji from being a sort of catch-all.

Problems I see include:

  • This might cause some hot/cold channels, where posting in a certain channel is more likely to give you Cred than another channel. I.e a shill channel probably won’t generate cred as much as an art channel.

  • Using two emojis in the title??

  • Rebalancing the Cred graph based on this rule might do some weird things

I got this idea from @decentralion lion wanting to have specific rules in #didathing channels. If this is possible in the future, then I would imagine this is too. Anyway this is definitely a v2 feature, but I thought its a fun idea to let simmer on the grill.

DISCLAIMER: I am not familiar enough with the discord plugin to know how difficult this would be.

2 Likes
2

Thank you for this writeup, @youngkidwarrior! This is very clear (and much easier to grok than what I was able to glean from your explanation on the call, though that might’ve been my internet connection dropping out here and there).

I worry—quite a bit, tbh—about the intense cognitive load that this would create. From a community perspective it’s intuitive, but also hugely overwhelming and easy to get confused. Just today I posted a question in the feedback channel (instead of questions) because it was related to a conversation that had just happened in the latter. If people had responded to that with the ? emoji I wouldn’t have gotten the higher weight.

Furthermore, this also just highlighted a huge confusion issue: reactions do not correlate to the channel emoji at all (and that’s only for when a Discord server even uses emoji in channel names), and would imply incredibly contradictory things at times. A :question:reaction to a question, to me, suggests “what do you mean by this?” not, as your proposal would make it, “this is a great question!”

I don’t think it’s difficult to choose which emojis to weight more. I think different weights are best kept to a minimum because each new addition exponentially adds to the cognitive load of having to remember which one is worth how much.

The cleanliness of the SourceCred custom emoji being worth 16× a regular one is very easy to remember, even if you don’t remember the exact number. (“SC emoji is worth a lot more” is all it takes.) Actually, I was surprised to find out that :heart: and :+1:t3: had different weights as well, since that was never explained anywhere I came across, unlike the SC emoji’s greater weight. Also, I already can’t remember which one is worth how much more than a baseline emoji. ¯_(ツ)_/¯

The specific rules for #didathing and #props are more for adjusting and inverting the Cred assignment, not for the emoji reactions themselves. When you post in #didathing that you, well, did a thing, we’d like (all) reactions in there to count for more altogether, because of the nature of the channel being about “hey I did something <which doesn’t have an automatic Cred tracking mechanism for it>”. Meanwhile, #props is for giving someone else Cred for what they did, but the reactions go to your message, so it has to be inverted by the Plugin / Cred Calculation process, to award the received Cred to the people @-mentioned in the message, and not the message poster (you).

All that said, I’m super grateful for this clear write-up of your idea. Your writing style is nicely compact and yet very comprehensive, I loved the “from the X perspective” approach, breakdown of foreseeable problems, and the premise up front. Thank you! :slight_smile:

4

So your primary worries from what I could glean from your response are

  • makes it more complex, not less
  • misuse of emojis

Two very important things.

I see this as more of a solution to these problems though, as these problems already exist in the current iteration.

In a nutshell, channel name emojis say, “this post embodies the nature of this channel”. (Side note, if the channel doesnt have emojis, then it doesn’t have a channel emoji (It’s a feature)

You use this example.

If it was a question related to feedback then it’s in the right place and it’s worthiness of achannel emoji is up to the same medium of it possibly being worthy of a 16x sourcecred emoji. The channel emoji is like an inbetween for our 1x emojis and our 16x emoji.

It’s much easier to write a single doc about channel rules that apply to all channels then, say, individual docs around each emoji.

I want to hear more about this, because I’ve had trouble assigning weights, and I don’t think the solution is to “use sourcecred less”

5

I’m −1 on this, because:

  • Channel display names are cosmetic, and should not be load-bearing.
  • This would mean that renaming a channel to change its emoji would cause an arbitrarily large re-weighting of cred, which is highly undesirable.
  • As @KuraFire points out, this greatly increases complexity—not just for the SourceCred authors or for community leaders, but for all community members of projects using SourceCred.
  • I do not see what problem this solves.

Do they?

Here is how some of our channels render for me:

Screenshot of the , , , , and Discord channels in the standard channel list UI, with their accompanying emojis

Of these, I see:

  • #props: no idea what that emoji is; maybe :tada: (open party poppers)?
  • #didathing: okay, that’s :muscle:
  • #learning: tofu
  • #inspirations: tofu
  • #social-media: okay, that’s :eyes:

So, two fail to render entirely, and one is indecipherable. Of the remaining, :eyes: is already a commonly used reaction, one of GitHub’s eight standard reactions, for instance, which people already use in their own ways. And while both :muscle: and :eyes: are “sure, kind of related” to their channels, it’s hard to say with a straight face that they “embody their natures”.

My understanding is that the emojis in channel names are simply meant to be decoration, nothing more.

Unpopular opinion, but… I’m not a big fan of emoji :fearful: and if it were just me, I wouldn’t include them in channel names, config files, etc. I tolerate them in the channel names because it’s clear that other people like them. But placing even more load on them for everyone (including me) is not something that I support.

What we want here is indeed different rules, not different weights. Like, “in #props, cred from reactions flows to whoever was @-mentioned in the message rather than the author of the message”. Channel-specific emoji weights don’t seem to overlap with this much, one way or the other.

Okay. Let’s talk about this. What is it that you’re trying to accomplish by assigning custom weights to many(?) channels? Why does it not suffice to have weights for (say) :+1:, :heart:, and :sourcecred: shared among all channels? And how is adding a “channel-specific emoji = 3×” rule different from just adding a “:tada: emoji = 3×” rule?

1 Like
6

Hmmm the names not loading is definitely a wrench in this. I wonder why the ASCII names aren’t loading in your client :thinking:

I was just relating to the channel specific part. Pretty tangential but inspiration comes from anywhere. Hence the disclaimer in the OP about not knowing how complex this change is.

Well it’s two reasons:

  • having more emojis with higher weight will take cognitive load off the :sourcecred: emoji. More available options, means more specificity can be accomplished. Right now, :sourcecred: is kinda a catch-all for greatness, but a lot of things are said that are great that don’t quite deserve a :sourcecred:, maybe because they are specific to a given conversation in a channel.

  • it gives the emoji a reason to be weighted higher, other than arbitrary usage opinions. This is key. There’s just no way to decide any level context to an emoji without having a big explanation per emoji. Since the emoji is the namesake of the channel, there is a purpose written right next to the emoji. It allows for a bunch of meaning to be explained at once.

It’s not about the emoji itself being a perfect representing the channel, but the channel creating a better use for the emoji. It’s the same use case as the :sourcecred: emoji except the specific use case is different for each channel. Sort of a recursive idea, which feels super sourcecreddy

Eyes is a perfect example why this is better than a general weight. :eyes: is very popular. If we weigh :eyes: heavier in all channels, it might change it’s original use case across the entire Discord. We really want eyes to just be different in #social-media, because it’s in the title which would make sense why it’s weighted higher. Having it be channel specific means that change is condensed to a single channel, so this way we don’t ruin an entire emoji. Otherwise we’re pretty much stuck with 1 big emoji and that’s it. There are trade offs, but it seems more useful than it is impeding.

I agree, this is a hard case. Its one of the problems I listed in OP. For one thing, channels rarely get renamed, they are more often deprecated which would avoid this problem. Also, maybe a rule can be made where the previous channel emoji is stored or old scores transfer?

Thanks for sharing some well thought out concerns, Could you explain load bearing to me more? Do you mean technical load, cognitive load, social load?

7

We call a part of a system load-bearing if changes to it would cause broader changes to the system as a whole. The term is often used especially when the property is undesirable.

For instance: the SourceCred codebase has lots of files of source code. Most of the time, the file names are not load-bearing. If I think that trie.js would be more clearly named as prefixTree.js, I can rename it, and the system will work exactly as it did before in terms of correctness, efficiency, cred distributions, etc. But there’s one case where our file names are load-bearing: if a file name ends with .test.js, then it’s treated as an automated test and run continuously to make sure that it doesn’t break. If I rename trie.test.js to trie.somethingelse.js, then the system has changed, because the tests will no longer be run. These file names are load-bearing.

In general, it is helpful to consider whether aspects of a system should be load-bearing or cosmetic. For instance, it seems uncontroversial that usernames should be cosmetic: your cred shouldn’t change just because you rename yourself to @decentralion. I claim that Discord channel names should also be cosmetic.

The distinction is important because people need to be able to freely change cosmetic things without worrying about downstream impact—or worse, without not realizing that they need to worry about this!

2 Likes
8

I see! Thanks, that’s great. I love that distinction.

Maybe instead of having all channel names be affected by default, we could allow a whitelist? I don’t like that much though because people might haveto remember which channels are on/off.