#141 Easyfixes webapp
Opened 2 months ago by abompard. Modified 2 months ago

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.


This project seems to be well-defined and has a clear scope. There are some key objectives that are laid out that seem to be achievable for an intern with a bit of Python experience.

Was any thought already put into how to evaluate an intern's capability during the application phase? Since this seems like a new project, I am curious how applicants will get a chance to get introduced to Fedora and showcase their abilities before a decision needs to be made.

@ankursinha Paging you here, because this project proposal seems like something you might want to follow too.

@abompard There is a chance I can fund both projects, but there is also a chance that I can only get one funded. If you had to choose between this project and #142, which is more important/valuable to run?

Was any thought already put into how to evaluate an intern's capability during the application phase? Since this seems like a new project, I am curious how applicants will get a chance to get introduced to Fedora and showcase their abilities before a decision needs to be made.

I was thinking they could use the existing Easyfixes webapp to fix a couple existing issues in our apps. I mentionned that in the Outreachy application because it was one of the forms fields, but forgot to do it here.

@abompard There is a chance I can fund both projects, but there is also a chance that I can only get one funded. If you had to choose between this project and #142, which is more important/valuable to run?

For the team, #142 would be more valuable as we've needed this for a couple years now, and some of the apps (namely github2fedmsg) are dearly in need of a rewrite, mostly because of the RHEL7 deadline. But the Easyfixes app may be more interesting for an applicant as it is more generic. It may (or may not, I don't know) be more interesting for the Fedora Project as a whole, since it could be used to bring in more contributors.

As a member of my team that feels the pain of having to maintain obsolete all-over-the-place software, I would vote for #142, but feel free to override this as "too subjective" ;-)

Metadata Update from @t0xic0der:
- Issue tagged with: Outreachy, project-idea

2 months ago

Metadata Update from @jflory7:
- Issue set to the milestone: Outreachy 2024

2 months ago

This is submitted in the Outreachy project portal, but I am keeping it pending due to a surplus in projects than what we are able to fund.

Login to comment on this ticket.

Metadata