Hey everyone and wish you folks a very happy and prosperous new year!
As we head towards the end of the extensive ARC investigation for Fedora Badges, the scope for the development and maintenance of the system has become clearer than ever before. Not only did we largely explore the system in its current state, but we also delved down the path of reworking it with two probable approaches - one, being the revitalization of the existing codebase and the other, being the complete rewrite of the project from the ground up.
Allow me to go further in detail about our observations and the conclusions that we deducted from them.
Fedora Badges is not a project, but rather a system constituting multiple projects like
- Messages Consumer (or fedbadges), which listens in to the (now, deprecated) fedmsg bus to know about the events that lead to awarding contributors
- Web Interface (or tahrir), which allows users to view their badges and that of others, the leaderboards of the top awardees, award badges to other users etc. from a web browser.
- Database library (or tahrir-api), which allows interaction with the database model at ease by abstracting the database classes, for tasks like creating and awarding badges.
- Collection of artworks and rules (or fedora-badges), which houses all the related artworks and awarding conditions, tracks issues and discussions and has documentation.
- Badge awarding scripts (or awarding cronjobs), that are triggered not by the messages, but rather run periodically to check if the conditions for awarding have been met.
A lot of these project repositories contain undeployed or incomplete feature implementations, do not have a functional testing environment and code compliance checks, use comparatively lesser-known frameworks and libraries, still rely on the (now EOL’d) Python 2, do not have a working project configuration and are inadequately documented.
Efforts put into the codebase in its current state would be largely spent on cleaning/maintaining the aforementioned items and lesser on working on new features and designs, and with the lack of documentation that helps people do so, this becomes less incentivizing of an opportunity for the contributors to partake in maintaining the system.
More about the current implementation can be found here. I highly recommend reading this through if you are interested to know how the existing system works.
Revitalization of the existing codebase - This approach aims to utilize as much part of the existing codebase as possible and update them to fall in line with the more recent functional requirements and deployment environments. This would take significant effort as the documentation about the system in its current state and the dependencies it makes use of is scarcely available. I recommend reading the following writeups if you are interested to get involved in developing Fedora Badges.
- ARC proposal - Revitalize Fedora Badges
Complete rewrite from the ground up - This approach aims to inherit the ways of the existing system and add meaningful changes to the workflow to meet the more recent functional requirements. This gives contributors a fair opportunity to partake in making choices, developing technologies and writing documentation for a system that they would maintain. I recommend reading the following writeups if you are interested to get involved in developing Fedora Badges.
Having explored both the options, we have come to the conclusion that it makes a lot more sense to inherit and expand upon the methodologies employed in the current codebase but implement the same from ground up in a new functional rewrite.
- Step 1 - Understand the project remit of the system to decide on the scope
- Step 2 - Get started with creating/inheriting the database schema for users
- Step 3 - Dump a snapshot of the existing database according to the new schema
- Step 4 - Brainstorm and document the interactions expected with the system
- Step 5 - Connect with the Fedora Design team to begin with the mockup designs
- Step 6 - Develop and document the Messages Consumer alongside Accolades API
- Step 7 - Test both against the dumped database and the existing Collection
- Step 8 - Develop and document the Accolades CLI and test its functionality
- Step 9 - Build Liberation frontend alongside the Fedora Websites & Apps Team
- Step 10 - Document and Test the frontend against the above mentioned entities
- Step 11 - Deploy and document the system on STAGING with the Fedora Infra team
- Step 12 - Release Accolades CLI as a Python package on PyPI and as RPM
- Step 13 - Announce public testing invites for the staging deployment
- Step 14 - Announce deprecation status for the existing Fedora Badges system
- Step 15 - Migrate database changes continually to keep up with the changes
- Step 16 - Switch the environment to production and… PROFIT?
Of course, there are and will be more things to account for than what meets the eye but from a Mount Everest high perspective - these are the steps we would want to suggest in the roadmap.
The in-depth analysis of the current state of the system could not have been possible without the foundational investigations done by @ryanlerch. I would also like to thank @zlopez, @lenkaseg and @patrikp from the Community Platform Engineering team, and @sayanchowdhury, @gui1ty, @bogomil and @ank22 who participated in the ARC investigation and provided their valuable insights on what this system can be developed into. I cannot appreciate @jflory7 and @eocarrol enough for kicking off the joint community effort for revamping the system.
Of course, last but not the least, thank you folks for reading this wall of text. Please feel free to reach out to me if you have any questions regarding this and I would be glad to help you.
Let us build Fedora Badges again. Together.