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

fix parsing errors and sphinx warnings

Browse source 
Signed-off-by: Ryan Lerch <rlerch@redhat.com>
This commit is contained in:
Ryan Lercho 2023-11-16 08:02:56 +10:00 • committed by zlopez
parent 8fb9b2fdf0
commit ba720c3d77
98 changed files with 4799 additions and 4788 deletions
Download patch file Download diff file Expand all files Collapse all files

210
docs/badges/prop_rewrite_entities.rst
View file

@ -1,146 +1,132 @@
.. _prop_rewrite_entities:
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.
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).
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).
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).
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 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).
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 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).
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 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.
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 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 <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.
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.
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.
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.
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.
**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.