Let's talk about Easyfix

I was just in a conversation with @misc regarding the probable steps forward with revitalizing Easyfix but then it suddenly dawned upon us - there must be some reason why it has not been updated and reworked upon for so long and we are definitely not one of the first ones to think about giving it a little love. Has the user count declining for it or is it something that we do not use anymore?

Before the W&A team could potentially start working on the Easyfix, it is quintessential for us to understand its relevance in the current times and how useful has it been to the newcomers and the repo-owners, alike. We could, of course, go ahead and revamp that thing in terms of look and feel but I think it would really be worth our time to know if are trying to solve a problem that doesn’t exist.

Opinions are appreciated. Like a lot.


I am tagging some folks from the Join SIG who have been around for a while now.

@grumpey @alciregi @ankursinha @siddharthvipul1 @bt0dotninja @hhlp

Some infrastructure folks too who would have an idea about the engineering side of things.

@kevin @darknao @nb1 @codeblock

1 Like

Revmap Easyfix is very important from the point of view of the teams to attract new contributors, it is a key point of each team to keep the tickets easy to do up-to-date, because of this we do not assign tickets, this is not the way Open Source works, this means we provide tools so that new contributors easily find the tasks easy to do and integrate quickly into the community and the way of it works.

Regards., HTH


These are the sources:

This script:

It just gathers tickets and puts them through a Jinja template to generate the page. The script is run regularly on Fedora infra. That’s all it is at the moment.

Hi @ankursinha,

I think I wasn’t able to convey myself clearly. I am aware of what Easyfix is and it has been worked upon by the team too. In the discussion that I had today, we realized that we probably should go back to the drawing board and see if at all there is a need for such a revamp - before we commit time/effort into working for that.

Easyfix and Join SIG, both being, the entry point for newcomers - it would be of great help if we could understand as to how actively it has been used, why it has not been maintained and if at all it is something which we need. That is something that the folks who have worked on it would probably have an idea of.

For example, do we have a rough idea of a contributor who used easyfix to enter in the community ?

1 Like

It was for the benefit of others who may not know how easy fix functions, since that’s an important indicator of the amount of work that revamping it may need.

Well it is maintained—it functions and when/if it breaks someone steps up to fix it. The reason behind “why it hasn’t been revamped” till now is a combination of “if it works, don’t fix it” and the unfortunate inactivity of the/a websites team.

A general problem here is that there’s no data on how/if it is being used. We have zero analytics here so tickets may be picked up and removed and so on but we have no way of tracking this.

I also remember that we had some discussions about this and you had opened a PR etc.:


Are we continuing from there or are we starting afresh in perhaps new directions?

(3 of the 4 remaining tickets are not related to the easyfix tool itself: Issue #59: [Tracker ticket] Proposed improvements to easyfix - Fedora-Join - Pagure.io )

Not that I’m aware of (but let’s wait for the infra folks to weigh in since they’d know if there was something of the sort).

Appreciate it. Thanks!

Makes me wonder if we should have some kind of analytics engine to garner its activity logs on this attempt of rewriting it. If we do not have an idea of to what extent it is useful, we cannot quite say that working on the Easyfix would be worth our while. :confused:

I did work on the older code and brought it to a position where it could just work while looking good. With my rewrite, there was still one problem - the renderer code more or less stayed the same. That is why we decided on starting afresh with finding a much more efficient way to gather tickets from GitHub/Bugzilla/Pagure and asynchronously fetching it from the client-side.

Considering the conversation we have in yesterday’s Websites and Apps meet regarding this, we decided the following things -

  • The Easyfix’s rewrite, promotion and it being worth to be worked on would be discussed in the Mindshare Committee meeting. (CC. @riecatnor and @thunderbirdtr)
  • Articles need to be written on Community Blog to promote the project’s existence and purpose (CC. @lilyx)
  • Reaching out to folks asking them to check if their repos have some self-contained and well-documented tasks (CC. @lilyx)
  • Making it a pluggable resource by wiring things in such a way that other communities who feel the need of using something like this could be able to fork and reuse ours without much added effort (CC. @jflory7)

Let us see where it takes us. Feel free to let us know if you were helped by or interacted with Easyfix or if you know someone who did - we would love to know their experiences and that would help us justify our rewrite attempt. :slight_smile:

1 Like


And this.

Looks like the most important thing right now is to gather the “data on how/if it is being used” to prove “if it works”.


I guess this is the Easyfix website - Fedora Project easyfix

Things I do not find encouraging.

Too much choice

I am tired just after reading thorough the issue titles.

Good example - https://www.codetriage.com/ - one issue per day to email, projects are in boxes instead of lists, boxes have catchy issue numbers that I can at least somehow compare, there is a visible filter of boxes by language, and boxes carry project descriptions.

Alphabetic sorting

Project starting with A are not necessarily the most interesting or encouraging to go on. And without some kind of shuffling, issues that are attractive and interesting will be fixed, and the ones that will remain at the top will be the best at scaring people away.

To fix this, a random sorting with a seed to bookmark, or another algorithm can be used. Maybe mixing issues without even mentioning the projects for a bit of intrigue.

No gameplay

The list is, well, a list. It doesn’t even update the status if you took an action. It is as boring as a list. It is not even a character sheet list. It is just… a list… of problems… things floating in the endless space of unknown… and unclear. Well, it does look like a list of quests. Although those quests brings no rewards, no achievements, no progress and level ups, skills, loot boxes, events and discounts on pay to win items… (pause) There is a challenge, yes… And the gameplay starts once you get deep into it. But there is no gameplay to get you hooked.

No community

It is just you and the issue. No support, no happy/grumpy tweets, writeups and postmortems, no people who struggle to understand that a base runner is, and who write openly about that. It is just you and the issue… and maybe maintainer, who is so knowleadgeable and busy about the project, that distracting him with silly questions seems like the worst thing in the world you could do right now.


The Mindshare Committee discussed this in their weekly meeting. The team generally agrees this is a great tool, and we want to help support the initiative to improve the site. Here are some notes from our meeting:

Benefits of an “easyfix” website

  • highlighting easyfix / newcomer friendly bugs across a project has huge potential to help on-ramp new contributors
  • can help improve process for mentored projects, easyfix tasks are a part of the process of onboarding outreachy applicants

Our knowledge of status

  • no idea if it has actual users now. i cant imagine it does, it’s confusing
  • not very intuitive, not sure where to start

Teams/Groups that should be involved

  • Mindshare is a great way to coordinate the easyfix triaging, since we are connected to the most active teams on the Mindshare side. Can provide a lot of support with the internal outreach needed.
  • We should involve FESCo. That committee talks about standards. Do we have a standard tag for easyfix and newbiefriendly across issue tracker tools?
  • We should involve the D&I team, we want to ensure the site is accessible and any DEI concerns taken into consideration. (@riecatnor to bring this to the next D&I team meeting)
  • The Join SIG specializes in this work, want to make sure their experience working on the front line is heard in this discussion.
  • Fedora Council should be aware of the discussion and provide input if desired
  • Translations team should be aware of the discussion and provide input if desired.

Ideas for Features/Improvements

  • more publicity about it via magazine/comm blog
  • ask our community members to tag them with easyfix more often
  • The initiative should be publicized on the devel list requesting feedback
  • Emails should be sent to devel and other lists periodically reminding people to triage
  • We would propose “good first issue” instead of “easyfix”, as what is “easy” is objective. or use of both tags with different definitions
  • Create a badge series for triaging pagure tickets with the tag “good first issue” or “easyfix” to help provide incentive for continual triaging

I’d suggest using a text file in a format like yaml (example below) to feed the list instead of the wiki page. One, that would enable the removing of all the wiki parsing code. Two it makes the site more self-contained, which is useful if other communities want to use an implementation of it. Three, it allows us to add tags for things like the language, related tech, etc.

The downside is that submitting a new project has a slightly higher barrier to entry.

Example of what I’m thinking for a yaml file (could also be json, ini, whatever)

- bzeol:
  name: "Bugzilla EOL closer"
  url: "https://pagure.io/fedora-pgm/pgm_scripts"
  contact: "bcotton"
    - perl
    - buzilla
- wpauthors
  name: "WordPress author counter"
  url: "https://pagure.io/fedora-commops"
  contact: "bcotton"
    - WordPress
    - python

Yeah, there’s no statistics or currently much way to know if this is getting used. :frowning:

It might be worth considering our goals here and revamping things to better meet them.
Are we trying to add regular contributors? Help people with limited time do drive by commits to fix things? Help people figure out what part of our project they want to contibute to?
I’d suggest we ideally want several different groups: 1) new folks looking for a place to contribute more, 2) people with limited time just wanting to help and fix some easy thing and 3) drive by contributors that just want to fix something and move on.

Github has a ‘good-first-issue’ tag ( https://github.com/topics/good-first-issue ) perhaps it’s worth adopting that convention too (if thats one of our use cases). Of course easyfix aggregates easyfix tagged issues from pagure projects, bugzilla and more.

Also, it probibly is worth advertising to our existing contributors more. There’s only 9 bugs marked in bugzilla, and only 26 github/pagure projects. ;(

1 Like

That list also has some projects that implement aggregators, so worth looking at (and perhaps deriving from/extending). For example:

Hi @bcotton,

This pull request addresses this suggestion by doing away with the dependence on the wiki page for repository listing and makes it very pluggable, in a way that people can add support for GitLab, Gitea etc. down the line.