There are, indeed, technical solutions to social problems

1. "Richard W.M. Jones noted that there were times when a group of packages needed to be updated together and it was not feasible 'to go through a months long asynchronous process where every package is a special flower'. Jones said that Fedora needed 'a bit less ownership and a bit more shared responsibility with packaging' and that packagers should just try to do the right thing."

2. "provenpackager" status exists specifically to override this sense of ownership, apparently without requiring second-person review from another provenpackager.

3. "Stephen Smoogen said that Robinson can be difficult to deal with at times, but that his work was in service of the parts of the project he has been given charge over." The actual email is harsher: "Yes, Peter is hard to get along with at times, and yes he can be brusque, pushy, and grumpier than any mule or cow I have had the 'pleasure' to work with, and I have been at the tail end of his tongue multiple times over the years in Fedora. Yet in all those years, I have also known that his work has been in service of the parts of the project he has been given charge of, be it architecture or package sets."

It seems like the community has ended up in a situation where individual package maintainers are encouraged to have an expectation of ownership and control over their packages, the project as a whole also has an expectation that certain trusted people will unilaterally override that ownership and control for the sake of forward progress in the project, and one of the people who has most beneficially exercised that ability (from the point of view that the exercise of that ability is a good thing) is someone who is unpleasant to work with. I don't think it's surprising that this would have blown up at some point.

In particular, given the simultaneous expectations of individual ownership and provenpackager overrides, the project has essentially engineered a situation where the most effective provenpackagers, the ones who most accomplish the goals of having that override capability, are the ones who are most willing to disregard other people's feelings and preferences and make opinionated changes. Someone who cares very much for respecting the preferences of the individual packager and working with them is simply going to exercise their override powers less.

Indeed, someone who is very effective at this interpersonal work probably doesn't need provenpackager status at all; they can just send patches or convince the maintainer that they can be trusted as a co-maintainer. (If the maintainer is unresponsive, this doesn't work, but that can be dealt with by a process that only applies to inactive maintainers, e.g. a shorter timeout for a maintainer to be removed and replaced, communicated clearly up front when someone offers to be a maintainer. The situations discussed in this article seem to be about provenpackager changes to packages that aren't unmaintained; e.g., the FESCo statement about "other maintainers being forced to react to these changes" implies that those other maintainers exist and are active enough to need to react.)

I think that if you have a social community where the most effective people are also the rudest and hardest to work with, you should rethink your community structure and how it got to be that way. To be clear, I don't think that rudeness or difficulty is an immutable characteristic of a person; your community may simply have told people who are capable of many interpersonal approaches that the effective approach is to be rude. I wholly agree with the point at the end of this article that the real issue here is about the provenpackager status and not about the individuals, and that Fedora (and Debian, and other projects) would benefit from rethinking them. Among other things, that same rudeness is probably dissuading new participants, and if you had more participants and a process for making the individual commitment lower, you wouldn't need the structures that lead to high-stakes conflict.

One specific technical thing that surprises me is that provenpackagers have access to commit without review. This was how we commonly did software development in the CVS/SVN days, before we had DVCSes that allow commit objects to be created but not applied to the mainline. I recall a number of upstream communities where getting access to the "commit bit" was an onerous and high-stakes process, and also where fractious disagreements arose from people making unreviewed commits that others didn't like. With the rise of GitHub and platforms with similar workflows, those problems don't seem to have scaled up proportional to FOSS development itself, and I think that's because the technical model both prevents an individual maintainer from acting unilaterally (if you require review for all changes) and also lessens the distinction between a maintainer and an ordinary contributor and so reduces the need for that level trusted access. (Another technical change that has worked for the better is CI that runs as part of a pull request or merge train; you don't need to argue about who broke the build, whether you should have tested on a specific platform, whether you conformed with style requirements, etc. if there are bots that enforce these for you and the configuration of those bots is expressed in code that can itself be changed by a normal pull request.) I assume Fedora's practice here predates the conversion to Git and I think this would be one of the first things to rethink.