1. Understanding and Enhancing the Gamification Model
Assess the current value badges provide to the existing community
Evaluate their effectiveness in onboarding new contributors
2. Technical Improvements
Analyze how the new migration impacts user engagement
Identify ways to accelerate the rollout of the updated design
3. Problem-Solving and Innovation
Address primary challenges with realistic timelines
Explore opportunities for expanding the badges system
Methodology
To achieve these objectives, we would:
Data Collection & Analysis:
Gather badge ownership statistics (frequency and volume)
Track contribution and interaction patterns of badge owners
Monitor onboarding metrics following community events
Measure retention rates for new contributors
Conduct targeted interviews to understand the gamification model’s community impact
Key Questions to Address:
How can we better communicate the value of badges to newcomers?
What has been the effect of the Forgero migration on user interactions and eventually on badges?
What barriers are preventing the deployment of the redesigned badges system?
Logistical challenges
Technical obstacles
Requirements gathering
Automation needs
I want to emphasize that this is just a starting point. Many contributors have already done valuable work in these areas, and their expertise will be crucial to making this hackfest successful.
Timing-wise, the window between CentOS Connect and FOSDEM seems ideal—perhaps a 3-4 hour session. The goal would be to emerge with concrete objectives and a flexible roadmap that gives our efforts clearer direction.
I encourage everyone to share their thoughts and suggestions on this idea
One of the things @jflory7 mentioned to @abompard and me was that the hackfest / workshop would focus on moving the repos from GitLab and Pagure to Forgejo (along with the necessary workflows for the automation). Having codebase, documentation and assets across three forges made it difficult for folks to contribute, I would assume so it is reasonable to have it as the first priority. As for the other points, I would be wary of expanding to them until we have an idea of what the timeline looks like, and we have connected with the primary maintainers of the Fedora Badges stack to understand its current state. I have mentioned it here[1] that the we have a few folks slowly chipping away at the large cookie due it not being a priority and as such, we would absolutely hate to see the outcomes from the hackfest go to waste, if all it ends up doing it painting new targets for the same set of two to three folks contributing to the foundational part so far.
I would not really delve much into the metrics side. Not because I don’t want to - but because I want the likes of @gwmngilfen, @jspaleta, @rwright etc. (who are already doing it) to set the standards for the how the community health is being evaluated, instead of introducing one more target to pursue that has overlaps with the Fedora Commops[2] efforts. Then it is only a matter of aligning all the Datanommer entries from Tahrir Messages to work on just what information that we want out of it. That also reminds me the discussions around the Fedora Mindshare’s discussions on the remit of the Recognition Service[3] and the following call for feedback on the current efforts on revamp project[4] - that should take precedence IMO. Oh also - we need more badge pushers. Replacing one of the more ambitious / time-consuming parts of the proposals with this self-contained workshop might help unblock the badge proposals as they come.
Hi folks, I am checking back in here after the new year. Unfortunately, I know that not everyone is able to travel to Belgium for FOSDEM this year. However, I am aware we will have people like @ekidney, @abompard, @rwright, and @jspaleta in attendance. Possibly others.
Is it still useful to do something in-person around Fedora Badges there at FOSDEM? In particular, I’d like to think about how to make Fedora Badges a more strategic tool for measuring engagement in different parts of the community.
This work has been unrealized for two, nearly three, years. As part of the ongoing interest in revisiting Fedora Badges, I would really like to see this work integrated into a modernization effort. I’m not sure we could fit this into FOSDEM somehow. I’m not sure if there is a way we could “stage” things for @t0xic0der and @abompard to perhaps automate the integration of the new artwork?
Any thoughts on this? At FOSDEM, I could probably track down some time to sit down with anyone interested and organize these badge image assets into the existing git repo.
Perhaps we could also consider migrating the image assets to Forgejo, if the Pagure Exporter tool is ready for that task by the time FOSDEM comes around.
Since I am less than likely to make it to FOSDEM 2026 and Fedora Council Strategy Summit 2026, I would comment specifically on the functional parts of this discussion thread. The migration of assets from Pagure to Forgejo shouldn’t require the Pagure Exporter tool, as it could now be done easily from the Fedora Forge itself using the in-built Pagure Migrator functionality that we worked on in the previous couple of quarters. But the joining of the destination Fedora Forge repository to be the place where the artworks are sourced from in the Fedora Badges CDN could use some Ansible-related changes.
If the artwork files in the updated work are named appropriately, I could perhaps open up a branch that replaces the older artworks with the newer ones for review. But this task would take hardly 15 minutes or so, and hence, is not a hackfest-worthy thing to pursue, in my honest opinion. But hey, if we want to use this as a tool to explain to the newcomers how the Fedora Badges artwork repository is maintained, how to push new badges when they are requested (or heck, do it for the sake of having something to do there), I would keep myself from doing that unless explicitly asked to do so.
Oh right! This is what I meant. Do you think the built-in migration functionality is ready for a repository the likes of the Fedora Badges repo, with all of the design assets? Have the bugs been worked out with image uploads and whatnot?
Theoretically, this part should be pretty easy.
I have a feeling that the data angle is more interesting for some shared FOSDEM time. Maybe we don’t do so much hacking on code as much as playing with the data pieces that @mwinters and @rwright have been plumbing.
The part that could still use some work is associated with the issue ticket attachments, which we do not migrate anyway and simply point back to the source repository when they used to reside. This however is not a blocker and we could proceed with the migration as the changes have to do with the proxying and redirects from Fedora Forge to terminate at the static deployments of all attachments.
Fair enough, and hence, not hackfest worthy, I would assume.
I have not been following this as closely as I would have loved to. Apart from @gwmngilfen’s work on the contributor metrics that he exhibited in the Fedora Mindshare recognition service, I am pretty oblivious to what is going on in the Data WG. It could ultimately prove to be useful, though, and I am optimistic about ways in which Fedora Badges could leverage all the good stuff that they have been up to.
I am likewise out of touch with the Data WG stuff - I’ll see if I can catch myself up before FOSDEM, because we are indeed going to need that for the Badges work.
