On Tue, 28 Jul 2026 08:31:57 -0400 Christine Lemmer-Webber <[email protected]> wrote:
> > I know this was an especially long and hard process that consumed an > > unbelievable amount of resources. I hope we can circumvent the > > waste of many of these resources in the future, for I am convinced > > that we could use them more wisely and sustainably. > > Which is it? That we need more time, or that it is too many resources > used already? We don't have only time as resources. How nerve wrecking the conversations are drains people too. And huge chunk of time right now isn't the same cost as lot of small chunks over longer period of time, and the cost can change from person to person. So my question is if we can find ways to offload as much as possible of the costs in other processes that are not as nerve wrecking as this one. And also how can we make as much as possible of the process fun? If we're not pressed by time, working on documentation can be way more fun (and even addictive) than shouting at each other in a very polite way. Parliamentary republics have commissions that can make reports on topics (like LLMs) for instance and as we have scarse resources this could be reused later on for the application of a GCD for instance (example: cited in the manual for legal or practical topics that need to be taken care of). And here we wound't have to wait for GNU for guidelines and they'd probably take inspiration of our work instead. Also, looking at Debian, there is a Debian developer onboarding process. This at the same time prevents a takeover of Debian and also makes sure that people do have or get a baseline knowledge on topics like free software, licensing and so on. Both are required to not put the Debian project at risk. And both are a requirement for discussions like the GCD 008 (how much we need to keep things legal would be covered already for instance, so people could still put that in question but they would really understand such decision). I've no idea if Debian processes are sufficient (they decided to not decide on LLM last time, and the systemd discussions had issues) but we can at least learn from them to fix some of the issues we have, and hopefully have some process that even Debian can learn from as we would also have learned from them. > I have a sense that part of the challenge you may be having is with > the GCD process itself, and possibly as a governance process that is > happening within Guix and not specifically as coming from GNU. Is this > the case? I think that Guix became quite big. And we lack some of the process of big distributions like Debian. Many GNU projects look quite small in comparison, and the maintainers are responsible for many things that in Guix are handled by teams, and teams members are not maintainers in the GNU sense, and probably don't feel these responsibilities. Most of them are also not distributions. For instance https://www.gnu.org/prep/maintain/maintain.html isn't a requirement to be part of a team. In fact there is not a lot of requirements for being part of a team. So GNU and Guix need to adjust to having big projects in GNU I think. And I think that GNU also has a lot to offer as many things are documented, handled well in GNU, even if not everything is (nothing is ever perfect). And this helps both small and big projects as we don't have to reinvent the wheel for many things (there are manuals for legal topics, coding standards, how to manage project, the ideology enables to get contributions from companies while staying independent, the infrastructure cost is low, etc). So personally I see Guix more like a youth wing of some bigger political organization that can push for changes, more inclusion, etc, and that has some interesting things to bring to the table but also things to learn (processes to add) to avoid issues that are also avoided on more historic projects (that also come with a huge knowledge about many topics). Both combined would probably yield many really neat results, and this is also how movements evolve over time, by keeping what we have and improving it rather than restarting from scrach and not learning the lessons of the past. And we need to learn from everywhere we can and try to really understand the consequence of a process (the good and bad parts of it) instead of copying it blindly. And maybe process failures also comes from the fact that there are no decision process nerds in organization that have these failures. It seemed to be a problem that was apparent in the panel about decision processes in last FOSDEM in the legal devroom (though I wanted to ask a question about that to make sure it was the case but I didn't manage to). > Because if this is true, this kind of objection means we have a > situation in which the GCD process altogether cannot succeed. The GCD worked really well for smaller decisions like with master/main, so we need to recognize that. And I would not put every eggs in the GCD basket as the GCD itself cannot solve all the problems in the world. The construction of a document also went pretty well for this GCD 008, even if it's not completely finished in my opinion, and yes the decision process was nerve wrecking and put in question, but I think we should rather try to understand what worked and what didn't and promote the former and fix the later. To be clear the fact that as a new contributor you can use LLMs (with some limitation) and cannot use it anymore once you join a team is really neat, and it is consistent with conservancy guidelines. So with that we get new contributors and help them be more autonomous by getting rid of LLMs for generating code/data. Are we the first that came up with this idea? If so can we recognize that? And can we at least preserve the process that enables us to get ideas like that? This is like copyleft for LLMs where we turn LLMs against what they bring with them (lack of autonomy, etc). > What *is* the alternative? Are we in a de-facto moratorium on genAI > contributions until a GCD in the positive is reached? Or is it free > reign? The short term alternatives are much more complex and we end up with logical problems (see below). As for the longer term alternative, I think we need to improve the processes in Guix, not just the GCD, and I hope this could also remove the objections there were with how this GCD went. An idea could be to have a lower cost GCD process, especially for the people that want to push a small fix? For instance can we propose something, and directly vote on if we want to vote on it, with obviously a quorum required? And then once people are in favor, discussions would start? This would enable people to decide to not vote on a GCD 009 if they don't feel ready for instance. There would then be complete clarity that this will not be voted at the end. We could also allow votes for time extensions as well, ideally with very clear reasons or focus (go look for that info, cool down if people do respect the cool down, etc). This could also be done at the end, where we'd vote for yes/no + time extension or not to not have this "feature" cost too much time to people. > Many people poured themselves into it, and it's difficult to see how > the situation will do better. In any case we cannot go back in time but we can learn and adjust. Also is there only 1 person that wants that GCD declared invalid (which is different from voting for or against the GCD)? And personally I'm in favor of the GCD being valid and also to learn from what we did as a way to fix our collective wrongs and also recognize what we did well. Gabriel, would that fit well to you? What would you like to be done in the future to fix the issues we had during the process of this GCD? And do you think that we could makes things okay by fixing our process for future GCDs? Another option would be to have enough people that come forward that want it declared invalid, enough to be the majority and that would win a GCD if it was made, the majority probably wants the GCD to be valid. This would challenge only the validity of the GCD 008 and nothing else. So remains potential objections on the content of the GCD I guess, but there are also process both within (a new GCD *later*) and outside of Guix (the press, GNU, etc) to challenge that, and I didn't feel that the content was seriously put in question here, more the process. But for the sake of the argument, as it is questioned, let's see what happens if this GCD is declared invalid. If this GCD is invalid, we would have to re-do the process, but this is costly, and most voters probably don't want that. I don't. And the question is also if the process issues really did influence people to vote against what they wanted to vote in the first place. In my case It didn't, but I can't speak for others. And this is also important for legitimacy I think. Re-doing only the vote won't change anything since it would be the whole process that is questioned here: that would be invalid as per GCD 001, and so some people could also question that. And GNU cannot magically solve the legitimacy either here: the GNU moratorium on LLMs is also supposed to still be in place but we also had feedback from GNU on what they are doing and what we did, so it's not even clear if this moratorium still applies to Guix or not because the feedback from GNU isn't clear apart from the fact that at some point in the future things will be OK, so this isn't a way to decide either. We could also apply both, like wait for GNU's guidelines to apply GCD 008, but here people could also object I guess as GNU's feedback isn't clear on what we should do now either. If we ask GNU what to do instead, it could work in theory but people would still need to accept the decision anyway, so that brings back to the same issue of legitimacy. And the question is also if GNU would even want to do that or if they should do it, as it would put a lot of responsibility in the shoulder of a bigger organization that didn't participate in the discussions we are having, so that might not be the the right way of interacting with GNU. And here again there is the question of legitimacy. So if this GCD is invalid, there are no clear answers, so we would need to look for them. A way could be to let people that are not OK with GCD 008 passing speak I guess. Though, we still need to reflect on what happened and how to improve things too I think. Another option if things are is still confrontational, could also be to try to calm down and discuss all that in person, ideally with group mediation before the discussion, and try to find solutions together, which mean wait for a solution. And/or we could do a really fast GCD to postpone the discussions until September / October so we could have these in-person meetings to try to find a solution out of this mess. And I hope that here we can rather come with a process that makes people retrospectively happy here rather than doing more confrontation. So maybe the best way to deal with all that could be to try to discuss about what went on and propose modifications to processes in Guix in the longer run. And we really need to do that. And have in person discussions as well for that. I'm not sure how to call that but it would not be technical-debt but something like social-debt we'd be accumulating if we don't do it. > But I fear instability in the face of not having achieved consensus > on this document, if that is indeed the outcome we seem to have > achieved. And I wonder what it means for any future GCD. It is a > particular risk if the perspective from one member that the process > itself is a waste of time can manifest the process into being a waste > of time. That, certainly, would be poor for everyone. I also agree very strongly here. If different people apply incompatible rules and are confrontational about it (so it's not accidental), then this indeed leads to confrontation and this is also bad and at the end it would force us to decide, but probably we'd be in worst situation than now as we'd have more tensions. So the main issue here is really that. Before this GCD we had consistency as per GNU moratorium but this also needed to be made more public, more documented, etc, or put in question, which would push GNU to make it more public, more documented, etc. If this GCD is invalid them we have consistency issues and we are probably in a worse situation than where we started. Though we'd still have helped other projects learn from our GCD. And I think that there are other inconsistencies as well in Guix related to not breaking things and removing broken things, so this could also combine with other tensions. Denis.
pgpIgtbXiRpIN.pgp
Description: OpenPGP digital signature
