Rewrite Fedora Badges From The Ground Up

Something which is state-of-the-art right now,
will eventually and inevitably become a tech debt tomorrow.
– Pierre-Yves Chibbon, Sometime in 2021

We are proposing a rewrite for the project from the ground up.

Justification

  1. The web interface and the API service for Fedora Badges is written in Python 2 which has gone EOL on January 1st, 2020. We could have proposed a 1:1 rewrite of the same functionality in Python 3 but reimplementing the features in ways that are more relevant now, makes more sense.

  2. The messages consumer is bound to the fedmsg and needs to be reimplemented to be compatible with Fedora Messaging. As these two projects are inherently different from each other in their function, not a lot of code can be salvaged from the previous implementation of the messsages consumer, even though the strategy/approach can be.

  3. The web interface and the API service for Fedora Badges is written using the Pyramid web framework and makes use of Mako templating system which are not as popular as their alternatives, Flask or FastAPI and Jinja respectively are.

    • Maintaining the codebase in its current state can be a challenge in the absence of comprehensive documentation, popular community support and frequent question/answer activity on forums regarding the topics related to the Pyramid web framework and Mako templating system.

    • Finding interested community members (or getting people interested to contribute to the project) can be difficult if a set of comparatively obscure or unpopular technologies are used, which might deincentivize participation here due to a relatively steep learning curve.

  4. The frontend of the web interface is written in a form of a meta-application (i.e. the frontend is supposed to behave like an application and yet is implemented like a website) using (now, dated) templating systems, plain HTML, CSS3 frameworks and Javascript libraries. These could use a rewrite for improved application-like functionality and interactivity.

  5. The current codebase has residual and/or partial implementation to accommodate Open Badges (or Badgr) standards for storing artworks data, awarding conditions, awardees etc. which have potentially never been completed and/or deployed. Cleaning up the said codebase or completing it before maintaining the project in its current state would require lots of effort.

Implementation

Here is how we are planning to have the project redeveloped.