On 2025-09-23, [email protected] wrote: > On Mon, Sep 22, 2025 at 11:42:42PM +0200, Tomas Volf wrote: > > The other aspect I see is that the teams in Guix don't seem to work as a > 'team'. There's no shared team goals, discussions or organisation. In my > previous experience we had team boards/todo and regular IRC/video meetings. > This > sort of organisation doesn't seem to be in Guix's culture :-) Maybe we will > see > this change a bit with Codeberg - I've seen a few 'milestones' being used. > > Steve / Futurile
Moving to Codeberg was well-intentioned, but it doesn't solve the root problem of Guix contributions. It may be more user-friendly, especially if you don't have technical knowledge, but it can also be equally or more difficult for both contributors and maintainers, as it follows the "GitHub" model. Because if you're an first time contributor and you submit a PR adding a package, and more than two months the PR still open without reviews[1][2], it will be frustrating, and you might reconsider contributing again. If you're a maintainer and your issue count grows too much, you'll be overwhelmed. If the number of open PRs grows too much, you'll also be overwhelmed. Where do I start? The "Github" way of making it easy to create issue reports and open PRs, the problem really is who reviews and accepts those PRs/issues. In Github's success stories, there is usually financial support from companies or sponsors. What they don't have is what happens to them like https://github.com/flutter/flutter/issues for a well-known project but with few external contributors. Not having an owner per package, like Debian or Arch, has its advantages—it's more decentralized—but its disadvantages: the sense of ownership is lost. For example, someone submits a package and contributor disappears, that package could have in the future security flaws, and no one is responsible for it. With teams, as mentioned, it can be one or two people. It's basically "someone added a Rust package, and now I don't have to maintain 1,000 packages, but 1,001." The team unwittingly has to become responsible for what others submitted. In Debian, it's perhaps easier because its releases are longer-term, like Guix being a rolling release. People have high expectations for Arch packages, frequently updated packages, which can be another point of frustration for users. Perhaps we should look at the experiences of Debian and Arch regarding successful contributions. In the case of Arch, there are package owners, but also teams and occasional contributors, a mixed model. Perhaps we could take inspiration from something like: https://wiki.debian.org/Teams/MIA, a team for auditing/QA of orphaned packages. I think the issue is how to get that contributor to stay. But I agree that there is a need to align teams and team objectives and general Guix goals, for example, a new version of Guix-oS with which to reduce the time of the first GUIX pull? Footnotes: [1] https://codeberg.org/guix/guix/pulls/815 [2] https://codeberg.org/guix/guix/pulls/1292
signature.asc
Description: PGP signature
