Entities involved

Let us dive deep into the entities that would come together to make the Fedora Badges project functional. We will call them “entities” for the context of this discussion. Also, the names used for the entities here are temporary in nature and are, for the most parts, only representative of the functions that these entities perform.

Here is a diagram exhibiting the proposed architecture.

../_images/badges-proposed-architecture.png

Internal entities

Accolades API - Backend service
  1. Succeeds the existing Tahrir’s backend API and/or is planned to be a reimplementation of the same.

  2. This is planned to act as the backend service for the entire project and has direct interactions with its neighbouring internal entities (i.e. Collection, Database, Liberation, Messages Consumer, Accolades CLI).

Accolades CLI - Client application
  1. Succeeds the existing Tahrir API client and/or is planned to be a reimplementation of the same.

  2. This is planned to act as a client application and/or library, usable for automating purposes like pushing of badges (and their related awarding conditions) to the Collection via the Accolades API, and other such high level interactions offered by the Accolades API.

  3. This is planned to be a standalone entity with just one possible interaction with the neighbouring internal entity (i.e. Accolades API) and three possible interactions with the neighbouring external entity (i.e. community users, badge owners and service admins).

Liberation - Web interface
  1. Succeeds the existing Tahrir’s frontend part and/or is planned to be a reimplementation of the same.

  2. This is planned to act as an interactive client application, accessible via modern web browsers, usable by community members and service admins for purposes like looking up the Fedora Badges leaderboard, checking badges awarded to self or someone else etc. and adding new badges (and their related awarding conditions) etc. respectively by interacting with the Accolades API.

  3. This is planned to be a standalone entity with just one possible interaction with the neighbouring internal entity (i.e. Accolades API) and three possible interactions with the neighbouring external entity (i.e. community users, badge owners and service admins).

Collection - Artworks and rules
  1. Succeeds the existing Fedora Badges repository and/or is planned to be a reimplementation of the same.

  2. This is planned to be a repository of supporting assets (artworks, awarding conditions, consumer rules etc.) for the badges available for being awarded to the community members, which can be read from and updated by the interactions with the Accolades API entity and the Liberation entity as well as by admins having relevant accesses to the repository.

  3. This is planned to be a standalone entity with just one possible interaction with the neighbouring internal entity (i.e. Accolades API) and one possible interaction with the neighbouring external entity (i.e. repository members).

Database - Achievements storage
  1. Succeeds the existing Fedora Badges database storage for storing the badges awarded to community members, date of felicitation and other details and/or is planned to be a reimplementation of the same.

  2. A huge chunk of the existing database is planned to be reimported into the newer schema and the columns specific to the Open Badges (or Badgr) compatibility will not be taken into consideration. This can be read into and updated by the interactions with the Accolades API only.

  3. This is planned to be a standalone entity with just one possible interaction with the neighbouring internal entity (i.e. Accolades API) and one possible interaction with the neighbouring external entity (i.e. service admins).

Messages consumer - Conditions listener
  1. Succeeds the existing fedbadges fedmsg listener and/or is planned to be a reimplementation of the same.

  2. This is planned to act as a messages consumer, listening into the Fedora Messaging bus matching the schemas that it is configured for and comparing the messages against the awarding conditions available on the Collection, and on a successful match, making a request to the Accolades API for awarding the said badge to a certain contributor who have met the conditions specified in the related badge rule.

  3. This is planned to be a standalone entity with two possible interactions with the neighbouring internal entities (i.e. Accolades API and Collection) and no possible interaction with the neighbouring external entities.

External entities

Service admins - Access Level IV
  1. Consists of people belonging to the Badges Administrators group.

  2. People have access to the deployment environments (staging, development, production etc.) and can control most of the aspects of all the internal entities.

Badge owners - Access Level III
  1. Consists of people who either lead or represent certain subcommunity, SIG or subproject within the Fedora Project community, who want to make new badges available and set rules for awarding.

  2. People have an elevated access to the Liberation and Accolades CLI, which enables them to access, create, change, award and delete badges that they “own” (not those that they “have been awarded”).

  3. If there does not exist a designated IPA group for marking out these entities, a new one can be created and they can be added to the same for easing access control processes.

Repository members - Access Level II
  1. Consists of people who either design, create and/or facilitate new badges and want to make them available and set rules for awarding.

  2. These are the people who can fall under the “Badge owners” category too but that might not necessarily be the case always (for eg. badge designers who do not lead or represent another subcommunity, SIG or subproject but are tasked to create and upload badge assets).

  3. There need not be a designated IPA group for marking out these entities as their access is restricted to accessing, creating, changing and deleting badges assets available on the Collection entity, which is simply a version control system mediated repository.

Community Users - Access Level I
  1. Consists of generally everyone from the Fedora Project community who have a valid and activated, IPA account and have signed the Fedora Project Contributor Agreement.

  2. These are the people who are eligible to only receive badges for their recordable actions (i.e. those which either trigger a message on the Fedora Messaging bus or are noticed by a Badge Owner entity) within the Fedora Project community.

NOTE - These access levels are not exclusive in nature. A person who has an Access Level IV, can (but not necessarily will) have those beneath it too and by default, every FPCA signed member of the Fedora Project community, has at least, Access Level I.