A while ago we had a page that would list all the issues labeled "EasyFix" in the applications we use in Fedora to build the distribution, or that we are upstream for and use in the distribution. This page was statically built by a periodic task, and the generator ended up not working anymore due to API changes and was dropped. About a year ago, I made a couple fixes to it to make it work again and refresh it slightly, which gave use this page: https://easyfix.apps.ocp.stg.fedoraproject.org/

The idea is good and useful, but the implementation is still a hack and should be properly rewritten. Here are some requirements:

• Write it as a webapp with a python-based backend (Flask is preferred, FastAPI is fine too, Django is OK).
• Use an actual database instead of parsing a wiki page to list projects
• Use authentication (OpenID Connect)
• Every authenticated user can define dashboard pages that would gather multiple tags from multiple projects in any supported Forge. For example, the "easyfixes" dashboard would collect "easyfix", "good first issues", etc, the "CPE" dashboard would collect the "cpe" tag, the "Larger projects" dashboard would collect "next phase", "long term", etc.
• Dashboards can be owned (editable) by users or groups and readable by users, groups or public
• Public dashboards can be viewed without authentication, accessible from the front page
• To build a dashboard, the user can list a project on Github / Gitlab / Pagure
• Each issue will have informative details such as the description, the creation date, the last modification date, whether it's assigned to someone, other tags, etc. The aim is to give all relevant information for a new contributor to choose an issue to work on.
• On the backend, the crawler runs asynchronously from a cron job.
• The crawler will try to limit the number of API calls made to the Forges, and handle rate-limiting
• The backend is modular and supports Github, Gitlab, and Pagure. It should be easy to add Codeberg one day, for example.
• It should run in OpenShift, and use S2I in the source to be built there easily.
• The frontend should be themable (imagine it being branded for OpenSuSE, Almalinux, etc)

Strech goals:

• The backend can accept webhooks from the forges, detect if one of the known tags has been applied to an issue, and trigger the crawler to refresh the corresponding entries in the database. Adding a project to track would display the URL (and secret?) to add to the project's webhooks.
• Users can authenticate with Github / Gitlab / Pagure's oAuth2/OIDC systems, which would give them the token to automatically add the webhook to the project if they have the proper permissions
• The frontend is dynamic (Vue.js preferred for coherence with other apps) and will refresh dashboard pages when the data is updated by the crawler. Redis or RabbitMQ can be used as the event broadcast system on the backend.

The Fedora Project would use this app to offer an entry point to newcomers to contribute to our applications. It should also be usable by other OpenSource projects, and should make an effort to limit any Fedora-specific code to a module or a plugin that can be replaced.