Marketing

Charles-H. Schulz wrote:

Define the kind of badges we could have for contributors on specific instances, design them and define their awarding policy.

What's our overall plan for gamification here? Are we thinking about using something like http://openbadges.org/ or perhaps rolling our own? Having some kind of tool for keeping track of contributors like CiviCRM would be nice. I don't know anything about Zurmo (http://zurmo.org), but they seem to have gamification built right in, so we should at least take a look at them for tips and ideas.

I have mixed feelings about doing something too complex, because it ends up requiring more backends to run and more energy to invest.
My initial idea was to go with Mozilla's OpenBadges, but anything involving more is going to be confusing to a lot of people. We are targeting volunteers who already find the concept of Red Mine difficult.

So let's take this step by step; investigate OpenBadges on a technical point of view, if it involves too many resources let's just have simple badges tied to each contributor but with no metadata management behind it.

What do you think?

Eeek! We already have so many sites to maintain and so few people to help do the maintenance. I agree that we should keep to easy management of badges; OpenBadges does seem cool and fun and management is quite easy. I would favour the use of OpenBadges.

Let's investigate the OpenBadges then. I am going to test the OpenBadges right on the Mozilla site but we will have to install something our server I think Robinson, would you like to take care of that?

Sources:
https://github.com/mozilla/openbadges-badgekit/wiki/BadgeKit-Tutorial
https://github.com/mozilla/openbadges

thanks!

Charles-H. Schulz wrote:

I have mixed feelings about doing something too complex, because it ends up requiring more backends to run and more energy to invest.
My initial idea was to go with Mozilla's OpenBadges, but anything involving more is going to be confusing to a lot of people. We are targeting volunteers who already find the concept of Red Mine difficult.

So let's take this step by step; investigate OpenBadges on a technical point of view, if it involves too many resources let's just have simple badges tied to each contributor but with no metadata management behind it.

What do you think?

My concern is how to qualify for a badge "quota". If a question is asked and it takes several members' replies to get to the "meat" of the issue and get a good fix or resolution, who gets the "quota number" towards a badge?

Also, there are people who are able to spend a lot of time online "helping out" while others [like me] who cannot be online much time each day. The badge idea might be good, but sometimes it makes newer users who want to help decide that they could never "compete" with "major badge holders" and maybe think their ideas to fix an issue would not be excepted as readily as it would be from one of these members with "high ranking" badges.

When I first started on the lists, I felt like my support ideas could not "compete" with the others on the list. On some projects I once were on that had a badge ranking system, the higher ranking badge holders seem to "look down their noses" at the lower ranked project supporter. One such project system[distributed computing] basically had the idea if you did not have dozens of computers with 4, 6, 8, or 16 cores - in very, very, powerful and expensive systems - you were a slacker and not worth "their time" allowing you to help their project. Competition for badges can work well for some projects, but it can turn some people off. After I "burned out" two systems in the distributed computing project and was told almost directly that my help was not needed if I did not buy much more powerful systems with expensive system specs. I no longer support that project.

So I really has a bad experience with badge systems. We need to make sure our "new helpers" do not feel unwanted or un-cared for.

Also, will there be some indicators, or different badges, for the support of the different modules of LibreOffice? These people support Writer, these support Calc, or Impress, and these people support Base? Sometimes people specialize in helping Writer and not so much in helping Calc or Impress.

Well, that are some of my thoughts and/or concerns.

Charles-H. Schulz wrote:

• Design
  • they should look nice

;-)

• available as png
• the object of the award should be visible
• who's doing them?

Starting page (July 2013):
https://wiki.documentfoundation.org/Design/Whiteboards/Badges

Charles-H. Schulz wrote:

Let's investigate the OpenBadges then. I am going to test the OpenBadges right on the Mozilla site but we will have to install something our server I think Robinson, would you like to take care of that?

Sources:
https://github.com/mozilla/openbadges-badgekit/wiki/BadgeKit-Tutorial

I investigated the option to "use the BadgeKit app...[with a] hosted private beta account at BadgeKit.org," but ran into some errors when I logged-in to https://badgekit.org.

I'll ping someone at the site and see if they can help us get a basic hosted test up and running. I think that's the best way for us to evaluate the software, and decide if we'd like to go further, run a copy locally, etc.

Robinson Tryon wrote:

I'll ping someone at the site and see if they can help us get a basic hosted test up and running.

Update from them: They're "experiencing some issues with the BadgeKit site and are working on fixing it."

In the meantime, they're interested to "hear more about how you're thinking about integrating open badges into your community" so they can help send us some additional resources.

Any thoughts on how we might integrate the badges into our existing infra?

I have a major concern about applying only metrics based on "karma", such as the number of posts. Quantity does not necessarily mean quality.
Automating the attribution of badges based only on that would be a mistake and would also only cover a minority of the population that is eligible to badges.

• posts
• bugs reported
• tasks/issues reported and or closed on RedMine
• active wiki contributions (treshold TBD)
• extension developer
• dictionnary / string translator (insofar as the contributor is not eligible for TDF membership)
  *...

• conference volunteers and organizers (setting up the booth, holding the booth, etc.)
• binaries packagers
• active advocates (people who help start major migrations for instance)
  *....

I see how the first, measurable set of contributions (the ones that are measurable) is integrable in a badge system. I don't see how that works with the latter set of contributions. It could mean we would need to attribute badges on a case by case basis, which also means we would only have an internal workflow (?) not relying on any badges system.

Last but not least let us not forget who we are targeting here. Badges are meant to be an encouragement to volunteers who may not qualify for the TDF membership. The problem is that the membership itself is not overly known (most people think you have to be a developer to be a member) but it is of course not true. So we need to avoid obfuscating the membership with these badges.

These badges should thus have a limited timespan and have a low (yet real) set of criteria to be granted.

In summary we must check:
1) how we grant these badges too all the categories we want to cover
2) the criteria that trigger the badges grant
3) the badges lifecycle and how they can drive someone to request membership (out of the basges system).

Restarting this: The Membership Committee probably needs such a badge system.
Based on this code (API + web app, administered on our infrastructure), what would be the timeframe to set this up?
The thread here has quite a lot of elements on the criteria to get the badges and we should connect with the design team for the rest. Now the technical part is important to assess.

Thoughts? Feedback? Here's the code repo: https://github.com/mozilla/openbadges-badgekit

thanks!

All this discussion sounds very formal. I have been thinking about what would be useful as a way of demonstrating recognition without creating a large bureaucracy. Wikipedia introduced the idea of "barnstars" (see https://en.wikipedia.org/wiki/Wikipedia:Barnstars) - a badge that any editor could award to any other editor as a way of thanking them for a contribution. The Barnstar is posted to the editor's personal account wiki page. These are 100% informal and have no governance status, but do allow others to see that a past action was worthy of recognition and to see what it was, who was grateful and when it happened. They create a mechanism for expressing gratefulness in a low-key way.

Since TDF also has a wiki, it's reasonable to expect every active participant to have an account there -- mine is at https://wiki.documentfoundation.org/User:Webmink -- and we could adopt the Barnstar approach almost trivially.

When I was a member of the MC, one of the issues we had was getting a clear idea of the contributions of people outside the personal knowledge of the MC members. If TDF community participants were encouraged to recognise the work of others with Barnstars, the MC would then be able take them into consideration when awarding or renewing membership.

Thus, my suggestion: TDF should adapt and adopt Wikipedia's Barnstars as a way to build community, with the side effect of creating a casual reputation system.

I very much like the proposal from Simon. I find it simple to use and admin, and almost anyone in our community is able to have a wiki account. I like the fact also that anybody is able to reward somebody else contribution.

As this project seems too big to get off as is (1 year w/o much activity), I extracted the core of this into #1868. Maybe we can get that to fly -- with a better focused scope.