I wonder if there was a specific team or SIG in Fedora that might be willing to help trial an idea like this. If we could find an approach that worked well for a team or a smaller group, it would be easier to scale it out more widely to the rest of the Fedora community.

I like the idea of cross-sectional teams for this, so two teams that come to find as possibly good candidates would be the Websites & Apps Team and the Python SIG. I have not asked those teams about this yet.

I wonder if there was a specific team or SIG in Fedora that might be willing to help trial an idea like this. If we could find an approach that worked well for a team or a smaller group, it would be easier to scale it out more widely to the rest of the Fedora community.

I like the idea of cross-sectional teams for this, so two teams that come to find as possibly good candidates would be the Websites & Apps Team and the Python SIG. I have not asked those teams about this yet.

EasyFix includes QuickDocs issue ticket. Docs team can use 'Good First Issue' label in Pagure. We need more technical reviewers, who are subject matter specialists to a product(s). I expressed my interest in Easyfix to @ankursinha in Discussion. I'm in.

It'll be great to have docs in it.

@jflory7 : could you clarify a little more what the idea to limit this to specific teams is? is it that we only add it to their tasks for the release cycle to begin with?

I was thinking of posting a "Please spend 2 minutes marking your EasyFix issues" thread to -devel per release, similar to the "Please spend 2 minutes testing upgrades to Fedora N+1" thread that we now have per release. So, having this item in the release schedule will provide them more visibility (and remind us to do it).

A late follow-up from me, but late is better than never.

@ankursinha wrote…
@jflory7 : could you clarify a little more what the idea to limit this to specific teams is? is it that we only add it to their tasks for the release cycle to begin with?

The existing easyfix list has a low signal-to-noise ratio. There are archived projects on the list with no clear maintainer. To some extent, we likely need remove some projects or come up with general criteria for how a project can be listed on this page.

From there, I think working with specific teams might be more effective first because we can make smaller, more specific asks. A connection is built with the team maintaining the info, and then we can make more general asks to everyone about maintaining it or building a new day into the schedule.

What do you think?

@ankursinha wrote…
I was thinking of posting a "Please spend 2 minutes marking your EasyFix issues" thread to -devel per release, similar to the "Please spend 2 minutes testing upgrades to Fedora N+1" thread that we now have per release. So, having this item in the release schedule will provide them more visibility (and remind us to do it).

I think an email blast to devel certainly cannot hurt though.

We could perhaps tweak easyfix to only list tickets that have had activity in the past N months (or some time period), the idea being that if they haven't received activity in this period, they're considered "stale"?

The other alternative is for a human to go through projects and keep the list of repos featured there up to date from time to time. I guess this could be automated/scripted in some way so that the PoC is sent a notification asking them to "check-in"?

An e-mail blast would be good start though---that's like a general reminder to everyone that EasyFix exists and they should update their tickets/repos. What would we need to do to get this going?

@ankursinha wrote…
An e-mail blast would be good start though---that's like a general reminder to everyone that EasyFix exists and they should update their tickets/repos. What would we need to do to get this going?

We need an owner for this task. There was a job posting for a Fedora Operations Architect position. This might be a good task for that person. I will share this idea with @mattdm and circle back here after discussing with him.

@amoloney I wanted to bring this idea to your attention with regards to the release schedule and whether we could consider some sort of communications step to encourage people to curate "easyfix" bugs and tasks in projects for new contributors to discover.

There might be a pre-requisite step of creating some clear documentation about how to update easyfix bugs, but if we had that in place, would this be a good idea?

@rwright @bt0dotninja Tagging you both on this as something of interest to the onboarding aspects of the new CommOps Community Initiative.

Documentation on how to set up projects for Easyfix is here. It can be improved/moved elsewhere if required:

https://fedoraproject.org/wiki/Easyfix

I dont think this is suitable for the release schedule. I think its a great idea, but its not release blocking and so should not be included in the schedule. This sounds to me like something that's best placed in an onboarding SIG or group, and coordination with marketing SIG would address the exposure issue.

See Fedora-Council/tickets#482 for further discussion on this topic.

Perhaps this ticket can be closed as Duplicate to focus the discussion into the Council ticket?

+1