Make MDN to act as
1) an issuer of badges (both, automatically and manually),
2) a displayer of badges (in the user profile) and
3) add badges to the user's backpack (using openbadges.org Issuer API).
- (Tracking) bug
- See Badges about what badges are and why it's awesome.
- lorchard also wrote an article about "Why does Mozilla need a Badger?"
- See badges.mozilla.org for what the Mozilla community is already awarding
- What are our goals for issuing badges? What behaviors or activities do we think badges will promote?
- Who are the audiences for badges? Who earns them? Who "consumes" (looks at and cares about) them?
- What are the users' goals in pursuing badges?
- How does a person change or grow in earning badges?
Badges ideally have an awesome design and/or a funny name, don't be boring here :)
The Badge Design Canvas from digitalME could be a handy thinking tool for defining the particulars for each of these badges.
In reference to Florian's work sheet (https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0ApeHsuEebcoRdFZVbER3a0NEbk1hUTBvV2UyM01Ra1E&usp=drive_web#gid=2)
The ideas here look good so far, although the specific criteria for success and achievement numbers could do with tweaking. What thought process went into choosing the numbers? Something like this could perhaps work, e.g. for a “general edits” badge:
- Work out average number of useful edits per week by active contributor (e.g. someone who has made an useful edit in the last 6 months)
- Work out the number of edits they could do in say
- a week
- a month
- six months
- a year
- three years
- 10 years
- Set the numbers for level 1-6 to those numbers
So if you are an average contributor then you might get up to level three without too much trouble, but it would take ages to get to level 6. Whereas if you really want to earn your top level badges, you have to start putting a bit more time in, to “farm” the achievements.
We could run a beta period and see how this feels to everyone.
Other ideas for badges:
- badges for contribution to specific zones/topic areas, e.g
- Platform (Firefox OS/Firefox/Fennec)
- Code/demo writing contributions
- Kuma bug fixes
- MDN diplomat (helping others on the mailing list, resolving disputes, not sure how we’d measure this)
One, pretty obvious, comment: before we start issuing badges based on automated number-of-edits criteria, we should be able to exclude edits that were reverted, and "nothing edits" when someone just clicks "Edit", then "Save".
Based on amount (1/25/100/250/...):
- [number] edits made
- [number] new articles added
- [number] new translations added
- [number] technical/editoral review flags cleared
- "<h1>", "<h2>", "<h3>": Has made 100/50/10 edits in open web documentation.
- Article of the month
- DevDerby winner
- "Sherlock" badge: Has found a problem on Kuma and reported it in Bugzilla
- DocSprint attendee
- Set up and ran Kuma (already on badges.mozilla.org)
- Helped to set up Kuma for a new contributor
- "!important" badge (no idea for this yet, but I like the name. Maybe some kind of an important contribution)
- Has written a hacks blog post
- Has written a complete tutorial on MDN (we want more of those!)
- Has written a tool (like the box shadow generator page)
- "House keeper": Has cleaned up hundreds of pages (like ethertank)
- 3 DocSprints attended in a row
- 3 DevDerby wins
- I've (Chris Mills) been thinking a lot about beginner's material recently, and would love some kind of system whereby badges could be awarded to readers that work through beginners' tutorials and complete certain exercise questions successfully. But this would require a bunch more long term thinking.
Inspiration: SUMO's implementation
Additional thoughts / requirements
- This got shared with the open badges folks, but I want to mention this here, too: To add some (more) value to a badge, it would be nice if you are able to see "awarded to xy contributors". So that you can be (even more) proud of a badge, which is only awarded to a small amount of people.
- Hope to have this rather sooner than later, but this could be a Google Summer of Code project probably, if we won't have it earlier.
- (Mail from Robert Nyman) Evangelism Reps badges, MDN badges, Developer Program members badges? Need to evaluate if it should be the same badges or badges program/initiative.
- (Luke) We should track the open rate and the claim rate across cohorts and segments so we can sense the badge fatigue if/when it starts
- MDP badges Toronto etherpad
- MDP badges wiki project page
- sumo-badges etherpad
- SUMO's tracking bug
- django-badger (lmorchard for the win!)
- kbadge (sumo implementation)
- Badge System Design wiki
- Feedback / more ideas
- Reuse parts of SUMO's implementation?
- Have an actual tracking bug with sub tasks