Jay discussed this on Bugzilla. He described badges as "areas of expertise as defined in the profile or determined via our own game mechanics (which we can develop in the future)."

In the meeting yesterday, someone also shared the idea of badges rusting over time. This could be used to encourage contributors to stay active even after earning a badge.

In talking about permissions, Sheppy made an interesting point that might be relevant to the Badge system. "I'm not sure of the best way to handle stuff like that... probably to have categories of users. This category of user is allowed to upload these additional types of files, admins can upload anything, that kind of thing." Do we think it would be worthwhile to provide a badge for each type of user? An administrator badge, a newbie badge, etc. Reddit does something similar (https://pay.reddit.com/help/awards#shutterbug), as do many forums.

I don't know if we should overload the badge system for access controls.

Since I just saw this bug, 2 thoughts: * Let's use django-badger, yay! * It might be interesting to have both automated and manual badges for MDN. That is: 1. Badge awards generated as a result of certain classes of site activity 2. Badges awarded at in-person events like Hack Days and conferences For #1, we'll need to come up with an initial set of badges and programmed criteria before feature launch. Those can of course be expanded on an ongoing basis, but will require code pushes to support additional programmed criteria. But, for #2, we can create new badges on-demand before events. I think the main question there is one of access - would administration of in-person badges be limited to devengage people, or would we want to open that up to more community members? An interesting feature from django-badger for events is that it can generate single-use and reusable claim codes for badge awards. So, imagine you have a talk and want to give away a badge to attendees of the talk: You can hand out physical printed badges to everyone with a claim code, or write a 6-character code on a whiteboard for everyone to use.

Seems like there's not a reference to this anywhere, but Janet had started a badge system design spreadsheet for MDN: https://docs.google.com/spreadsheet/ccc?key=0Ao_fDuA-PPFydDYxRjdmTFZURy1MY214SlRoX0kxYWc

Note that the spreadsheet linked above currently lists badges in category #2 (event-based ad hoc), not category #1 (based on site activity). I think it will be easier to implement ad hoc badges, and figure out the activity-driven badges later.

This is a larger project and the linked wiki page has some more information. This bug should become a tracking bug, where sub tasks are still to be defined. As indicated in the whiteboard, this needs more definition, too. I'm trying to drive this forward.

I filed bug 968386 to get an MDN badge styleguide from creative so we can self-service at least some visual assets. :fscholz proposed a first set of content badges here: https://docs.google.com/a/mozilla.com/spreadsheet/ccc?key=0ApeHsuEebcoRdFZVbER3a0NEbk1hUTBvV2UyM01Ra1E&usp=drive_web#gid=2 :lorchard, which of those are technically the easiest to implement first so we can start measuring badge usage and impact? :fscholz, can you speak for the content team and work with :lorchard to select the first set of badges to implement?

An important note about that badge spreadsheet: It collapses permutations that actually represent multiple separate badges. That is, while the spreadsheet lists 10 badge concepts - it potentially specifies close to *100 concrete badges*. Each of those will need creative and code to implement. We should be able to script the creation of some of them, but it needs to be taken into account for creative at least. For example, each "level" is itself a badge. Some of the badge concepts list 3-6 levels each. Same for things like "MDN <locale> Translator" - the fill-in-the-blank <locale> needs to be paired with a list of locales. MDN currently supports 34 locales, so that means each of those rows in the spreadsheet collapses 34 badges into 1 concept.

Will mentioned that we should not issue a badge (for the automated number-of-edits badges) when someone creates an empty revision. Marking bug 812157 as dependency here.

Can we come up with a smaller list of badges for Les to implement first? Les, if I understand it correctly, these permutations are technically possible but we would need graphics from the creative team for each badge and that adds up to a lot of badges with the current ideas we have. I think the levels might look similar, not sure if we can automate the graphics creation. So lets say we take 2 badges (edit a doc and create a new doc) Complexity levels: Level 1-6 = 2 * 6 = 12 badges Chosen locales (5) = 12 * 5 = 60 badges Zone badges are a good idea (Chris Mills idea here https://wiki.mozilla.org/MDN/Development/Badges#Badge_ideas), but I think we want to skip that for the first implementation. Questions: * Do we want less complexity to avoid 60 badges? * Skip locales for now? * Do we agree on the levels? What are the exact numbers to reach each level? What I have written in that spreadsheet were just ideas, let's brainstorm on these more and have agreement on a plan of what we want for the first implementation and for later. Thoughts?

(In reply to Florian Scholz [:fscholz] (elchi3) from comment #13) > Can we come up with a smaller list of badges for Les to implement first? > > Les, if I understand it correctly, these permutations are technically > possible but we would need graphics from the creative team for each badge > and that adds up to a lot of badges with the current ideas we have. I think > the levels might look similar, not sure if we can automate the graphics > creation. Yeah, I should be able to write code something like this to generate the badges: for level in (1, 2, 3, 4, 5, 6): badges += { "slug": "mdn-editor-%s" % level, "title": "MDN Editor Level %s" % level } And then, it's an additional 2-3 lines of code per badge detect 5, 42, 100, etc edits as awarding criteria. Needs to be taken into account, and it adds up, but it's not awful. Being as I'm not a designer, I can't really speak for how that might be automated. So, yeah, I'm more concerned about the work there.

Another point to be defined: The end-user views for manual badge creation, awarding, nomination are disabled. Meaning that only admins (admins = not the whole community, but MDN admins) can create manual badges through the django admin interface and award them there and also a nomination form allowing one community member to nominate another community member for a badge is disabled currently. Are the different stakeholders who want to issue badges all okay with this?

I'm sure we'll want to enable community-made manual badges in future iterations. Do you think community-made manual badges should be part of the first set of writing-oriented badges?

No, speaking for the writers, I think we are fine with it for the first iteration (we want it in the future probably). Janet and others are CC'ed. Please jump in, if this is not the case.

(In reply to Florian Scholz [:fscholz] (elchi3) from comment #17) > No, speaking for the writers, I think we are fine with it for the first > iteration (we want it in the future probably). > Janet and others are CC'ed. Please jump in, if this is not the case. Agreed; we're fine with this for starters.

Unassigning, I am not driving this anymore.

I've created a Trello board to track feature requests and development (we'll file bugs as features are selected from the board): https://trello.com/b/HMrxxHdp/badges

Since it isn't linked here yet, here's the etherpad from the DevRel work-week where we last discussed the first set of badges: https://devengage.etherpad.mozilla.org/devrel-workweek-2014-first-mdn-badges Understanding that things may have changed and we may want a new first set now.