Hey Guix. There's a specific thing I'm motivated to address after the recent security incident with the "cosmetic" patches & all the fallout of that.
In one of the comments that lead off that thread, Mark asked "does anyone else find it worrisome that Raghav has commit access?" I speculate this comment may have predisposed some people to read subsequent comments from Mark as harsh or suspicious. I distinctly remember reading that message and thinking "oh Mark is not amused." I'd write a message like that if I'd already tried privately to resolve a person's practices and they'd been resistant, causing me to give up on them and leaving me feeling little choice but assuming bad faith. I don't know what history the participants in that incident had with one another, I don't follow the list or know everybody well enough to have any knowledge or good guess. One way or another, part of the subtext I got from that thread is that Mark, an established and respected senior contributor here, believes making an error like the one Léo and Raghav made is beneath the level of somebody who's entrusted with membership in the committer group. That reminds me of a common attitude I've seen in operations at a lot of companies, that ops are heroes who take their duties very seriously and feel an extreme responsibility to follow procedures and avoid using their power destructively. That attitude is a liability at any organization, because we're all fallible and guaranteed to fault on occasions, but I think especially so in a high-trust inclusive atmosphere like what Guix has been building. I noticed that Léo joined, got really engaged with improving the software, and was quickly accepted as a committer, which I thought was really cool. I haven't applied for commit access myself yet, both because I have anxiety about acting out of line and thus want more time to learn the norms of the community, and also because I feel reasonably at ease with the tools and processes for non-committers to contribute. But I saw that and thought it was a great sign that a committed contributor like Léo was able to gain the group's trust so quickly. It's a strength and would be a shame to lose that. But if everyone who's entrusted with commit access is also expected to live up to the heroic responsibilities of the classic ops/sysadmin role, then I think we're setting people up for failure. Ops at the best companies are guaranteed to make mistakes, and they have the cultural training to be Very Sorry about it and Learn Their Lesson and so on. But how do we expect every committer to a volunteer open source project to behave that way? Blaming a volunteer for a bad commit, calling them out on the mat to fess up and say they're sorry, is big "blame the intern" energy and it's ultimately not conducive to our security as an organization. I think that's still true even if you assume good faith and use only factual statements throughout. It felt to me like Mark was expecting (demanding?) a certain cultural performance from Léo: acknowledgement of what was done wrong, contrition for his part in it, and a promise not to repeat it. This is typical in ops organizations, but it's not necessarily humane, and I don't think it's a reasonable expectation in a volunteer project. A reexamination of the hero culture among the Guix developers might be in order to avoid similar confrontations in the future. What does it look like to step back from hero culture? One tool I've used working for paranoid security organizations is to require at least two signatures/sign-offs on any merge to a "protected" branch (like master or core-updates,) one of whom has to be part of a "security ops" subgroup who take on responsibility of this extra review. This pratice works on the simple acknowledgement that any given committer is fallible and two heads are better than one. It's impossible to know for sure, but I imagine this practice would have caught the mistake in Léo's commit to core-updates, and might have avoided a lot of anxiety. Some of Christopher Baines recent work on visualizing the impact of commits could also help aid this review task. I'd also be interested to see a mechanism for marking commits in the "protected" branches as vulnerable, such that "pull" and "time-machine" can give a warning (or refuse to use those commits.) This might make occasional bad commits less catastrophic and thus reduce anxiety, allowing us to maintain a safer git tree without having to rewrite history or maintain heroically high standards of judgment about every commit. Cheers, and an honest thank you for everybody's thoughtful messages this past week! Ryan
