FESCo provenpackager sanction causes problems [LWN.net]

By Joe Brockmeier
December 19, 2024

The Fedora Engineering Steering Council (FESCo) has made a series of missteps in deciding to revoke a longtime Fedora contributor's provenpackager status. FESCo made the decision during a closed session, based on private complaints. It then publicly announced its decision, including the contributor's name, while only supplying a vague account of the contributor's actions. This has left the Fedora community with more questions than answers, and raised a number of complaints about the transparency of FESCo's process. In addition, the sequence of events has sparked discussions about package ownership, as well as when and how it's appropriate to push changes to packages that a developer doesn't own.

Package ownership

Sources for Fedora packages are currently hosted using Fedora's Git forge software, Pagure (though it is due to be replaced by Forgejo in 2025) at src.fedoraproject.org. The packages are managed using Distribution Git (dist-git), which is basically a Git implementation with additional data storage designed to hold content of source RPMs.

In Fedora, packages are typically owned by a maintainer who has packager status. This status is not granted automatically—users have to have a sponsor and learn the ropes to be added to the "packager" group. Once added to the group, they then have the ability to commit changes to the repository for packages they own. Then the package can be submitted to Fedora's Koji build system to be built for a release. Each package repository has a branch for each release that the package exists in, so a package might have f39, f40, f41, and rawhide branches for Fedora 39 through Fedora 41 and Rawhide, for example.

There are many scenarios where packagers may wish to modify packages they do not own. For example, when a person is packaging an update to an application they may need a newer version of a library it depends on. If the owner of the library package has not gotten around to updating it yet, it can be inconvenient to wait for its maintainer to make the update. This is a common scenario in a project where some contributors are paid to work on packaging, while others are volunteers who check in infrequently as time allows. Anyone can submit a pull request (PR) to modify a package, even if they aren't a Fedora packager at all, but only the maintainer (or co-maintainers), can commit those changes.

One exception to this is if a person has provenpackager status. The members of the "provenpackager" group have rights to commit changes to packages they do not own or maintain. To gain this status, a packager must submit a ticket to FESCo requesting the status and must receive at least three affirmative votes (and no negative votes) from provenpackager sponsors. For perspective, the list of packagers includes 2072 users, while there are only 156 members in the provenpackager group on src.fedoraproject.org.

Revocation

The episode began (at least publicly) on December 13, when FESCo member Josh Stone sent an announcement to fedora-devel that stated FESCo voted, after a private meeting, to revoke Peter Robinson's provenpackager status. Robinson has worn many hats within the project over the years, including a stint as part of Fedora's release-engineering team while employed by Red Hat. He has served on the now-defunct Fedora Board and its replacement, the Fedora Council. He left Red Hat in September and currently maintains more than 120 packages in Fedora as a volunteer. Stone wrote that multiple tickets had been opened with FESCo, privately, regarding Robinson's "packaging behavior":

In particular, on numerous occasions Peter has pushed uncommunicated updates to packages he has no prior relationship with, interfering with those packages' maintenance efforts. On at least a few occasions, this has resulted in other maintainers being forced to react to these changes with no coordination or notice.

The statement claimed that FESCo representatives had several conversations with Robinson and they had issued warnings to him, but he had continued to "use his provenpackager privileges in an unapproved manner, frequently causing additional work for other maintainers". As a result, FESCo had voted that his provenpackager status would be revoked, though he would still retain packager status. Stone said that the vote to revoke the status was seven in favor, and two against—but did not note how the individual members had voted.

People were quick to respond to the announcement with questions and requests for additional information. Gary Buhrmaster said that, to be transparent, FESCo should provide the specific conduct that led it to make its decision:

Facts are facts, and should not be in dispute, nor hidden from the community at large, should FESCo wish to maintain the full trust of that community.

Dominik Mierzejewski said that FESCo should supply an "exhaustive explanation with a compelling justification" for revoking Robinson's status, and to supply individual FESCo member votes before the current election closes on December 20.

FESCo member Fabio Valentini replied that FESCo had agreed to provide a public ticket with a summary of its deliberations "it just hasn't happened yet". That led others to wonder why FESCo had announced the decision before having the public ticket at the ready, and suggest that FESCo should hold back such announcements in the future.

First time

Valentini eventually responded that FESCo was still "coordinating internally" about supplying more information publicly. He prefaced his response by saying he was only speaking for himself, not all of FESCo. He reacted to some of the criticisms by saying that this was the first time that FESCo had been asked to revoke provenpackager status, so there was no process for doing so. As for timing, he said that the date of the announcement was chosen to be shortly after the decision was made and before FESCo members were offline for the holidays.

Robinson himself spoke up to say that the public announcement provided more "openness and transparency" than the email he had received personally from FESCo. (He linked to a screenshot of his reply to the email on Google Drive.) He said that none of the changes he has made to packages were meant to be malicious, but were made to improve the project and fix "actual problems users are experiencing".

He said that he had not been aware of any of the tickets that had been opened with FESCo, and could only remember one conversation with a FESCo representative about a change that he had made to the dav1d package, a cross-platform decoder for the AV1 codec, maintained by Valentini. In that conversation he had agreed that he should not have updated the .gitignore file in the repository, but that it had been done "without malice". Robinson added that the other changes to the package were made "using my architecture maintainers hat" in an attempt to solve numerous complaints about performance of video codecs on aarch64 for devices that do not have hardware acceleration.

Robinson's response also alluded to a history of disagreements with Valentini over maintenance of other packages. He questioned whether FESCo's process was unbiased, given that Valentini had been involved in the discussions and vote to remove him. "This feels like a kangaroo court to me." He said he looked forward to FESCo providing details of its conversations, since he had not received a reply directly.

"Broken trust"

Former Fedora Project Leader (FPL) Jared K. Smith expressed surprise "that this would happen with so little communication with Peter, and in such a public manner". He said he'd known Robinson for more than ten years, and always found him helpful and had not known him to abuse provenpackager privileges. People-related complaints always require a certain level of privacy, but "this doesn't pass the sniff test".

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. Of the many people who had used provenpackager privileges in problematic ways, Robinson was the person he thought least likely to be dropped from the group. He hoped that those matters would be dealt with in a public setting in the future, or that information would at least be published before judgment was announced: "There have been a lot of things in the past that tested my temper in Fedora, but this is the first thing that has truly broken my trust." Simon de Vlieger also wanted to know why FESCo chose to publicly name Robinson in its announcement, and said it was "unnecessarily harmful".

Vit Ondruch was one of the few who spoke up in support of FESCo. He replied to the list with Robinson's commit to the Ruby package, which Ondruch owns, in 2014. Robinson said that it was when he was one of two release-engineering people working on Fedora, and the package was likely blocking the building of release artifacts. The example was not, he said, relevant or useful since a lot of things had changed since that patch was committed.

Ondruch replied with more detail, saying that Robinson's changes—including renumbering patches in the RPM spec file—were more than needed for part of the release process. He said he would "love to believe that this is a relic of the past, but some of the recent discussions" on the list did not support that. He did not elaborate about which discussions, and a quick search through recent fedora-devel discussions does not turn up any obvious examples. Given the age of his example, it's possible that his definition of recent extends farther into the past than one might expect. Ondruch also complained that Robinson didn't include "something like 'sorry'" for the decade-old offense so that "we could move on".

FESCo apologizes

FESCo member David Cantrell replied to the thread on December 16, and issued an apology on behalf of FESCo "for how we communicated the news". He said it was difficult to figure out how best to communicate "and we have made mistakes" by failing to make the facts available quickly. In some cases, he said, FESCo was dealing with situations where reporters wanted to remain anonymous.

He said that FESCo was "currently assembling" its facts so they could be shared publicly, but first wanted to discuss it with Robinson. FESCo is also discussing revising the provenpackager policies and its policies for handling situations related to provenpackagers. He reiterated that it was the first time FESCo had been asked to revoke those permissions.

Adam Williamson said that it struck him as problematic that FESCo was allowing anonymity in the process:

This is essentially a technical/process dispute, right? I see no indication that Peter has been accused of a particularly heinous crime or a CoC violation or anything like that. I'm having trouble seeing how anything that doesn't rise to that level could warrant a process involving anonymity for 'reporters' and behind-closed-doors FESCo discussions.

Valentini muddied the waters further by saying that none of the parties requested anonymity, but FESCo could not simply make the ticket public "because it also references a [Code of Conduct] (CoC) issue which *is* private and cannot be shared". Daniel P. Berrangé said he was surprised about the mention of a CoC issue, since that should be handled with confidentiality and by the CoC committee rather than FESCo.

FPL steps in

Current FPL Matthew Miller stepped in on December 17 to say: "Several things went very, very wrong in all this."

If the Proven Packager guidelines are ambiguous enough that different readings of them can lead to conflict this strong, we need to clarify them and make sure we have consensus on the [conferred] powers and duties.

In any case, FESCo should not be [adjudicating] Code of Conduct or behavioral allegations, and FESCo actions must not be used as a "shadow" CoC enforcement mechanism.

Miller said that he was not sure what needed to be done to make things right, but that Fedora's Council—which is Fedora's top-level community leadership body—would be working on immediate actions before the holiday, and longer-term actions in January.

Valentini, having been the one to drop the CoC comment in the first place, complained that he didn't understand where the idea came from that "this was basically a CoC issue that was raised to FESCo [...] it's just not true". He said that FESCo is not usurping CoC responsibilities, and the CoC mention was "only a minor side note" that should not have been mentioned at all. It is, to date, still unclear where CoC complaints factor into this situation, the nature of any complaints, and if Robinson was the subject of those complaints.

On December 18, Miller provided an update, saying that the Fedora Council had met to discuss the topic and had asked FESCo to put its decision on hold while the council investigates. The council would compile a report of what happened and when.

This is going to take some time (and would even without the holidays), and I appreciate your patience. The specific situation connects into broad questions about what "proven packager" should be — and even bigger ones about what it means to be a package maintainer in Fedora. I hope that we can improve how we collaborate and communicate overall. Once we have a full understanding, we will make recommendations on next steps, and possibly adjust Council policies.

Proven packager problems

Setting aside the personalities involved and FESCo's communication fumbles, this episode brings to the fore a common problem for community Linux distributions like Fedora and Debian. There is an inherent tension between individual package ownership and the collective responsibility and collaboration required for the entire project to work. Debian has had a number of discussions this year that have touched on ending single-person package maintainership, though little progress has been made in that area.

In the provenpackager thread, 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.

Berrangé agreed with Jones that the notion of package ownership could give rise to problems. He said that packagers should be considered custodians of packages, rather than owners. "Fedora owns the package, maintainers are looking after it on behalf of Fedora." Packagers have personal preferences, but they should put those aside for the greater good of the project. If someone is following Fedora procedures, he said, "that should be considered fine, even if it doesn't align with personal preferences".

The provenpackager guidelines, he said, are too vague and open to interpretation. It was easy to see how differences of opinion would arise from the non-specific guidance in the policy:

Prior to making changes, provenpackagers should try to communicate with owners of a package in bugzilla, dist-git pull requests, IRC, matrix, or email.

Do provenpackagers need to try all five communication methods? How many times do they need to try? "Combine that with 'personal preferences' and it is surprising there are not more conflicts seen." The policy, he said, should have a default method that is considered sufficient to satisfy common scenarios.

It is, to say the least, not easy to provide policies that balance the needs of the many and the few. A project must find a way to avoid demotivating or hindering volunteers who do the bulk of the work on individual packages, while still making it possible for others to step in as needed. Giving gatekeeping powers over packages to individuals is, perhaps, necessary to ensure that volunteers will take responsibility to ensure the work gets done. But the single-maintainer model that has evolved can be at odds with long-term sustainability, contribute to maintainer burnout, and leave a vacuum when a packager suddenly steps away.

Managing the disagreements and conflicts when they arise between packagers requires clear policies and skillful diplomacy. In this instance, both seem to have failed. The provenpackager policy leaves too much room for individual differences of opinion. It also lacks a clear resolution process, and FESCo's attempt to create one on the fly—behind closed doors—has gone poorly. One hopes that Miller and the council will be able to achieve a better outcome.

to post comments

Guidelines, schmuidelines

Posted Dec 19, 2024 15:43 UTC (Thu) by smurf (subscriber, #17840) [Link] (1 responses)

> in 2014

Owch. My gut reaction to this one is "Grow up already".

Seriously, this should have been ample reason to request Ondruch to recluse himself from the current discussion.

> The provenpackager policy leaves too much room for individual differences of opinion.

That is not necessarily a problem. I'd rather have a loose set of "use your judgment dammit" guidelines than a five-page straightjacket that leads to rules lawyering instead of finding a compromise.

> It also lacks a clear resolution process,

… which is the actual problem, methinks.

Fedora should put this sanctioning on hold, if not revoke it outright, until such a process has been somewhat-agreed-on.

Guidelines, schmuidelines

Posted Dec 19, 2024 17:52 UTC (Thu) by cuviper (guest, #56273) [Link]

> Fedora should put this sanctioning on hold, if not revoke it outright, until such a process has been somewhat-agreed-on.

The article already mentioned the hold request from the Fedora Council, and that's been done via <https://pagure.io/fesco/issue/3305>.

it's me, hi, I'm the problem, it's me

Posted Dec 19, 2024 15:49 UTC (Thu) by decathorpe (subscriber, #170615) [Link] (5 responses)

While I agree that this has been handled and communicated poorly, I am quite confused by some responses from the community, given that

1. both the policy around packager / provenpackager responsibilies [0] [1] and the documentation for what changes are OK to be made using provenpackager privileges are quite clear (and not ambiguous at all, in my opinion) [2], and

2. it is (for now) undisputed that both policies have been violated numerous times in this case.

All information regarding this issue are being (or have already been) forwarded to the Fedora Council, and I am confident their investigation will eventually confirm that the FESCo decision was justified (if quite badly communicated).

I am also disappointed by how some FESCo members' efforts (including mine) to calm the waters have been received on the mailing list, and were often just interpreted in the worst possible way: "we are working on providing more details" is not enough, "we cannot share everything yet" results in being accused of backroom deals, but actually mentioning *why* it's not as easy as just un-marking the FESCo tickets as "private" is somehow even worse.

I get that people are disappointed or even angry, but this looks like a situation in which *no* answer would satisfy some commenters on the mailing list.

Side note: I also don't understand why some contributors are so agitated about loss the of provenpackager status here - they are *special* privileges that should be used in *exceptional* circumstances, and which should not be needed for normal workflows. Also, losing provenpackager group membership can happen as easily as ... just not contributing to Fedora for six months (for which there *is* an established process [1, last paragraph]), so I am confused why this is apparently considered such a draconian measure by some.

[0]: https://docs.fedoraproject.org/en-US/fesco/Package_mainta...
[1]: https://docs.fedoraproject.org/en-US/fesco/Provenpackager...
[2]: https://docs.fedoraproject.org/en-US/fesco/Who_is_allowed...

it's me, hi, I'm the problem, it's me

Posted Dec 19, 2024 17:37 UTC (Thu) by hailfinger (subscriber, #76962) [Link] (2 responses)

Disclaimer: I don't use Fedora nor am I involved in this in any way, but I've seen similar situations unfold elsewhere. Enforcement action may be well-intentioned, but the (collateral) damage can be huge.

> I am also disappointed by how some FESCo members' efforts (including mine) to calm the waters have been received on the mailing list, and were often just interpreted in the worst possible way: "we are working on providing more details" is not enough, "we cannot share everything yet" results in being accused of backroom deals, but actually mentioning *why* it's not as easy as just un-marking the FESCo tickets as "private" is somehow even worse.

Try to take a birds-eye view on this: Some people in power make a decision, announce and enforce it. At the time of announcement/enforcement, they are not providing detailed reasoning nor transparency. People not in power fill the information vacuum with the explanation they think is most likely and start getting angry. People in power are still not providing transparency for reasons which can't be verified either. People not in power start getting angrier.

Something along the lines of "Trust us, we did the right thing, but we can't tell you our reasons (yet)" may be intended to calm the waters, but the only situation where this can even remotely work is parents taking care of very young children. If grown-up people realize they are treated like children, they get even angrier.

With adults, it's just politics. If elected officials can't justify their actions, the electorate will complain. Some officials have figured out that apologies go a long way in getting re-elected.

> I get that people are disappointed or even angry, but this looks like a situation in which *no* answer would satisfy some commenters on the mailing list.

A possible answer which may satisfy some commenters: an apology and a retraction of the decision until the reasoning can be made public completely.

Side note: If there is a process which may result in disciplining a person, that process should also afford at least a robust set of protections for the defendant. That's something which quite a few projects are lacking.

it's me, hi, I'm the problem, it's me

Posted Dec 19, 2024 21:43 UTC (Thu) by ttuttle (subscriber, #51118) [Link]

As a former young child, it didn't work on me either.

it's me, hi, I'm the problem, it's me

Posted Dec 20, 2024 0:33 UTC (Fri) by tchernobog (subscriber, #73595) [Link]

Very well said.

Additionally, the accused should be able to defend against accusations leveraged against them, before disciplinary action is taken.

I ask my kids "did you really hit your sister?" and "why?" before deciding whether to revoke television rights for the week. And sometimes accused and accuser swap...

Never mind adults and their complex courts of laws.

It's very hard to trust any process if even the accused is just shelled out punishment out of the blue fur something they don't feel responsible for. Would you trust your government if you had no hearing from a judge once being put to trial?

Even worse, supposing any accusations is founded, it takes away the ability of the perpetrator to learn from their punishment, instead than just righteously balking at the injustice that befell them.

FeSCO did not seem to hear the other side, met behind closed doors, had at least one person with a personal stake on the board that should have revised themselves, and publicly made an example of a person by publishing their full name publicly.

When all of this is wrong "trying to calm down people" because "it's a small punishment" is missing the fundamental point of social contract in a community based on trust among people.

it's me, hi, I'm the problem, it's me

Posted Dec 20, 2024 2:49 UTC (Fri) by AdamW (subscriber, #48457) [Link]

Well, what you should have done is get all your ducks in a row properly.

Don't remove PP status till you're ready to announce the decision (because someone may notice and trigger a mess). Don't announce it until you're ready to justify it. If doing that requires work to hide something that *really really* needs to be private, do all that work first. Peter's been a PP for more than a decade and he hasn't burned the project down yet, whoever he might have annoyed a bit. There was no rush to remove his privileges immediately.

Once you hadn't done that, the first response by FESCo to people highlighting the issues should have been the response Matthew and the Council eventually had to do instead: apologize for the errors, and announce that the revocation was being suspended while all the ducks were put in the correct order.

It's possible the decision is entirely justified. The problem is nobody outside of FESCo can judge that, and it doesn't seem like there was any legitimate reason to delay disclosure of the reasons for the decision beyond disclosure of the decision itself.

it's me, hi, I'm the problem, it's me

Posted Dec 20, 2024 13:06 UTC (Fri) by farnz (subscriber, #17727) [Link]

Fundamentally, no answer is satisfactory because it's all "we have private tickets, which you're not allowed to see, but trust us, they're damning".

There's an ordering problem here - first, you should have had the evidence ready to go public as easily as un-marking FESCo tickets as public. Second, probinson should have been granted read access to the tickets you're going to make public, and be given a chance to prepare his response - with you able to show via logs that he had indeed seen the tickets. And then, and only then, should you have made the announcement.

The trouble is that having done things backwards, you're in a bad place. You're effectively saying "trust us, our super-secret private information proves that you can trust us, but we can't show you it", and that's always a hard statement to make successfully, especially if people have emotional ties to Peter (friendship, for example).

There are, indeed, technical solutions to social problems

Posted Dec 19, 2024 17:12 UTC (Thu) by geofft (subscriber, #59789) [Link] (4 responses)

A few things strike me as contributing to an inevitable conflict:

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.

There are, indeed, technical solutions to social problems

Posted Dec 20, 2024 1:26 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (3 responses)

> 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.

This is not a Fedora-exclusive problem. Basically every internet community where "effective" has any sort of meaningful definition has exactly the same issue. There is nearly always "that one guy who rubs everyone the wrong way, but does good work too." (In my experience, the person does usually identify as male, but I'm sure female etc. examples can be found if you look hard enough. I use male pronouns for simplicity.)

The most common resolutions are:

1. Ban "that guy" from the community, and then argue over whether he should have been banned.
2. Don't ban "that guy," and then argue over the same.
3. "That guy" takes a hint and mellows out.

Most communities enter a holding pattern where (2) is the default answer right up until "that guy" manages to do something obnoxious enough to tip the moderators (or whatever they call themselves) over to doing (1) instead (frustratingly, this last straw often looks innocuous in isolation, which is why people continue to argue after the banhammer comes down). (3) is rare but probably does happen from time to time.

One other thing: Since I have no experience working with Fedora, I have no idea if Mr. Robinson really is "that guy," or if he just rubbed one or two people the wrong way once or twice (you are not "that guy" unless it's a long-term pattern of behavior and affects a lot of people). I do not want the above comment to be interpreted as a condemnation of him in particular - I'm just trying to describe a general trend I have observed in internet communities.

There are, indeed, technical solutions to social problems

Posted Dec 20, 2024 12:51 UTC (Fri) by k3ninho (subscriber, #50375) [Link]

Valorising 'technically effective' over 'socially effective', which is sometimes hidden behind ideas of meritocracy, is a real pain when trying to manage people and coalesce teams to be perform greater than the sum of the parts. The '10x individual' idea is a heinous part of this, too, because it puts lower responsibility to be (or reward for being) a good colleague and team mate on someone who's not good at that, while binding everyone impacted by this individual's choices to a status level where they have to deal with working code now and little-to-no documentation or discussion.

I understand that those things have rare excellent projects started -- but sustained requires collaboration from people co-laboring with you.

One idea with Merge Requests is to set the expectation that a MR which passes the test suite ought to be approved, but you present the changes to the team as a teaching session documenting why you chose the approach and made the MR's design decisions. Because people get better at what they practice doing, you get gains in technical communication ... by practising technical communication.

K3n.

There are, indeed, technical solutions to social problems

Posted Dec 20, 2024 18:00 UTC (Fri) by lkundrak (subscriber, #43452) [Link] (1 responses)

> I have no idea if Mr. Robinson really is "that guy,"

absolutely not

There are, indeed, technical solutions to social problems

Posted Dec 21, 2024 13:07 UTC (Sat) by smoogen (subscriber, #97) [Link]

I agree, and I apologize that my sentence about Peter has blown up about it. I was trying to be clear that I know he can be rough around the edges and it got away from me.

Guess it's time to vote

Posted Dec 19, 2024 21:34 UTC (Thu) by jdulaney (subscriber, #83672) [Link]

I haven't voted in a fesco election in years; clearly that needs to change.

Late to the conversation - this is key Fedora advantage

Posted Dec 30, 2024 11:58 UTC (Mon) by martin.langhoff (subscriber, #61417) [Link]

I've been a Debian and Fedora maintainer. And I've worked closely with Peter Robinson - some years ago.

Yes, provenpackagers cause some friction making needed changes fast, and any mistake they make gets amplified if the package maintainer of record has a strong sense of ownership. But that sense of ownership is in tension with moving things forward uniformly and quickly.

Fedora has it right – provenpackagers get sh_t done and most packages aren't unique flowers. I find this to be significantly better than Debian.

When I worked with Peter, I had this exact situation - every once in a while he'd fix something across a dozen packages, some of which I was the maintainer of record for. It was annoying, but it moved the ball forward every time.

In a few occasions, he made a mistake, so it was double annoying. I complained a bit, but the ball kept moving forward, so after complaining a bit, I helped mend the effort and... I didn't torch the person pushing for progress.