Closed Bug 671908 Opened 13 years ago Closed 6 years ago

profile: Badges

Categories

(developer.mozilla.org Graveyard :: Profiles, enhancement, P2)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: openjck, Unassigned)

References

()

Details

(Whiteboard: [user-interview][triaged][type:feature])

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.
Whiteboard: u=contributor c=profiles p= → u=contributor c=profile p=
Blocks: 653849
Priority: -- → P2
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.
Whiteboard: u=contributor c=profile p= → [user-interview] u=contributor c=profile p=
I don't know if we should overload the badge system for access controls.
Blocks: 756266
No longer blocks: 653849
Priority: P2 → P3
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.
No longer blocks: 756266
Blocks: 756266
Version: Kuma → unspecified
Component: Website → Landing pages
No longer blocks: 756266
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
Priority: P3 → P2
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.
Component: Landing pages → Collaboration
Whiteboard: [user-interview] u=contributor c=profile p= → [user-interview]
Component: Collaboration → User profiles
Whiteboard: [user-interview] → [user-interview][needs-definition]
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.
Assignee: nobody → fscholz
Depends on: 960835
Depends on: 968386
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?
Flags: needinfo?(lorchard)
Flags: needinfo?(fscholz)
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.
Flags: needinfo?(lorchard)
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.
Depends on: 812157
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?
Flags: needinfo?(fscholz)
Depends on: 971709
Depends on: 971715
Depends on: 971717
(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.
Depends on: 971733
Depends on: 971823
Depends on: 971843
Depends on: 971864
Depends on: 971876
Depends on: 971880
Depends on: 971886
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?
Flags: needinfo?(fscholz)
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.
Flags: needinfo?(fscholz)
(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.
Depends on: 973963
Severity: normal → enhancement
Whiteboard: [user-interview][needs-definition] → [user-interview][triaged][type:feature]
Unassigning, I am not driving this anymore.
Assignee: fscholz → nobody
No longer depends on: 968386
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
Depends on: MDNProfiles2
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.
Depends on: 1174275
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.