3 | | 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 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 Fritsch, propose to standardise and extend this feature to all interested BOINC projects and beyond. |
| 3 | 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 Fritsch, propose to standardise and extend this feature to all interested BOINC projects and beyond. |
59 | | == Open questions and challenges == |
| 57 | || __badge__ || |
| 58 | || id : int (pk) || |
| 59 | || title : varchar || |
| 60 | || description : varchar || |
| 61 | || level : varchar || |
| 62 | || image_uri: varchar || |
| 63 | || sql_rule : varchar || |
| 64 | || create_dt : timestamp || |
| 65 | || team : boolean || |
| 66 | || tags : (set or varchar/JSON) || |
| 67 | |
| 68 | |
| 69 | |
| 70 | || __user_badge__ || |
| 71 | || uid : int (pk) || |
| 72 | || bid : int (pk) || |
| 73 | || create_dt : timestamp || |
| 74 | || reassign_dt : timestamp || |
| 75 | |
| 76 | || __team_badge__ || |
| 77 | || tid : int (pk) || |
| 78 | || bid : int (pk) || |
| 79 | || create_dt : timestamp || |
| 80 | || reassign_dt : timestamp || |
| 81 | |
| 82 | |
| 83 | |
| 84 | 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. |
| 85 | |
| 86 | Badge assignments provide the means to expire old ones by filtering on the `create_dt` attribute. Sorting of badge assignments can be done based on the `reassign_dt`, e.g. newest-first. |
| 87 | |
| 88 | === Badge assignment process === |
| 89 | * A script runs periodically (e.g. a project task) and updates all badge assignments |
| 90 | * The script iterates over all defined badges (`badge` table) and executes the respective SQL rules |
| 91 | * Each SQL rule (one per badge) returns a list if user IDs or team IDs (see next item) |
| 92 | * The attribute !badge:team defines a badge to be team or user assignable |
| 93 | * Upsert (insert or update) the user/team IDs for the current badge ID into the `user_badge` and `team_badge` tables respectively |
| 94 | * An update (only) resets the `reassign_dt` attribute to the current time |
| 95 | |
| 96 | '''Open questions and challenges''' |
| 97 | |