Hi Gabriel,
thanks for taking initiative on this topic! Gabriel Wicki <[email protected]> writes: > 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. clear definitions of roles and expectations are always a good idea imho! > 2. We add another mailing list, that we expect committers to read before > pushing stuff to master. I don't think that yet another communication channel would be an improvement, especially if the issue is people not following communication channels closely. Adding another one probably won't improve the situation. > 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), What would the benefit of per-team mailing lists over codeberg issues labeled for the respective team and discussions on guix-devel be? I think all relevant information should end up in one of these two. > the archives are not as easily searchable as they should be What's missing? afaik there's a simple web interface https://lists.gnu.org/archive/html/guix-devel (and https://yhetil.org/guix-devel as an unofficial mirror) allowing to search for things. If there's the need for a more modern UI, I like what the Fedora project is doing with their mailing lists by providing HyperKitty as an interface to their archives: https://lists.fedoraproject.org/archives/ and it seems like HyperKitty itself is already packaged for guix as python-hyperkitty. > (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): Having a devel mailing list and an issues tracker already is quite centralized in terms of communications. > 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 don't know if Zulip adds anything for me personally as it seems to be a web client for things I'd prefer not to do in a web client. However, as it seem to integrate well with a lot of things, I can see how that lowers barriers in participation which is always a good thing, I don't see myself using it though. -- Kind regards, Wilko Meyer
