Let's talk about Easyfix

Project Discussion
1

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.

4 Likes
2

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
3

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

2 Likes
4

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.

5

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.

6

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

1 Like
7

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.:

https://pagure.io/fedora-join/Fedora-Join/issue/232

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 )

8

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).

9

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
10

This.

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”.

3 Likes
11

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.

5 Likes
12

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
3 Likes
13

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"
  tags:
    - perl
    - buzilla
- wpauthors
  name: "WordPress author counter"
  url: "https://pagure.io/fedora-commops"
  contact: "bcotton"
  tags:
    - WordPress
    - python
3 Likes
14

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 ( good-first-issue · GitHub Topics · GitHub ) 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
15

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

16

Hi @bcotton,

https://github.com/t0xic0der/fedora-easyfix/pull/2

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.

4 Likes
17

Beautiful!

2 Likes
18

I just tried using our easyfix page to find an issue that would be a good first issue for a programmer to get used to contribute to open source. All three issues that I considered have problems that make me believe that the current collection is not helping that much. Basically, the problem is that the projects are not curated enough. Besides having issues that are good documented and easy to address, also the project needs to be ready to receive them.

Here are my examples:
Add -v, --version option to fedora-business-cards
This sounds like a great first issue, clear task, easy to achieve. Now looking a the issues, the problems are:

  • the task is already assigned to someone
  • there was already a patch posted for this a year ago: PR#11: Added version flag in cli - fedora-business-cards - Pagure.io
  • the PR received some comments and does not seem to be sufficient but is still open
    So this leads to the questions:
  • Is the project still maintained? What is expected from a new contributor at this point? Do they first need to ask if someone is still working on this?
    IMHO, if this is still a valid easyfix, the issues should be unassigned, the PR should be closed and there should be a comment by the maintainer about the state

RFC: Extend max-line-length from 80 to 88+ (100?) in freeipa
Again, a trivial issue, nice task for someone to do something

Again, this issue is not curated, it should not be there.

Report rpmlint version used for checks in taskotron/task-rpmlint

Now I am frustrated. Maybe there are some issues in there, that are good first issues but these were the three first issues that I checked and looked like possible candidates at all. So IMHO, if we want to promote tasks/projects, there needs to be some regular vetting for the projects to make this a benefit.

2 Likes
19

+1, the question has always been: how and who does the vetting?

Ideally, maintainers/contributors that add projects to the easyfix list should keep their project lists up to date but maybe some automated checks can be added on the easyfix side of things too? Perhaps issues can be listed by age (to indicate staleness?) and things like that?

This sort of things is slightly tricky with the current “static” implementation, but with the rewrite @t0xic0der has planned these features can perhaps be added?

20

In my opinion, it needs a dedicated volunteer who will be doing this.

The maintainers are currently responsible for this but this does not work. Maybe it can be made simpler with automation, so that maintainers need to promote issues regularly to keep them being listed.

1 Like