Reputation/badges system for drupal.org: proposal

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Part 1. Voting system to recognize contributions/expertise

Basic functionality for this part is written - Reputation module.
Take a look at demo site. Feedback is welcome. Especially code reviews!

We define a list of types of contribution - up to 6, "+1" widgets on comments in issue queue, forums, doc pages, g.d.o posts etc. let users vote for comment and specify type of contribution they wish to recognize.

Example list:
Code
Design & UX
Documentation
Support
Project maintenance
Event organizing

Voting results will be shown in 2 places:
1. If comment has votes they will be shown right on it e.g.: "Votes by: user1, user2 ,user3 and 4 more"
2. On user profile page - aggregated information: how many votes user has per type of contribution (this will be changed to show not exact numbers but range e.g. "over 5", "over 10")

What this will let us do:
a. show "who is who" in the community, make it easier for the new people, make it easier to make a judgement on the value of a comment
b. recognize non-code contributions which can't be counted by number of commits or other such data
c. show support of comments by other users, this will eliminate the need for "+1 to #21" type of comments - you can just vote instead
d. provide an easy mechanism to say "i agree", "thank you this was useful", "you're doing great job" etc. which will encourage people to contribute

Part 2. Official "team badges"

These will function via a mechanism of adding d.o users to "teams" such as UX team, Doc team, Security, X core subsystem maintainers etc. Each user added to a team automatically gets "Member of Y team" badge on user profile.

Each team has couple of team leads, who will be responsible for adding/removing people from team list. Team leads get special badge "Y team lead".

What this will let us do:
a. "officially" recognize people active in a certain field
b. expose community structure, make it easier for new people to see who is who
c. adding special badges for team leads will help to make decision processes more clear, show that specific people have authority to make specific decisions

Part 3. Activity badges

These will function via a mechanism of automatically rewarding users with badges for specific actions.

List of actions/badges to be defined, examples are:

  • Encouraging first contributions
    badge for first vote you got on your comment, badge for first uploaded patch, first doc page edit etc.
  • Badges for specific levels of contribution
    for example for 1000 documentation edits, or 1000 commits, or 1000 reputation points, or 10 years member of the site etc.
  • Badges for specific 1-time events,
    for example for module maintainers who took D7CX pledges and actually had D7 versions of modules ready on D7 release day.
  • Badges for attendance of DrupalCons and Camps to encourage wider participation, participating in code sprints etc.

What this will let us do:
a. add a bit of "gamification" into community processes
b. encourage more contributions by rewarding people


Previous discussions in Prairie:
Exploring Solutions: Showing Reputation/Experience on Drupal.org profiles
Reputation systems: how others do it
Reputation/expertise system: initial draft

Comments

+1 :-)

Crell's picture

I overall like this plan. My one question is on part 1, for the different "axes". It's not clear from the description above how I'd "categorize" a comment. "+1 this was helpful in relation to UX"? I don't see how "documentation" works as a category for that sort of interpretation. Same with security. Figuring out the right set of axes so that their use is obvious will be a challenge.

I assume this will apply on all comments, including those in the issue queues? (So those of us who live in the queues but never go to the forum are on equal footing.)

Also, g.d.o lets you vote up or down on a comment. Has that been discussed for d.o and rejected, or "this comment is wrong, don't listen to it" something we want to capture, too?

"+1 this was helpful in

tvn's picture

"+1 this was helpful in relation to UX"?

Yes, something like that. Sort of "+1 this comment is useful patch review", "+1 this is good idea for UX", "+1 great design mockup". Only there are so many different things that can be in comment so we had to collect them into more general categories, otherwise list can get really long.

I don't see how "documentation" works as a category for that sort of interpretation. Same with security. Figuring out the right set of axes so that their use is obvious will be a challenge.

You are right! It is a challenge. I am open to any ideas on the list of axes. So I agree security probably won't work. Documentation was originally added when we planned to vote on doc pages itself. Now that we vote only on comments maybe it still will work for say "+1 this is great idea for Docs" on documentation issues in core queue and Docs project?

I assume this will apply on all comments, including those in the issue queues?

Of course.

Also, g.d.o lets you vote up or down on a comment. Has that been discussed for d.o and rejected, or "this comment is wrong, don't listen to it" something we want to capture, too?

For the system we wanted:
- possibility to differentiate types of contribution - so simple +1 from g.d.o won't work
- no negative scores and negative voting at all - only recognize when contribution is positive

Like it

quicksketch's picture

I think this looks like a great idea. Drupal.org was never intended to be a stackoverflow-style site, but that doesn't mean we can't draw some of the practices from them (and countless other merit-systems). I think it's great that this approach will give some sort of metric for non-coders, and I love that it's centered around positive feedback (+1s, not -1s).

Great Idea

jlab's picture

I'm all in for something like this... This will make reading reading forums and issue queues a better experience.

Good idea

svettes's picture

I love the idea that these +1's will aggregate thankyous on a user's profile, what a great way to recognize and encourage community involvement.

Questions:

Pt1 & pt2 point A-- help users find leaders -- are you going to include this info in user search criteria? Or perhaps feature on some pages on d.o to do with mentoring?

Votes on a user: what kind of notification to the user who gets the vote?

Pt1 & pt2 point A-- help

tvn's picture

Pt1 & pt2 point A-- help users find leaders -- are you going to include this info in user search criteria? Or perhaps feature on some pages on d.o to do with mentoring?

Something like this should be done, though we should be very careful of not creating "leaderboards" and the feeling of competition.

Probably vote results on user profile could be links to lists of people who also have any votes in the same category, similarly to "People that have worked in the X industry".

Votes on a user: what kind of notification to the user who gets the vote?

We haven't considered any notifications yet, but I agree that would be good. Maybe we can show votes you got on your dashboard. Or use email notifications, with possibility for user to opt-out of course.

Dammit.

svettes's picture

I made this long, thought out comment and somehow lost it :( -1.

Anyway, gist of my thoughts on voting in a discipline were...

  • expose community structure, make it easier for new people to see who is who
    => so we want to find leaders, but we don't want a leaderboard... can't wrap my head around that. Help me in my ignorance to better understand this :)

Maybe we should kill the idea of listing leaders based on voting, and instead focus on badges to establish leadership and use voting to simply relay public consensus on comments. Just a thought.

(Also: why would users be searching for people who had votes in a particular discipline, is that redundant wrt the "groups" functionality?)

About notification...

I am anti-email notification for voting, could get annoying really quickly if your comment is popular! I do like your idea of seeing votes on your own dashboard.

we want to find leaders, but

tvn's picture

we want to find leaders, but we don't want a leaderboard... can't wrap my head around that. Help me in my ignorance to better understand this :)

So but not having leaderboards I meant that we do not want to have lists like:

UX reputation:
1. userx 2000 points
2. usery 1900 points
3. userz 1800 points
etc.

So maybe we could make such lists (if we need them at all) a bit less competition-promoting.

Say:
Most voted in UX
Over 1000 votes: userx, usery, userz
Over 500 votes: userp, userq, userr
Over 250 votes: userk, userl, userm

Or without vote numbers at all:
Most active in UX:
and list of icons of top 30 users without actual points

I am anti-email notification for voting, could get annoying really quickly if your comment is popular

Yeah, that was just a random idea. Although maybe we could send emails once per week with the list of your top voted comments.

Everyone should read

sun's picture

Everyone should read http://groups.drupal.org/node/209448 first. Explains background information and considerations.

While the voting in categories idea sounds good, I'm concerned about the UX, and will almost predict that it's going to be too complex to be actively and frequently used in the end.

Likewise, I wouldn't want to see drupal.org issues to be cluttered with lots of disturbing funny social gamification "information" all over the place. Merely the +1 widget alone will add noise on its own, and I'm not sure I really want to see who and how many voted for every. single. comment. on. an. issue. (perhaps the mindset will change over time, but right now, this sounds rather horrible than helpful)

Daniel F. Kudwien
unleashed mind

I'm concerned about the UX,

greggles's picture

I'm concerned about the UX, and will almost predict that it's going to be too complex to be actively and frequently used in the end.

Luckily we can test this by deploying, monitoring use, and refining.

Likewise, I wouldn't want to see drupal.org issues to be cluttered with lots of disturbing funny social gamification "information" all over the place. Merely the +1 widget alone will add noise on its own, and I'm not sure I really want to see who and how many voted for every. single. comment. on. an. issue. (perhaps the mindset will change over time, but right now, this sounds rather horrible than helpful)

Keep in mind with this criticism that you are not the intended audience for this tool. You already have a mental map of the project and know most of the people and can say "this person is a long standing community member who knows subject areas Foo and Bar but has weird ideas when it comes to Baz." The idea is that we make that knowledge more visible for people who are new to the community. They will benefit from this the way you do now. And, if advanced users dislike it then they can use dreditor and userstyles to hide it.

I like most of this, but

greggles's picture

I like most of this, but wonder about the team idea in general and about the "team lead" badge idea specifically.

The fact that I'm security team lead doesn't mean my ideas are more right than others when it comes to security. Can we have some discussion (maybe it happened and I missed it) with other "team leads" to see if they like the idea?

I would rather if we could display a badge to indicate "lots of positive votes in field X" for people rather than manually maintaining lists of "teams." My fear is that people will say "I'm not on team X so I guess I can't discuss that topic" and then censor themselves and not provide some great idea.

I actually disagree with Crell that a comment can't be good from a security perspective. Many issues on d.o go like this:

  1. idea
  2. idea tweak
  3. idea tweak
  4. patch
  5. review
  6. new patch
  7. review that includes security component missed in earlier discussion
  8. new patch
  9. review that includes UX review
  10. new patch
  11. commit

Certainly we can give +1 security and +1 UX on comments #7 and #9 respectively.

I also share this concern, as

webchick's picture

I also share this concern, as well as the concern of how to "gracefully" remove the badge from another person who is no longer part of a team, due to time constraints or due to destructive behaviour.

However, the thinking there is to try and provide transparency to new users in the community on a situation like:

  • Bunch of people arguing about what colour to paint a particular bikeshed
  • Seemingly random user A says "It should be green."
  • Everyone else says "Ok, green it is."

Identifying random user A as the Bikeshed Maintainer in the stream makes that interaction make a lot more sense.

Badges: That makes sense.

svettes's picture

Ok I can definitely see the usefulness of badges in that context: an indicator of authority would help new users to know who they're talking to, and understand that motivation behind decisions probably has something to do w/ that user's prev. experience.

I'm curious as to how we are currently de-maintainer-ing things? Does someone just say to the maintainer who's not maintaining - I'd like to maintain this, can I have the maintainership?... maintain... just one more for good measure.

If so, (request => acquiesce) is all it takes, then the magic "list" could be managed in the same way.

"Maintainer" is such a boring

zenlan's picture

"Maintainer" is such a boring 'role', sort of like condemning someone to be shackled to a millstone for life and robbing everyone else of any ownership.

Semantics worth changing at this point?

svettes's picture

I wonder if this terminology of "maintainer" is worth debating... if it's adopted/accepted by the community, then I wouldn't suggest changing it -- but what do I know :P

Also, a rose by any other name...

What would you call that role, just curious?

Maintainer, gatekeeper,

zenlan's picture

Maintainer, gatekeeper, curator, prefect, manager of the status quo, who would actively seek such a title other than a builder of a walled garden? Someone above mentioned competition and I can't help but think that any kind of award system will be gamed and result in community cul-de-sacs.

I was at the Devs Love Bacon (in London) conf today and a talk by an OS community manager about how he hates the title 'maintainer' crystalised this thought for me. To paraphrase, he said that it was stifling, that he wanted to be a creator, not just a maintainer.

Does drupal.org want to encourage walled gardens and gatekeepers? Karma, kudos, brownie points, gold stars... is there an alternative I wonder?

Never work for any company that has an employee of the month scheme. Seems to me that a 'badge' system isn't far off that. The fact that it will involve voting doesn't make it any fairer, it can be gamed all the same. The badges may 'reward' people for contributions but it can also daunt and intimidate new-comers and dissidents.

I think you are misunderstanding

xjm's picture

The word "maintainer" is used to mean three things in the Drupal community:

  • Maintainers of contributed projects (people who develop these projects, fix bugs, add releases, etc.)
  • MAINTAINERS.txt component maintainers (people responsible for a specific core component and documented in the actual core codebase)
  • Maintainers for Drupal core. The handful of people who review and commit every single line of code that makes its way into core.

There's no gaming this. You are the maintainer of Drupal 7, or you aren't. You are a maintainer for Views, or you aren't.

And anyway this is just one suggested kind of "badge" among many possible, or so I understand.

.

Michelle's picture

Maintainer, gatekeeper, curator, prefect, manager of the status quo

These are not synonyms and aren't as negative as you are making them out to be. A maintainer ensures things don't fall into disrepair. A gatekeeper ensures the safety of what is being gated. A curator picks the best. Prefect doesn't really apply in the Drupal community. Manager of the status quo makes no sense at all in a community that is always moving forward and sounds as though it's meant to be inflammatory.

If you think we are building walled gardens here, you truly do not understand this community.

The goal here is to take a structure that has evolved naturally and somewhat invisibly and bring it to light. We are not imposing structure by adding badges; merely labeling what is already there. By doing this, anyone, no matter how new, can get a feel for who is who in the community.

Those who have been around for many years and have badges that show they are still active portray the community as something worth sticking around for long term. When someone new comes along and digs in and contributes and earns a badge, that sends a skewer right through the myth that there is some inner circle that decides everything and new people have no say.

Of course, we must tread carefully; we don't want the badges to become trophies that become the goal to a game. But I think we can avoid that with planning and the plan here makes a lot of sense.


My blog, mostly about Drupal: Shell Multimedia

?

xjm's picture

Our names are on every web server that runs Drupal. Makes me pretty proud?

I'd prefer to omit 2 entirely

xjm's picture

1 and 3 encourage participation from everyone while they expose our community structure. The "team badges," however, create "insiders" versus "outsiders." They seem to imply that UX is the UX team's problem; good docs are the docs team's problem; etc. I think 1 and 3 will expose a person's strong interests without the need for rubber-stamping.

Perspective of current docs team leader...

jhodgdon's picture

I have a few thoughts on this...

Starting with the original proposal at the top of this page:

Part 1 Voting - For Community Documentation pages on drupal.org, we want each page to be a "wiki", in the sense that it isn't written or owned by one person, but rather maintained by the community. So I don't ever want to see one person be recognized as the author of a page or getting the sole credit for a +1 on a page.

And since we try in general to incorporate/delete docs page comments, I definitely don't want anyone to get any type of positive credit for commenting on a docs page rather than just editing the page. If anything, they should get a -1.

Maybe we could have a way to recognize +1 credit for doc page revisions, but I kind of doubt most people ever look at the revisions tab or the diffs to find out who contributed really good stuff to a page... so I think this is not really viable for docs contributions.

And if this proposal doesn't have a good and viable way to recognize docs contributions, I am against having it. What we really don't need is yet another system that recognizes only some contributions to the community.

Also, how would you recognize and vote on some of the other contributions listed in this proposal, such as "event organizing" anyway? It just doesn't seem feasible. If it is only easy to vote on forum posts (support) and issue comments (developers/reviewers), then that is most of what will be recognized, and the system won't be a fair reflection of contributions to the community.

Part 2 - Official team badges: I'm against this for the Docs team. We want every member of the Drupal community to feel empowered to edit Community Documentation pages (and have worked hard the past few months to reformat the pages so that is more obvious). I don't ever want to be in a position of saying "yes, you are part of the docs team" vs. "no, you haven't done enough yet to be an official team member". Nor do I want there to be two classes of people, those part of the "official" docs team and those not part of it. Big no from me.

Part 3 - Activity badges: I like this idea, assuming they can be automatically assigned via queries from the drupal.org database, the way other things on our user profiles are now (like how many pages you have edited and how many commits you have made).

Builder of Drupal sites and modules, and Drupal tutor - http://poplarware.com
Drupal Core maintainer for documentation

I think many of the

greggles's picture

I think many of the criticisms of part 1 can be mitigated in the implementation and I struggle with how to make sure we're not letting perfect be the enemy of progress. If we can recognize support, design, ux etc. but fail to properly capture docs contributions in the first iteration then I'd be OK with that, tbh. From the perspective of the security team 90% of our work is in sekret so this system is unlikely to ever recognize that. But, like I said, if we can make progress in recognizing more and more contributors that is good.

We could easily make it impossible to +1 comments on docs pages. There could be some special consideration for how +1 works on a docs page to grant credit to all revision authors (though that gets tricky, do they get +1 per revision? per lines of revised content? etc.).

quick comment on point #2 you make...

svettes's picture

I know diddly about documentation leadership, so I'll defer to your expertise on this, but imho just b/c we recognize someone is a leader (such as yourself) it doesn't mean others are not empowered as you've worked so hard to clarify :)

I think there's another perspective besides non-badge-holders being 2nd class citizens (which could apply to every discipline and not just documentation).

I think the badge-ed ones would be viewed as information points or mentors rather than "I'm better than you b/c I have a badge don't touch my stuff!" lol. I'm obviously exaggerating, but you get the point.

I think the badge-ed ones

tvn's picture

I think the badge-ed ones would be viewed as information points or mentors

Yes, that's exactly what was in mind for the team badges. For example, someone random tells you - I think your code isn't secure. I'd more listen to it if I see that the person who said that is security team member. Or if I'm a newcomer with UX expertise, want to somehow contribute but do not know how - I see a person who is UX team member and can ask him how I can help and participate, etc.

Though I can understand concerns about "I am not part of the team so I should not do anything about it". Maybe we should think of just renaming this, from "team member" to something not implying closed circle of people e.g. Docs ninja, Security master, UX someone.

But I don't want to choose them

jhodgdon's picture

The point I was trying to make about team badges is that I have plenty to do without also assuming the resposibility of designating people to receive badges saying they are members of the docs team. I don't accept or want that responsibility. It might make sense for Security, but it doesn't make sense for Documentation.

Builder of Drupal sites and modules, and Drupal tutor - http://poplarware.com
Drupal Core maintainer for documentation

And since we try in general

LP's picture

And since we try in general to incorporate/delete docs page comments, I definitely don't want anyone to get any type of positive credit for commenting on a docs page rather than just editing the page. If anything, they should get a -1.

"Try to" is key here. There are still tons of docs page comments addressing variously more/less germane use-cases and details. While in some silver future these will be integrated, offering visual commentary on comments could be useful from where I stand as a doc page peruser, and seems like it could even be useful for those who act in rolling comments in - as an opportunity to essentially have a sorta RTBC.

That said, doc comments are sometimes rather conversational and this could be a mess.

Part 3, of course, can be

Morbus Iff's picture

Part 3, of course, can be handled with the Achievements module, alongside the Pointless module (which removes all competitive elements of achievements, including points and leaderboards).

Current vs archived

chx's picture

Points and badges should decay and move to archive shown on the user profile only. Show the current points and badges site-wide.

A dropdown besides +1 ? That's just confusing, don't do that.

Edit: can you imagine the core issue queue where, instead of just a nick you have a nick with ten gazillion points and more badges you can count? We really don't want that. We like our newbies. We love our newbies.

Only on the profile anyway?

xjm's picture

I didn't think these would be displayed anywhere other than the user profile and perhaps a hidden tooltip dealy.

Yes, the idea was to show

tvn's picture

Yes, the idea was to show badges/points only on user profiles and maybe short version in some tooltip, for example when hovering over username.

Separate into two buttons

fizk's picture

I like the +1 feature itself and the tagging/categorization feature, but they should be separate buttons beside each other.

Most of the time I will want to simply +1 a comment, but not categorize it. When I do want to use categorization, I'll use the other button. This second button could be named something like "tag".

It's a valid point - what to

tvn's picture

It's a valid point - what to do when nothing from the list of options seems fitting and you just want to +1. I'd love to see more opinions on what to do in this situation. Maybe we could come up with some general tag for that, or maybe indeed separate into 2 buttons.

So, there are a number of

webchick's picture

So, there are a number of things I like about this:

a. show "who is who" in the community, make it easier for the new people, make it easier to make a judgement on the value of a comment
b. recognize non-code contributions which can't be counted by number of commits or other such data
c. show support of comments by other users, this will eliminate the need for "+1 to #21" type of comments - you can just vote instead
d. provide an easy mechanism to say "i agree", "thank you this was useful", "you're doing great job" etc. which will encourage people to contribute

I think all of those are fabulous goals of a badges/reputation system, and I really like the "accentuating the positive" aspect of this. Well done.

If done well, a system like this has the potential to better incentivize critically important things that aren't getting enough attention. So we'll want to think carefully about the axes of the voting tool, both because as you said we can really only have about 5-7 of these before it becomes totally unmanageable, but also because it's a good chance for us to try and encourage activities we see lacking and that are difficult to track in an automated fashion.

For example, I would recommend switching from "Code" to "Detailed code review." Code contributors are not typically something we have a problem attracting. And we already have really good ways of tracking code contributions (git commits and, if nothing else, we can query the comment_upload table for files that end in .patch).

But for code reviews:

1) This work is absolutely essential (at least to Drupal core's workflow) to putting those code changes in front of the masses, so it's critically important to have people performing code reviews.
2) However, code review is seen as difficult, unglamorous work (compared to coding), so we are always totally starved for reviewers.
3) When we do get reviewers, especially new ones, it's often a "+1, looks good" style review instead of something that inspires trust in core developers and maintainers, so it doesn't actually do much good (hence the "Detailed" part of the description ;)).
4) When someone does put in the effort, we have absolutely no reliable means of tracking these credit-wise beyond very careful attention by the maintainer when they're sifting through 200+ replies looking for who deserves commit credit. Most often, one just copy/paste the message from Dreditor which only credits the initial poster and people who uploaded patches. :\
5) Tracking code reviewers also helps lend transparency to how the Drupal core queue governance works; for example, I'll trust reviews coming from an xjm, catch, or sun a lot more than I do a random newcomer review, just based on experience. It does take a few issues to build up that level of trust, so tracking that with "XP" seems appropriate.

My concerns are along the lines of Jennifer and some others regarding #2. One thing we absolutely do NOT want to do is disempower the do-ocracy with this model, with people thinking they have to be "on the team" in order to help out. Docs has this problem, and Core definitely has this problem as well, and that's without "team" badges. :\

One possible thought on the community transparency angle is to add a 255 max character "Drupal Role" field instead of using a badges system, where each user could attempt to identify themselves to others in the community. So I could put "Drupal community cat herder, D7 core co-maintainer", xjm could put "Issue queue triage ninja, Coordinator of Core Mentoring Hours, Taxonomy system co-maintainer", etc. Someone else might use it to say "Chief Community Curmudgeon." While on the surface that might seem like a reason not to do this, on the other hand transparency around "This person is generally pretty cranky" is actually a really useful thing to communicate! :)

Summary field

sun's picture

One possible thought on the community transparency angle is to add a 255 max character "Drupal Role" field

This reminds of summary fields as implemented e.g. on Twitter, G+ profiles, and about.me. Could be shown next to a user name in a comment. And that, in turn, reminds of existing user signatures ;) (though less and without formatting)

Daniel F. Kudwien
unleashed mind

Good & bad

svettes's picture

It does seem that a lot of people are uncomfortable w the idea of votes or badges determining who is who, so I like the suggestion of a field where peeps can self-identify.

However, 255 char is pretty long, where do you want to display it? I likes XJM's idea of hidden tooltip, perhaps that's too long especially is we're including voting range info. If on the user profile I think Sun's right...

IMHO Angie, your point #4 is reason enough to implement voting. I'm getting the warm & fuzzies thinking about being able to say thanks like this and how much moral boosting the community will get bc of it!

Levels of badges

Michelle's picture

I'm not sure this would work... It may lean too heavily towards the game end... But I wanted to put it out there for thoughts.

We want badges to indicate who has more "authority" (in the knowledge sense, not the control sense) in an area but want to avoid an "us vs them". So how about leveled badges?

Something like:

Bronze level docs contributor
Silver level docs contributor
Gold level docs contributor
(Platinum, etc, if more are needed)
Inactive docs contributor

Rather than being on the "docs team" you get a badge based on some metric (yes, a bit of handwaving over the hard part :P ). Make Bronze fairly easy to get to reward people who just start helping out and then each level is progressively harder.

By looking at the combination of level and category, you can tell at a glance what area of focus the person has and how much effort they have put into it.

By labeling it as "contributor" rather than "team" the focus is on what they are doing rather than what group they are part of.

I included the "inactive" as a way to show that the person has moved on without completely ripping the badge away. Perhaps the system could retain their previous level in the background so it can be re-instated by some easier way than starting at the bottom again.

Thoughts?


My blog, mostly about Drupal: Shell Multimedia

Fine if automatic...

jhodgdon's picture

That is OK if the badges can be generated automatically via database queries. It is even worse than the original proposal if it means that I have to decide who gets what level...

But ... I am uncomfortable with this concept actually. I would like everyone to feel like their (small or large) contribution to editing/maintaining documentation is valued. Saying one person is just "bronze" vs. another who is "silver" is ... not great. If it comes to that, I would just leave what we have in place now (on your user profile, it says how may docs edits you have, in round numbers) and leave it at that.

Builder of Drupal sites and modules, and Drupal tutor - http://poplarware.com
Drupal Core maintainer for documentation

.

Michelle's picture

The badges don't mean your contributions are more valued. It's just a way to let people know who's who and who does what without having to have been here long enough to know everyone.

Alternately, I suppose we could all have signatures like yours, which is essentially a self-applied badge. :)


My blog, mostly about Drupal: Shell Multimedia

Bmuzammil's picture

hi, I posted a similar idea too but that is implemented already on Concrete5 CMS.

List of badges :
http://concrete5-cms.blogspot.com/

http://drupal-association.ideascale.com/a/dtd/Badges-to-be-displayed-on-...

Some thoughts about contributor feedback

Itangalo's picture

I got linked to this issue from http://groups.drupal.org/node/231978, where I propose that documentation contributors should be able to get feedback about their work.

I think just having a way to see how much contributions are being used is a first and possibly most important part of contributions – be it in terms of documentation or else.

I'm generally hesitant about systems for reputation/badges. It has great encouraging powers, but it also risks increasing the distance between newbies and experienced users (which, arguably, could make newbies feel less welcome).

Anyways. I just wanted to link to a related discussion and chip in my 2p of thoughts.

How do we jumpstart this issue?

mgifford's picture

What needs to happen to jump start this issue again? There was 2 months of discussion and then.....

I do think this is something important enough for the community that it should be supported by the Drupal Association. Who can do that?

There's some work already up here (using Drupal):
http://www.linuxfloat.org/badges

Although it isn't really a question/answer system, So ArrayShift and Answers probably won't help:
http://drupal.org/node/1049212#comment-6239774

I plan to start working on

tvn's picture

I plan to start working on this initiative again in the next week or 2 and actively work through August and September.

Gamification & Drupal

mgifford's picture

I just created this GDO group - http://groups.drupal.org/gamification

Now that Drupal.org has been upgraded, it's time to start thinking again about how to add these components into the site.

It might be a good place to discuss the merits of the 3 approaches to implementing badges that seem to already be there on d.o.

Drupal.org Improvements

Group categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week