What's my next badge?

August 20, 2016
Tagged as: Fedora, badges, Python.

I love Fedora Badges. I'm not saying all I do is to get more badges, but it's a great motivator. One thing that somewhat miss a guidance on what options I have, what should I do to get another badge, how much activity will it need.

Fedora Project is not the only community that awards badges to its members. For example Stack Overflow has badges as well. In you Stack Overflow profile you can see which badge you are likely going to get next and how much progress you have made on that.

Badges on Stack Overflow
Badges on Stack Overflow

Is it possible to do something like this for Fedora badges? Turns out it kind-of is. There actually is [a related issue] filed for the awesome Fedora Hubs project to show options of next badges.

All this actually relies on having information about badge paths, but until it's available in production, it can be reasonably hacked based on badge name and a short list of exceptions.

Baby steps

First thing that comes to mind is to simply look at statistics of the badges. The ones that are awarded more often are most likely the easiest to get. Let's start from that by finding the 5 most common badges that I don't have yet.

However, just taking that is not a particularly good suggestion: in my case 3 out of these badges turn out to be "have FAS account for at least X years". I'm slowly getting there, but there's not much I can do to speed this up. It makes sense to only show the first badge from each series.

dont-call-it-a-comeback icon egg icon curious-penguin-ask-fedora-i icon crypto-panda icon speak-up! icon

Progress towards next badge

Before we can estimate progress on getting a badge, it is important to understand how the badges are awarded. The system is based on the messaging bus1. The fedbadges service listens to the bus and every time it sees a message, it checks it against the rules it has defined.

The process starts with a simple check on the message content to make sure that the message is connected to some badge. If it is, more complex checks are performed. These checks either communicate with pkgdb or datanommer, the service that archives old messages.

Now obviously I'm not keen on reimplementing the whole rule engine. Fortunately, it is possible to reuse the code from fedbadges. All badges that I care about for this part only need the datanommer integration, so that is a big help.

The biggest issue I faced with this is the fact that fedbadges connects directly to datanommer's database. I can't do that. My workaround was to write a script that would download all messages related to me from datagrepper and store them locally. This works reasonably well for me personally, but trying to get the messages for someone who is active for a longer time is going to be an issue.

Unfortunately, the list of messages related to a particular user is not enough for all badges: Bodhi has badges for other people voting on your updates. Therefore we also need all messages related to updates a person creates.

47 / 50
8 / 10
6 / 10
11 / 20
25 / 50
438 / 999
2 / 5
146 / 400
87 / 250
34 / 100
24 / 100
1 / 5

Another problematic badge is the Cookie one: the number of cookies you have get's reset every release cycle, so despite the number 8 above, I actually only have 1 right now.

I want it too

If you want to experiment with this code, I put it on Pagure as my-next-badge. There are instructions in README. I didn't try to optimize this in any way (yet), so it needs a lot of memory as all the messages must fit there. In my case, it is about 40 MiB. For other people, it might be significantly more. By "more" I mean it can easily be several gigabytes.

If you decide to try this, please note that the script is a hack that may not always be correct. It may try to convince you that you satisfy conditions for some badge even if you don't have it. Take it with a grain of salt.


  1. Well, almost. Some badges are awarded manually. We can ignore that here.