Exposing some structure of the community and involvement of members (badges?)

I like it. We are implementing something similar at Kiva. The problem is the conversation quickly devolves into bikeshedding over what the badges should be and what they should like (e.g., is it a trophy, a stylized druplicon icon (a la github octocat), just some text marker sort of like what exists on profile pages now?)

It'd probably be good to make this issue only a question of whether or not to implement karma or badges, and then have the implementation details go into another issue, to avoid people going back and forth on implementation details before even deciding if this should happen at all.

I personally think that karma/userpoints would be toxic to a community like ours.

However, I think a well-thought out usage of http://drupal.org/project/achievements would be a great thing for d.o.

May I rename this? If not, you can change it back. I *think* the key issue is how we can expose both the nature of our contributors (and thus, in a do-ocracy, the structure of the community). I'm in favor of that basic thing, and I have no problem with badges, although we seem to get stuck on the conversation.

I think there's broad-ish support for deliberately exposing the structure of the community by showing what people have worked on. We already have a little of this one-hop away (too far away) on the user profile page. But it could easily

This is actually an issue that we have already deadlocked on :-) So perhaps we need a conflict resolution process. I'm not sure this has ever been formally stated though. Perhaps the people in this very issue can reach a consensus and then this could turn into a broader issue including a d.o dev initiative.

+1 in favor of badges. If we went with http://drupal.org/project/achievements the first step would be to backport that module to d7 no?

We already have badges on d.o. though in a very minor way, via Drupal Association: http://drupal.org/image/tid/109

@rfay Do you want to file an issue for conflict resolution process, as sounds like, based upon your past experience, that developing that could be a pre-requisite to solving issues like this.

The problem is that the fact that you have contributed to Drupal in the past does not mean you are any more correct in the current conflict than the new guy who is new to Drupal but has relevant experience from other sources.

Currently you can get a pretty good feel for what people have done by looking at their use page. There are several things the user can add to their profile to indicate what they have done as well as a summary of git commits.

Basically I don't feel that adding this stuff in a way that has serious meaning to it makes sense when it comes to the issues we want to resolve by some better governance. It is probably cool and might make it easier for new people to figure out who the key players are, but until then just go to http://certifiedtorock.com/u/2 and enjoy :)

Skill set chart could be helpful: http://groups.drupal.org/node/172434/

Note that project management skills (including requirement analysis and project roadmap creation) are listed as 'non-Drupal skills.' :-)

Global-level badges are bad for the same reason that the project promotion system is broken: It sends the message that you're not all that welcome unless you've already been here a while.

Within a project scope, however, it could be meaningful to have some kind of badge for the project maintainers and co-maintainers. A commit stat might also be helpful. Maybe a tiny bar graph or something. This might be informative rather than intimidating. All this information is on the project front page, but might be a useful reminder within the discussion thread as well.

Here's a subtle but important distinction: Do we want to expose the structure of a do-ocracy, or of a meritocracy? Those are not necessarily the same thing. They're related, but not the same. And which one we try to recognize will have an impact on our culture, too.

@Crell Though I had jokingly used do-acracy this week a couple times while herding cats, I didn't really know the distinction. So for others who are in my boat, here's what I found, hopefully this adheres to the way you are defining things.

From http://prokoudine.info/blog/2010/07/doacracy/:

How can one possibly crawl out of this deadlock? There is a fairly honest way of dealing with this. It’s what we in Inkscape project call doacracy (the term wasn’t invented there, but that’s where I’ve grown to love and abuse it). What is means is: the more you do in the project, the more solid your vote is. I know I can bitch is some mailing lists and/or IRC channels, because I’ve been contributing stuff for years. And I know I can’t do that in others, because I haven’t done anything serious there, so I better keep my mouth shut (by means of a muzzle sometimes).

Closer to home, from g.d.o.: http://groups.drupal.org/node/146379

Do-acracy. I make a point of not trying to intrude my opinion on issues that I am not prepared to do the work for. I think it's a good idea. The people who are out there doing the work, presumably aren't ill intentioned, and aren't stupid. Sure, they probably won't print out the same signage for the event, and maybe I think white t-shirts are a horrible idea - but you know what? I'm not ordering the t-shirts or printing the signs so that decision isn't mine to make. This isn't to say that if you feel very strongly about something that you should say nothing. Just make sure that what you have a strong opinion about is A) relevant to the community itself, and B) really that important.

A real life example of this is the great t-shirt debate. We've had the discussion about 4 times when we think about getting t-shirts made about whether they should be American Apparel, or cheap available t-shirts. It's contentious, people have strong feelings about these issues. But here's the thing - it is a little irrelevant to the group. Those t-shirts are not code. Thus imo, this decision should be in the hands of the person ordering the t-shirts. That isn't because I don't care about sweatshop labor - that is because it isn't worth straining the good intentions of an organizer by intruding something that isn't relevant to the community.

Compare that to defining meritocracy:

From wikipedia: http://en.wikipedia.org/wiki/Meritocracy

Meritocracy, in the first, most administrative sense, is a system of government or other administration (such as business administration) wherein appointments and responsibilities are objectively assigned to individuals based upon their "merits", namely intelligence, credentials, and education,[1] determined through evaluations or examinations. The "most common definition of meritocracy conceptualizes merit in terms of tested competency and ability, and most likely as measured by IQ or standardized achievement tests."[2]

Here's a blog from a Drupaler comparing the two (with a very subjective opinion though:http://asymptomatic.net/2009/03/21/2795/meritocracy-versus-do-ocracy

Hopefully, that is helpful to people like me who were not yet sure of the difference.

While I support some sort of karma/badges system for drupal.org, I am not sure it is a good thing to make it a basis of governance process in the community. Unless we want to go stackexchange way with overly defined structure and rules e.g. "you need to have n of this badges to be able to do X, until you have them you can only do Y" etc.

In my opinion karma/badges system should be discussed as a means of: recognizing contributions and encouraging people to participate more, make it easier to see who is who in the community etc.

We've been actually talking about such kind of system for quite some time over at Prairie initiative.

The overview is here: http://groups.drupal.org/node/144594
It contains links to previous discussions in that group and various discussions on similar topic around d.o.
We also took a look at how others implement such systems: http://groups.drupal.org/node/209063

The current proposal, which is in work already, is here: http://groups.drupal.org/node/209448
Everyone is welcome to comment.

I want to underline that we call it reputation system (sometimes expertise/reputation system) just for the sake of simplicity, but we do not want the system to encourage competition, leaderboards and that sort of thing, what it really is - is a system to expose and recognize different types of contributions and expertise of community members.

The proposal for such system also ranks quite high at ideascale: http://drupal-association.ideascale.com/a/dtd/Add-a-reputation-badges-sy...

Also for interested in this topic, there is a book "Building Web Reputation Systems" by Randy Farmer (web version is available here http://buildingreputation.com/doku.php) which looks in detail into various types of karma/badges systems and types of communities that use them.

Sorry for the links spam, just wanted to provide an overview of where similar discussions happen.

I like the idea of badges if they are done carefully and clearly shown to be for identifying purposes rather than trophies. I've heard many times people say that we are all equal and so they don't want anything like this but, really, some are more equal than others around here. It's true that anyone can become one of the "inner circle" by putting in some time and doing but pretending that the opinion of a core maintainer isn't weighed any higher than Joe Newbie that joined yesterday is just hiding the underlying structure. I think it's important that we publicly recognize that, yes, there is a hierarchy of sorts here but that it is not a closed hierarchy and anyone who wants to become Someone Who Is Listened To just needs to pitch in and join us. We are not a clique that won't let new people in but we are a group that has been together a while and those on the "inside" know who is who and who knows what and who to listen to about what and new people just don't have that knowledge.

To Michelle's point, there is a concept of "more equal" on d.o., and it can be useful.

Take the issue about improving support options on drupal.org #1236290: Decide on a course of action for improving support options on Drupal.org

Angie repeatedly asked for those who have provided support on the drupal.org forums to weigh in. A badge system here for users who had replied to a certain number of posts could be deemed "forum contributors" and given a badge for it, Michelle for example probably would have this badge, along with WorldFallz, etc., and then when it came time to get those people to weigh in we'd easily be able to find them by badge.

Obviously, there is no way this could ever be perfect, but we at Kiva debated it much like the d.o. community is debating it, and despite vehement opposition from some people, we've decided to implement them, not as trophies, but as identifiers of a sort. For me this is useful. And on places like StackOverflow, though they are more trophy like in nature, they encourage me to continue contributing back to the community.

#14 is also a great example of why badges need to be revisited over time. I used to be very active in the forums but I'm not anymore. I still go there and answer things now and then especially if they are related to forums (not drupal.org forums; forums on peoples' sites) but I would not consider myself a top contributer to the forums anymore. While I know enough of what's going on there to have input in handling support on d.o, I don't think I deserve any sort of badge for what I've done recently.

I understand exactly what you're saying, because my areas of contribution have declined, but I'm still fairly well known and recognized. Far more, of course, than when I was contributing more.

On the other hand, it *does* help quite a lot to know that Michelle knows what's going on in the forums and that she knows what's going on in general. It does help to know that rfay has done core work and works on infra stuff.

If badges are a way of helping others to find their way around the community, rather than a way to express praise, then we're OK even when the actual info gets stale.

And I think this distinction is really important:

What we (should be) trying to do is to expose the structure of our community so that people can navigate it, not to motivate people based on badge "rewards".

I was thinking about this last night and a possible idea would be to have "faded badges". That is, once you earn a badge you keep it forever but the requirements are reviewed every so often and people who don't meet them currently have the badge "faded". So maybe black and white instead of color or something.

For this example, it would show that I was once quite active in the forums, enough to have that noted, but that I don't currently meet the requirements for the badge.

I agree that we shouldn't make them rewards. It's tricky to make them useful without it being a game, though. My thinking is that it would help if they are limited to just enough to provide useful information. If you maintain one project, you get a marker (I'm trying to get away from calling them badges but not sure what word to use) that you are a project maintainer but just one. If you add more modules, you don't get more markers (Dave wouldn't have room for his posts on the page with all of them otherwise... ;) ). Same with anything else. I definitely don't want to have a system where x posts gets you a bronze badge, y posts gets you silver, etc. Just make it a simple binary thing. You either are being marked for this certain thing or you aren't and there's no ongoing goal seeking involved.

I also think we should limit the number of things being recognized to only those that are really useful to the user looking at them. That is the intended focus here. These aren't "rewards"; they are information to people who are new to the community and can't just look at someone's name and know what they do around here. They are basically a summary of the person's contributions that a person wondering who they are can access quickly, perhaps by hovering over their user name.

@ tim.plunkett I was thinking the same thing - I've been working with Morbus a bit on this project through Examiner.com - and we've got a working implementation of the program. I can't share lots of details yet as we've not made our application live - but the use of badging could be very helpful based on the kind of aid in governance a given user has engaged in.

@Kjartan Certified to Rock completely ignores the contributions of non-coders/themers. I, for example, have been extremely involved in the community for over 5 years. My contributions are different:

• Organizing Camps
• Presenting at Camps
• Presenting at Meetups
• Organizing committee for a Con
• Evangelizing
• Documentation

The tool is flawed and skewed to an old way of thinking.

@MatthewS, I may be wrong but I think Kjartan's point is that CTR isn't a good solution. He's been absent from Drupal for a couple years, and still has an epically (and well deserved) high score that is somewhat outdated.

@tim.plunkett - Ah, I totally missed that point 100%. I thought he was saying that adding details to one's profile and looking at git commits, while not that useful, are the best thing that we have at this point. Until something better emerges, CTR is the best thing that we have to figure out who key players are. My bad.

What I am interested in is having some way of recognizing the people in "power" players when relavant. For me this means that when in a specific issue queue the project maintainers for that project are identified in some form. Or on the forums those who have moderation permissions are marked as site mainainers or moderators. In documentation pages those who are on the docteam get identified as such. For core I would add some way to have the component maintainers (MAINTAINERS.txt) and intiative leads be identified on core issue. I am somewhat conflicted with finding a method to flag people who aren't in specific positions but who have contributed greatly in recent time as we then enter into definitions of what constitutes contributions and valuing those.

Anything that goes towards an achievement model based on "posted X posts on the forum" and similar criteria I believe goes counter to how the Drupal community was developed. Some of this stuff is already on the user page, and can stay there and maybe be expanded, but I dont feel like it should be displayed more prominantly.

I agree the biggest challenge with any achievement model is that - without modification - it is completely task based. Do this action 3 times get a badge kind of thing. However, the Achievements module can take any number of criteria. It *might* make sense for us to think about adding to the inputs something on the lines of "was this post valuable" and use those elements in determining assessment of an achievement. Then something like a leaderboard can take into account recency. So you would have, essentially, a metric you could look at for overall participation (at least on D.O.) and on whether they are recent in that participation.

I see a big flaw to this approach having just come off the Drupalcon Local Organizing Committee - I put in hundreds of hours of time, but it was entirely in google docs, IRC, Skype, ZenDesk, and the Association Open Atrium site. None of that would ever surface on D.O. - we're limited to where we put our tracking. Again, contributions can be so much more difficult to assess than specific actions, get a badge.

A "was this valuable" marker on content (not people!) is useful in its own right whether we leverage it toward structure-exposition or not. That said, Kjartan makes a good point that there's both contextual "clout" and non-contextual clout. "Posts a lot in issues" is relevant differently than "posts a lot on THIS project". Eg, in the core issue queue, I legitimately carry a fair bit of weight. (Maintainers.txt and initiative lead.) In the Views issue queue, the Views Bug Squad members should be listened to before I am in most cases. In the forums, I practically don't exist. :-)

Perhaps we should put together a possible list of "cloutable things" and the context in which they would be relevant?

If you have clout in a project you should be a co-maintainer or part of the 'team,' as assembled by the project owner. Basically I'm saying the project owner (or maintainer, or whoever they delegated) would be the one who hands out the badges, and thus greater clout/juice/legitimacy per project.

The delicate moment comes when it's time to withdraw the badge. This is the real problem with badge-based stuff anyway, if someone can take it away from you. Often there can be hard feelings and everything gets stratified pretty quickly. Ideally people could resign their badge, and maybe be prompted to do so automatically if they haven't said anything in six months or whatever.

We've had this discussion at length at Examiner. We came to the conclusion that there are differences between badges (which once earned should always be kept) and something more like credentialing which requires upkeep to maintain. In the professional world, it is common to have to maintain a certain number of educational credits or you may need to retest. I think it is important to separate the two and make it really clear the difference to the community. One recognizes lifetime achievements and the other is a reflection of current activity.

+1 to @rfay's #3, the basic idea of exposing actions, achievements of individuals and structure of the community. I think the majority of us can agree on that.

The specifics on implementation will not be resolved in the usual issue queue format and will go back and forth forever here if we don't just move forward with something. I would suggest that we start with a basic system of badges, iterate, and pivot if needed.

Reading through the discussion, I identify four uses of badges/formalized karma:

1. Encouraging participation by giving public regocnition. ("People will see what I've done.")
2. Encouraging participation by triggering gaming instincts. ("Gotta have that badge!")
3. Being able to identify who to talk to on certain matters. ("Who's done a lot of work in this group?")
4. Encouraging and directing participation by providing feedback. ("Do people find my posts useful?")

I think most people would agree that (1) has potential toxic effects, and (2) risks shifting attention to achievements rather than people – which would make us dependent on a solid reward system.

I can't see any toxic effects of (3) and (4), though, which I think makes them a good place to start. I think it would be awesome if you could get information like:

* The +/- status of my posts, individual or in total.
* Lists of total +/- status for users on d.o, as well as individual posts.
* Page view statistics of (say) documentation pages or issue posts – your own as well as all of them.

Implementing better feedback to contributors would probably fulfil the (3) and (4) purposes of formalized karma. It would also, I think, go a long way in triggering gaming instincts (2) – while still avoiding the possible negative effects of it.

For those interested in working on this there's an updated post at http://groups.drupal.org/node/225824

I thought I'd just chime in with a link to Mozilla's Open Badges project https://wiki.mozilla.org/Badges

I do think this is a great idea. This type of recognition seems to work for StackOverflow too.

This came up again because we were looking at critical tools like Drush that have critical issues that are unfixed after 38 weeks. That's a long time for a critical issue. How do we change the dynamics in the community to ensure that more people are increasing their level of participation & those who are already doing lots are properly acknowledged?

Found this TED talk related - http://www.ted.com/talks/lang/en/jane_mcgonigal_gaming_can_make_a_better...

Wondering if anyone has any insight as how - http://drupal.stackexchange.com works as far as the badges that our members are already getting in that community. Is there any way we can piggyback off of that system?

Drupal 7 has been pretty stable over the last year and a half, but it's surprising how many important contrib modules still aren't.

EDIT: Also noting that this title is pretty verbose and doesn't encourage participation or action. Someone should think of a better more galvanizing title.

I think the drush critical issue is the same as nearly everything that's not seeing the action you want: patches welcome.

Updating title to make it somewhat more accurate.

Yes, but we are contributing patches already. The drush one is just an example that we were struggling with today.

There are lots of reasons why issues get stuck and why bugs tend to linger longer than they should. For a small shop we're already contributing quite a lot back.

It's a piece of the culture change that the http://groups.drupal.org/prairie-initiative is hoping to foster.

Yes, developers need to develop patches and submit them. Then someone else needs to review those patches & bring them into the repo. Finally, someone needs to put out a new release with the fixes included.

However, there are lots of people who aren't developers or who haven't budgeted for fixing a module so that it does what it says it is supposed to do on the description page. It's rare for us to develop a site without needing to bring in some new module that we've never used, especially in Drupal 7.

How do we make it easy for folks to give in different ways. It should be easy for a user to contribute to an upgrade or bugfix. We can't assume that developers who launch modules will always have the time that's needed to maintain them.

This issue is a good way to highlight the work folks have done and find a way to motivate others to do more. Drupal's too big to simply reply with "patches welcome". There have to be other forms of contribution and the ecosystem needs to be modified to make sure that Drupal is more sustainable.

Drupal's too big to simply reply with "patches welcome".

This might be true. I've always thought that inforal award systems are better than the explicit ones, but maybe that's not true for Drupal any more.

However, there are lots of people who aren't developers or who haven't budgeted for fixing a module so that it does what it says it is supposed to do on the description page. It's rare for us to develop a site without needing to bring in some new module that we've never used, especially in Drupal 7.

Not to be an ass, but it's definitely not the responsibility of the people who gave untold hours of their own work away for free that someone else lost money due to not putting enough padding in their client estimates. I would like to divorce the concept of providing recognition for a job well done from the idea that we should be putting more pressure on module developers to spend more of their free time so others can make money off it. Let's keep this discussion focused on the former.

http://groups.drupal.org/paying-plumbing is a better venue for discussing a sustainable way of doing module maintenance that doesn't ask even more of already swamped volunteers.

@Itangalo - I think it's fair to say that the informal award system works well enough for those who are already contributing a lot. However, there are a lot of people who don't know how to begin contributing. More importantly, patches are only a small way that people can contribute. It's got a relatively high bar for entry for most people on Drupal.org. Would be very interesting to see stats on what % of folks on d.o ever submit a patch, let alone one that works with git.

I don't know what the proper mix is, but we should have goals for participation & have means to monitor the group behavior to see if our community is behaving as we want it to. If badges don't work, we want to know that early.

@webchick - Thanks for the Paying for the Plumbing link. There are definitely some good conversations there. I actually want to try to put less pressure on module/theme developers and find ways to distribute it more broadly within the community. Putting more pressure on the maintainers is just going to increase burnout (and that's something we really can't afford).

It's really about trying to find a balance. I think that OpenConcept is a pretty responsible Drupal shop (mind you we haven't really got our /drupalgive initiative page up to demonstrate that). But with small clients (which many of ours are), there just isn't room to add the amount of padding needed. Ideally all Drupal shops would be able to just bill hourly for their time for as much time as it takes to get the job done right, sadly there just aren't enough clients willing to enter into an agreement like that. We all need to do what we can to reduce uncertainty in using this code base.

There's a big gap between "Providing recognition for a job well done" and providing micro incentives to train users to adopt the type of user behavior we want to be the norm. There are so many critical ways that maybe 500 people are already contributing to this community. They are probably going to keep doing so even if they don't get a gold star.

Hope this helps clarify my initial post.

Moving to the new Drupal Community Working Group issue queue.

I added an issue about this in the Drupal.org Customizations project. I do think it could be quite useful. I do wish that Mozilla were making better use of it and giving us access to their metrics.

Adding a link to Expertise/Reputation system: initial draft from GDO - https://groups.drupal.org/node/209448

Lots of this has been done before in GDO, but just never moved over to the issue queue to actually get implemented it seems.

I think...

giving orgs credit
https://www.drupal.org/news/supporting-organizations-credit-on-profiles

and the ongoing profile improvements
https://www.drupal.org/project/issues/search?issue_tags=d.o%20profile%20...

means the spirit of this issue is in hand, and not really a DCWG issue.

Any objections to closing this one out now?

Although there are some good changes being done for the profiles & organizations, I think that the spirit of this issue is bigger. Certainly there are great efforts to make the structure of the community more transparent.

I do think that more developers are likely to refer to their profile page, when it highlights their contributions. That will definitely be good.

Badge systems are really a mechanism to encourage folks to participate and learn more. Much of this thread (including the initial issue) are about that type of formal reputation system. That isn't something that is being worked on elsewhere.

Well, the issue title mentions badges as a possibility. If you feel that badges are the only solution as the way to achieve this then the title/summary should explicitly say that.

I think the title changed over time to recognize the idea that badges are one way to achieve an idea.

If this issue is *just* about badges then I am -1 on it (unless the specific implementation of the badges has some specific implementation details that really respect our community's values).

I think what we would need to move forward on the proposal in the issue summary of this issue is:

1) A spec of what it is we wish to implement (doesn't have to be crazy, but describes the changes/functionality to the point it could be understood/swagged by developers)
2) Agreement on that spec by at least a few people who didn't work on it
3) An outline of the community benefits we would achieve by implementing said solution

(This would probably be better done in the https://www.drupal.org/project/issues/drupalorg issue queue so the people who maintain D.o could see it.)

After that, this could be proposed to the CWG and we could sign off, and make a recommendation to the DSWG that this become a prioritized feature for Drupal.org if that seems to be the right thing to do.

Until then, though, I'm with Donna. I feel like the DA is already doing good work (expanded user roles, profile redesign, volunteer/org credits, "new" on new user profiles, etc.) in making our community structure more explicit, and don't see a need for the CWG to really intervene here.