From Fedora Project Wiki

(add resources section containing other badges links)
Line 10: Line 10:
* [[User: timjcasey| Tim Casey]]
* [[User: timjcasey| Tim Casey]]
* [[User:oddshocks| David Gay]]
* [[User:oddshocks| David Gay]]
* [[User:Jenneh| Jenn Kotler]]

If you think you want to know more about what we're trying to do here, you should probably jump on the [ mailing list] and add yourself to the above list.
If you think you want to know more about what we're trying to do here, you should probably jump on the [ mailing list] and add yourself to the above list.

Revision as of 21:03, 31 May 2013

Fedora Open Badges

The general idea is that as you do things as a Fedora Contributor and (eventually) as a Fedora User, we'll automatically issue you badges saying "So and so filed their first bug in Bugzilla" or "So and so closed 10 bugs in one week!".

Interested Persons

If you think you want to know more about what we're trying to do here, you should probably jump on the mailing list and add yourself to the above list.

Two Types of badges

There will be two major types of badges. They are distinguished by what authority can award them: Distro badges and Community badges.

Distro Badges

These are awarded by the "Fedora Project". They are to be automatically awarded by a rules engine that responds to events on the fedmsg bus.

Here are some preliminary ideas for Distro badges:

+ Involvement           Created a FAS account
+ First                 Submit your first package review
+ Reviewer              Complete your first package review of another individual
+ Push'd                Push your first update using bodhi
+ If you build it...    Complete your first successfull build with koji
+ SCM                   Push to the Fedora Package Repository
+ Proven                Provenpackager group
+ Sponsor               Packager sponsor group
+ Top packager          If you have more than X (20? 30?) packages approved
+ Reviewer              If you did more than X (10?) reviews

+ Bottom-poster         (doesn't top-post on email lists).
+ Not a jerk            (awarded by steering committee for handling situations well)
+ Secretary General     (awarded when zodbot notes you as a chair in an IRC meeting)
+ Generalissimo         Member of the Fedora Board, FPC or FESCo
+ Commander in Chief    Fedora Project Leader

+ Bug tracker           if you participated in more than X (20? 30?) bugs that have
                        been closed RAWHIDE, CURRENTRELEASE, or NEXTRELEASE
+ Alpha tester          if you reported X (1? 5? 10?) bugs against an alpha release
+ Beta tester           if you reported X (1? 5? 10?) bugs against a beta release
+ Living on the edge    Reported a bug against a Rawhide critpath package

+ Communicator          Submitted a translation to a Fedora package
+ Polyglot              Submitted two or more languages to a single Fedora package

Community Badges

The other kind of badge will be manually awarded by users in the community. For example:

+ Met $USER in person       Anyone can award this to anyone else.
+ Made $USER's day          Anyone can award this to anyone else.
+ Signed $USER's GPG key    Anyone can award this to anyone else.

+ Crème de la FEM           Awardable only by the Fedora Engineering Manager.
+ The FPL's Blessing        Awardable only by the Fedora Project Leader.

+ FUDCon 2012: ¡Presente!   Awardable by event organizers

+ Fedora ♡ PyCon 2014       Awardable by people running the Fedora booth at PyCon 2014.

For community badges to be awarded, we need a system that allows the awarder to generate a URL and/or QRCode that the awardee can visit to accept.

Badge Submission Process

There are three phases to this, each more complex than the last.

Badge Submission Phase 1 - A mailing list

We need to create If you have an idea for a badge, fully write it up and email it to that list. For a badge to be accepted it needs to be fully defined and have artwork already associated with it. Acceptance is granted when it receives 3 +1s from members of the 'badges-admin' group.

Community badges may be defined by a simple paragraph explaining what the badge is and what it is for.

Distro badges must be accompanied by a YAML file as defined below in the Really Making Badges section.

Both types of badges must be accompanied by artwork in order to be accepted.

Badge Submission Phase 2 - A web form

Only slightly more convenient than a mailing list, this web form just emails our original mailing list and the same rules of acceptance apply as before.

The purpose of the webform is to make the generating of the Distro badge YAML file as simple as possible.

Badge Submission Phase 3 - Opening up the curation process

We build a much more full-featured web application that allows the community to upvote and downvote different badge ideas. Something kind of like

Really Making Badges

Making a badge requires the following:

Infrastructure (the plan)

These will get exported to Mozilla's Open Badges Infrastructure (OBI). See their frontpage for a general introduction and the README for a more technical introduction. This is good -- it means we don't lock in users' badges just to Fedora where their friends' friends will never see them.

Epoch One badge awarding will be driven by the fedmsg bus. For instance, when a user comments on a bodhi update, bodhi emits a fedmsg message. A daemon sitting in our infrastructure catches that message, checks a database[1] to see if that user has ever comment on an update before. If not, then a badge awarded to them for commenting on their first update. Badge awarding means creating an entry in a second database that User X has Badge Y.

That process of checking the fedmsg database[1] will be handled by a rules engine. Rules for badges will be defined in a YAML format described above.

Mozilla's OBI requires that the user authenticate with them over Persona. We do not yet have a way to push badges automatically from our DB to the OBI. A stand-in workaround is to host a webapp that request Persona authn from the Fedora user and then exports our badges to OBI over their json API. This (while not deployed in our infrastructure) actually works.. even if its a clumsy extra step.

Epoch Two badge awarding will be driven by user activity on their Fedora machine. When they run yum update for the first time, or open the gnome-tweak-tool for the first time, a daemon on their machine will make submissions to our infrastructure.. awarding them badges. Epoch Two is not yet well thought out.

I don't want to have anything to do with this

By default, all FAS accounts will be included in the system.

By logging in, to Tahrir, the user should be able to do any of the following:

  • Toggle a flag and receive no further badges.
  • Toggle a flag and still receive badges, but no notifications.
  • Toggle a flag and hide their account and all its badges from being viewed by anyone.

Users should also be able to hide a single or a subset of badges from being viewed by anyone.


  • Spruce up the Tahrir app.
  • Deploy the Tahrir app.
  • Begin awarding badges via the fedmsg bus.
  • Create a process for contributors to submit and vet new badge ideas and details.
  • Write and make available a system for awarding badges from the desktop