Exploring the idea of using Discourse as a badges frontend — the backend implications

Continuing the discussion from Discourse Badges — should we or shouldn't we?:

As Ryan said in that thread, the really hard part is in the backend, not the UI at https://badges.fedoraproject.org/. But, that front end still also needs a lot of work, and there’s a really long list of things to do. So I have the idea of cutting out some of that work by using this site as a front end. Discourse already has its own badges, but they are very tied to the forum itself, and not very exciting. I think we’d leave those on at user-focused Ask Fedora, but just disable them all in favor of our own collection.

I did a little playing around, and it’s really easy (with the right API key) to create new badges — see my example here:

… so I don’t think this would be very hard to hook into the backend (or into a new and updated one).

Part One — the backend changes needed

Fedora Badges Current Architecture

Here’s the diagram of

You can see that what I’m talking about is basically replacing the left part. I can think of two ways to do that. And in fact, we could do first one and then the other.

Approach One: Keep the tahrir database

With this model, that cylinder in the middle left would stay. We’d need to update the fedbadges consumer to use Fedora Messaging and Python 3, and as well as tahrir api — that latter might already be done? — but basically they remain the same. They keep feeding badges into the database.

Then, we’d write a new little thing on the left side of that that would watch for those changes, and basically do what my script does: create any missing badges on Discourse, and award users any new badges. (There would also need to be a hook for when someone new logs in, to activate their back-catalog of badges.) There’d also be a process to remove any badges that someone’s not supposed to have.

Approach Two: Drop the database

Here, we’d back up the tahrir database, and replace tahrir_api with something that takes the same inputs but acts directly on Discourse — basically, Discourse becomes the database. Basically instead of putting (an extended and polished, of course) version of my script on the left side of the database, we’d put it on the right side.

We’d still need to update the fedbadges consumer, and probably also adjust all of the other users of the API (although there could be a shim).

With this, there’s fewer moving parts, and one less database to worry about.

One catch would be that we’d have to either create accounts on the site for each user

People who know more than me about this…

What am I missing?

Like, how do invitation links and qr codes work? I would conceptually expect them to feed into the right side, but they’re pictured on the left. Also, I don’t know what the admin panel on the website actually allows and how it compares to the Discourse badges admin panel.

Also, tomorrow…

Thoughts on the front-end. (Like, what’d be like if we just did the above, what we’d be missing.

1 Like

As far as I can see you can’t get the leaderboard functionality like you get with the current badges.f.o. However, it seems there may be some additional options for admins as discussed New Leaderboard/User Directory Features 🎉 - announcements - Discourse Meta , and there are also potentially options around custom plugins, which might generally be much less work than the current custom badges webstack.

1 Like

Yes, exactly my thought for that — add a badge count column to that, and there we go!

You can see it in action here: http://discussion.fedoraproject.org/u?order=days_visited&period=yearly. That already has some changes I’d like — total reactions instead of just likes / dislikes, for example. (It’s already possible to reorder remove columns, and we could remove some of the less interesting — do we need both “topics viewed” and “posts read”?