Badges for Ask Fedora (and Fedora Discussion overall)

Continuing the discussion from Magical Experimental Fedora Badges Topic!:

Chris noticed that I turned off the built-in Discourse badges on Ask Fedora. They’ve been turned off on this site for a while.

Most of these are for little things encouraging you to try site features – like “First Reply by Email” and so on, but also there are things like “Know it all” for having 50 replies marked as solutions, or “Devoted” for visiting every day for a year. (See Discourse Meta for a list of these built-in badges.) I don’t mind the first type, but don’t think they’re really necessary to learn site features. On the other hand, I think the ones that really reward and celebrate active, constructive participation are important.

What’d I’d really like is to have some Fedora Discussion and Ask Fedora badges as part of Fedora Badges. Let’s brainstorm what those might be!

  • an increasing series of badges for asking questions in the Ask category (maybe specifically questions which get a certain number of positive reactions?)
  • an increasing series of badges for providing solutions in Ask
  • days-visited seems fun too
  • a badge for having posted in an Introductions thread
  • conversation starter: number of topics created (maybe “with at least one reply by someone else”?)
  • conversation participatant / number of replies
  • an increasing series of badges for various post reactions :classic_smiley:
  • and also for giving other people’s posts likes and reactions
  • badges for serving as a moderator
  • badges for reaching each trust level
  • maybe some of the entry-level “first post” kind of badges?

I’m not quite sure of what mechanism we’d use to award these (since we don’t have reliable message-bus history for every post – there is a bridge, but it doesn’t cover everything and has had some reliability problems). But I’m sure we can figure something out once we decide on what we want.

5 Likes

Absolutely agreed!

With regards to the constructive participation, I think getting positive reactions (such as “likes”) but also distributing positive reactions to others should keep encouraged. The same for providing solutions. With regards to the latter, I think that the solution function is not really in use and many people just leave the topic as it is once their problem is solved (without marking a solution). Maybe it could be also some incentive (=badge) for people to mark solutions (…from others…) once a topic is solved? At the moment, the “solution” badges for those who provide solutions do not provide much incentives since it is arbitrary if the solution function is used once the topic is solved. At least people who regularly ask questions could be triggered that way to mark solutions if applicable. Obviously, this is not necessarily only about ask.fp. Just some idea :wink: Call it a mutual encouragement or such :smiley:

2 Likes

Yeah — there are some pop-ups asking the OP if their problem is solved, but they are easy to ignore.

Also, on Ask, the trust level required to mark a solution for someone else’s question was set to 3, and I’ve set it to that here now too in anticipation. (From the default of 4.)

I think a badge for this is a good idea, but also I think we should create a norm where mods and high-level users mark solutions after a few days. (And maybe have a separate badge for that!)

(Practical suggestion for tl3+ — if a question appears answered correctly, set a timed bookmark for 3 or 4 days later, and then when that pops up, mark the solution. Assuming of course there are not new developments.)

1 Like

I have seen this used on another Linux forum I was on and it was very motivating for people. They were actively trying to help users and solve their problems because of those badges.

I think the levels for badges on that site was 1, 10 and 100 solutions. It was a reasonable balance.

4 Likes

For the record[1], the way we’d implement this is using Data Explorer. This lets us craft (possibly pretty complicated) SQL reports, and those reports can be accessed via the API (and there is even a granular API scope which would limit to specific queries, so we could have some queries that might include more personal information[2] and keep those restricted while allowing a script to call just the ones needed to see who should be awarded discussion/ask-related badges.[3]


  1. and maybe specifically for @t0xic0der :classic_smiley: ↩︎

  2. not for badges, but for whatever other administrative thing ↩︎

  3. Because awarding badges manually should be a last resort! ↩︎

1 Like

This part gives me greatest pause because while it is important to know what we want, the implementation details matter and can shape what we can realistically deliver.

If I understand it right, this is building another badging layer into our existing plethora of badges, including the Fedora Badges platform. This would exist independently of any other badging solution or stack, as far as I understand it. The badges would also be exclusive to Discourse and would not be shared back into a Badges database.

Perhaps we could put some ice on the topic of pushing on badges so hard, at least for right now? If we set this up and launch it, it adds more complexity to the existing work for the Badges revitalization effort, and then the people who are doing the work have more arbitrary work introduced to figure out how to backport some other mechanism for badges into the new system.

Discussing the semantics and logic is fine, but I really, really, really, really want us to pump some brakes on implementing badges for now.

See the comment just above yours, where I answer myself.

No, that’s exactly not what I’m suggesting. To quote myself:

1 Like

As part of the Ask/Discussion merge, I have left the Discourse-internal Super Helper badge in place. That’s awarded for providing 10 solutions to questions in Ask Fedora. I’m thinking of this as a kind of stop-gap until we can get Real Badges working.

2 Likes

Bumping this again — let’s get this going!

What badges could we have?

What’s possible? Anything that can be reflected as a SQL query using Data Explorer. That’s very flexible, so… pretty much open to the imagination.

You can see the built-in badges for Discourse at Discourse Meta: Badges for some ideas.

Specific suggestions:

These are what I’m proposing initially:

Single-event badges:

  1. Signed in for the first time
  2. Filed out profile
  3. Posted in an introductions topic
  4. Liked (or other reaction) a post
  5. Posted a topic with over 1000 views
  6. Started a topic with 100+ replies
  7. Posted something that got 100+ likes and reactions
  8. Custom, fancy badges for TL2, TL3, TL4.
  9. Participated in a Changes conversation
  10. Visited every day for a year (update: make this a series with 1, 7, 30, 90, 365)

Series (1/10/100/1000, or whatever):

  1. Asked a question in Ask Fedora, marked a solution
  2. Topics started in Project Discussion
  3. Topics started in The Water Cooler
  4. Total replies (anywhere)
  5. Solutions provided in Ask Fedora
  6. Posts read
  7. Days visited
  8. Total Likes & Reactions received
  9. Added tags to a topic in Ask Fedora
  10. Recategorized a topic

That’s twenty different ideas … am I missing anything that seems initially important? Are there some of these that we shouldn’t do?

1 Like

This one may be very difficult to ever receive depending on how it is calculated and upon the users activities. Everything else looks good to me.

1 Like

There is a built-in badge (“Devotee”) for visiting daily for a whole year, so I’m assuming there’s a reasonable way to get that from a query. Haven’t actually looked. And yeah, it’s kind of an obsessive feat.

They also have 10 and 100. I suppose we might as well do those too, as more achievable levels. Or 7, 30, 100, 365?

The latter (7,30,100,365) seems good to me. It would provide more attainable goals at the beginning,

Is this the sums of a whole topic or just on one request?

We could do whatever, but in this case was thinking about a single, individual topic.

Concerning: “1. Asked a question in Ask Fedora, marked a solution”

Is this intended to be one badge? So, first ask a question and then mark
a post as solution in order to get the badge?

If so, my suggestion would be to split this in two different badges. We
cannot solve any topic, and merging the badges for creating +
mark-a-solution of a topic might trigger people to mark inappropriate
posts as solution to move on with their badges in cases where the topic
was practically not solved.

Just some thoughts :slight_smile:

True, we want to incentivize good behavior. But if someone wants to game the system, they might ask a dozen different questions for no real reason.

Moderators can remove or change obviously-not-right solution marks, so it’d be really hard to get up to 10 by cheating.

Yeah, that’s indeed a good point I missed. I am still not convinced that
the majority of solved topics are reviewed by moderators/TL3/4 after
they were solved, and the alternative is to ask many easy to solve
questions. But it is indeed a compromise in both variants, and the
“entry barrier” to cheating in yours is likely higher. So I’m fine with it.

To help the conversation and to create a proof-of-concept for this, I worked on some of the queries @mattdm defined above to provide some templates for Data Explorer. I got though the single event badges, and I will also attempt for the series generated badges.

The way I wrote these assumes there is some sort of process attempting to parse though these results and apply it back to the Badges API. Some of these queries like 5/7 should be validated for their run time as I wrote these against a fresh Discourse server just to learn the Discourse database. It’s likely with production data these will not be performant. :sweat_smile:

2 Likes

Cool, thanks! I’ll set them up so we can see!

Some what of an important question - do we need to know “when” a user achieved each milestone? Or is it sufficient to know that they have achieved the milestone or not?

In the way the queries were formatted for the 20 badge types, I wrote as many as I could except 2 of them to show the timestamp when the user achieved that milestone. But if when it goes back to Fedora Badges, it will always grant at the current timestamp, then I can rewrite many of these queries to be much more performant and use the summary tables.

1 Like