Infrastructure/arc
3
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Add rewrite proposal details for Fedora Badges

Browse source 
Signed-off-by: Akashdeep Dhar <akashdeep.dhar@gmail.com>
This commit is contained in:
Akashdeep Dhar 2022-12-14 13:43:59 +05:30 • committed by zlopez
parent af24160c4a
commit 0e41bb0205
12 changed files with 333 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

144
docs/badges/prop_rewrite_entities.rst Normal file
View file

@ -0,0 +1,144 @@
.. _prop_rewrite_entities:
Proposed Entities
====
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.
.. image:: ../_static/badges-proposed-architecture.png
:target: ../_images/badges-proposed-architecture.png
Internal entities
----
**Accolades API** - Backend service
1. Succeeds the existing
`Tahrir <https://github.com/fedora-infra/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 <https://github.com/fedora-infra/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 <https://github.com/fedora-infra/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 <https://pagure.io/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 and 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 <https://github.com/fedora-infra/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 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 <https://accounts.fedoraproject.org/group/sysadmin-badges/>`_
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 <https://accounts.fedoraproject.org/>`_
and have signed the
`Fedora Project Contributor Agreement <https://accounts.fedoraproject.org/user/t0xic0der/settings/agreements/>`_.
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.