Hi there! The move to codeberg was a blast and has (at least I guess so) both increased project-wide productivity as well as lowered the barrier for interested newbies to contribute to our glorious codebase! This is great news!
With the latest release we realized that some messages (like the master branch freeze) did not reach all committers in time—I for one only read about that by chance on IRC. That is because I was quite swamped with $dayjob and only went to codeberg to work off my notifications when I had time to do that. Reading [email protected] just did not make it to the top of my personal work stack often enough. So what we have here is (yet another) lack of definition of what we, as a project, expect from the roles we allocate. We discussed this issue, together with the question of roles and the GCD process (including the sometimes not so active discussion of at least one proposal) and came to the following options: 1. We define what we (as a project) expect from the different roles. E.g. committers are supposed to read and acknowledge messages coming through the guix-devel mailing list at least weekly. Like this we can expect that for example a branch freeze announced a week in advance is seen by everybody with the power to push. 2. We add another mailing list, that we expect committers to read before pushing stuff to master. These are both fine and should definitively be considered, but they do not really help channeling information. Teams can not easily add their information channels (who's in charge to open up mailing lists with gnu.org), the archives are not as easily searchable as they should be (especially for non GNU/hackers and other interested people out there) and maybe we could use this opportunity to decentralize responsibilities and enable centralization of communication channels. So there is this other option (that is somewhat perpendicular to the previous two): 3. We try this fresh, cool tool called Zulip¹, which Sergio introduced us to at Guix Days. This is not to replace current means of communications, but could extend in (seemingly) all possible directions. It can manage and archive both synchronous and asynchronous channels, integrates with things such as (but not limited to) mailing lists, IRC, BigBlueButton, git. I have set up a test organization², but apart form signing up relays to our official mailing lists (guix-devel, help-guix) I have not used it much yet; though it looks very promising. It promises integration through email and mailing lists so users who don't want to use a web-interface can still contribute via email. It could allow us to (relatively) easily adjust our communication channels as needed, enabling teams to form spontaneously. What Do Y'all Think? Just the best gabber ¹ https://zulip.com/ ² https://guix-test.zulipchat.com P.S. The IRC bridge does not seem to work for the official zulipchat.com instance, or maybe I'm missing it?
