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!".
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.
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
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 email@example.com. 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 http://lego.cuusoo.com
Really Making Badges
Making a badge requires the following:
- An image (with certain properties, TBD).
- A name
- A description
- An http link to any old page describing criteria for the badge.
- A YAML description of the criteria for our fedmsg rules engine.
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 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 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.
- 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