Hello Ludo,
> All this contributes to a [poor > experience](https://guix.gnu.org/en/blog/2025/guix-user-and-contributor-survey-2024-the-results-part-3/) > for those who choose to contribute despite the barrier to entry, probably > discourages many to even start contributing, and adds to the load of > committers and infrastructure maintainers. While I have differing views on the poor experience, from the 3rd part of survey’s results, don’t we see the answers to "What would help you contribute more to the project?" has answers of differing priorities? Only 9% of contributors feel like the addition of a PR-based workflow ála Github/Codeberg/Gitlab would lead to them contributing further but while 203 respondents (a total of 20%) report that it’s the timely reviews and actions on contributions that inhibit motivation for further contribution. I have started contributing over the last few months, and the current (Savannah, email based) workflow was a bit difficult but I overcame it in a few days, not even a week. And I’d certainly accept that I had an existing workflow for similar projects I contribute to, and have had used Gnus, and debbugs.el, but the learning curve isn’t really that much of an issue, from my personal opinion. What I do think could lead to better contributions is what’s reported in the survey before the workflow change, i.e, timely reviews, better REPL debugging and most importantly a guidance/mentoring setup. Guix Social goes far enough to enable this to some extent, thanks to Steve, but we should have a workflow where we keep certain issues/upgrades as low-hanging fruit for the beginners, and walk them through it over time. I had Ekaitz do the same with me, when i was contributing my first package to Guix. And I’d always be grateful for that, because if I hadn’t had that mentoring for a day or two, I’d have gotten frustrated and kept contributing to Guix aside for a while. I use and have used Codeberg and Sourcehut, it’d be not an issue for me to switch either way. Though I do have to ask, would there be an intent to maintain a mirror at Savannah, if Guix chooses to primarily shift to codeberg/forgejo? And also, it is better to go with Forgejo as a self-hosted instance than relying on codeberg.org since the latter has limitations on how big repositories you can host[0]. I’ve heard they can provide more, but since we already have existing infrastructure, why not go the self-host path? I’d be glad to contribute to the migration however I can, but I suggest we reflect on the necessity and consequences of this a bit more. [0]: https://docs.codeberg.org/getting-started/faq/ Regards, -- Divya Ranjan, Philosophy, Mathematics, Libre Software. PGP Fingerprint: F0B3 1A69 8006 8FB8 096A 2F12 B245 10C6 108C 8D4A
