Proposal: badges and achievements for volunteer contributions

Motivation

The heading says it all: (volunteer) motivation. The general idea is to have BOINC support the notion of "badges" that represent various achievements and can be assigned to a volunteer's profile. Those badges should motivate the volunteers to keep contributing as they, apart from (un-sexy) credits alone, can show off their individual contributions in a more tangible and meaningful way. The basic idea isn't new. Various gaming platforms like Steam and BOINC projects like World Community Grid already support the assignment of achievement badges which are then displayed in the community section, e.g. as part of the forum post author details. We, the Einstein@Home and Joachim Fritzsch, propose to standardize and extend this feature to make it available to all interested BOINC projects and beyond.

Note

*The following represents a proposal, a basis for discussion. Consider it work in progress! *

Requirements

The following list is a first shot at the requirements we have in mind (subject to change and refinement):

Origin: badges should be assignable by projects and, eventually, in a cross-project way.
Numbers: the numbers of assigned badges shouldn't be constrained. There could be tens of badges per volunteer, so prepare to visualise those.
Assignment: assignments should support temporary (incl. renewal) and permanent badges.
Visibility: badges should be visible across the whole BOINC universe, at least in managers (desktop/mobile) and the web front-end (forums/profile), eventually even on the stats sites.
Types: badges should be represented by icons/images, supported by textual descriptions. There should also be the means to represent different levels of the same badge type (e.g. a "Continued Support" badge in "Bronze", "Silver" or "Gold")
Assignees: badges should be assignable to users as well as teams.
Very far future: support trading of badges (for other badges or credit) :-)

Implementation notes

Badge "format"
- Image
  - Bitmaps or vector graphics?
  - For bitmaps: pre-defined set of resolutions?
  - Which formats to support (GUI toolkit and browser compatibility)?
- Descriptive text
  - Title
  - Level
  - Description
  - Eventually multi-language
- Origin (name of project, cross-project)
- Time of awarding (e.g. for sorting)
Display
- Forums
  - Avoid clutter: limit number of badges displayed and link to full list
  - Make entire badge display optional via community preference (like currently e.g. for avatars)
- Support badges display in "user of the month"
- Show descriptive text when hovering over badge (mouse/tool-tip), full glory as part of badge list in profile
- Teams
  - Show team badges also in profiles of team members (somewhat separately?)
  - Should member badges be accumulated on team page as well?
- Search (web)
  - Support user profile searches filtered by badges
  - Support team searches filtered by badges
- Support user/team "top" rankings based on badges
- How about adding the badges to the "print certificate" feature (integrated or separately)?
- In Manager/Client.
Server
- Project-specific badges defined in project database
- Rule-based assignment: use SQL to determine eligible users/teams per defined badge
- Project task to update the assignments by processing ruleset
- Support manual assignment of badges (e.g. via OPS page)
- Stats site support
  - Extend user profiles and team data to include badge references
  - Provide set of (project) badges in dedicated download (sub)directory, tailored for (r)sync.

Database schema

The following tables represent a database schema representing the ideas above. It allows for badge definition and assignment:


badge
id : int (pk)
title : varchar
description : varchar
level : varchar
image_uri: varchar
sql_rule : varchar
create_dt : timestamp
team : boolean
tags : (set or varchar/JSON)


user_badge
uid : int (pk)
bid : int (pk)
create_dt : timestamp
reassign_dt : timestamp


team_badge
tid : int (pk)
bid : int (pk)
create_dt : timestamp
reassign_dt : timestamp

Different levels of a single badge are supported by simply defining multiple badges, bearing the same title. The SQL rule per badge should be defined such that the different levels are distinguished. That is, define lower and upper bounds when you intend to use different levels for a badge.

We refrained from adding another relation for tags and de-normalised this attribute in favour of performance. We could use MySQL's SET type to support a bitmap of up to 64 pre-defined tags. However, that list would become part of the data model and would hence be very inflexible. Thus we propose to use JSON as textual representation that can be searched using regular LIKE statements and can be modified easily by available JSON support, e.g. in PHP. Upcoming versions of MySQL and MariaDB are going to include JSON support and will allow more optimised processing. XML would be far too heavy-weight for this purpose.

Badge assignments provide the means to expire old ones by filtering (or even removal) based on the reassign_dt attribute. Sorting of badge assignments can be done based on create_dt, e.g. newest-first.

Badge assignment process

A script runs periodically (e.g. a project task) and updates the badge assignments
The script iterates over all defined badges (badge table) and executes the respective SQL rules
- Each SQL rule (one per badge) returns a list if user IDs or team IDs (see next item)
- The attribute badge:team defines a badge to be team or user assignable
- Upsert (insert or update) the user/team IDs for the current badge ID into the user_badge and team_badge tables respectively
  - An update (only) resets the reassign_dt attribute to the current time

Open questions and challenges

How to ship the badges (images) efficiently?
- Should they be downloaded on demand (via URL) or shipped as "project file" (download on project attach/update) (looks infeasible with hundreds of possible badges)?
- Should they be downloaded as compound images (see stats site forum signature images) or separately?
How to ship badge assignment data to the managers?
- Part of scheduler request (length constraints!)?
- User-specific notices/RSS feed?
- Periodic web RPCs (e.g. extension of XML-formatted show_user.php)?
- Need to obey networking-preferences
Should updates (images and data) be incremental or always be a full snapshot (e.g. to support badge removal)?
How to implement cross-project badges? Are stats sites (e.g. BOINCstats) the natural place to do that?
- We could define a set of standard badges to allow stats site-agnostic assignment
- Should stats sites be allowed to come up with their own set of cross-project badges?

Work package assignments

Desktop manager: Rom and/or Charlie
Android app: Joachim
Server: David and/or E@H (TBD)
- DB:
- C++ bindings:
- PHP bindings:
- Project task/daemon:
- Stock web front-end:
- Drupal: Tristan
Project badges: each project
Cross-project badges: stats sites
Documentation:

Home