On Tue, Jun 30, 2026 at 12:37 PM Maxwell G <[email protected]> wrote:
> Hi, > > On 6/30/26 11:42 AM, Brendan Conoboy wrote: > > Thoughts inline below.... > > > > Brendan Conoboy / Community Linux Engineering / Red Hat > > > > On Tue, Jun 30, 2026, 8:23 AM Aoife Moloney <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hello everyone, actual Change Wrangler here so I thought I'd weigh > in :) > > > > Couple of questions I'd like to understand: > > > > 1. How has the current change process poorly impacted you? For > > example, are you a change owner who disliked X or Y? Are you a > > driveby contributor who doesn't like the devel/discourse split? Are > > you a FESCo member who needs more of A or B in the voting ticket? > > > > > > As a manager at Red Hat I can share a few things that I've observed > > indirectly. This isn't the same thing as a primary source, but as a > > change agent inside Red Hat, I've spent some time thinking about these. > > Thanks for your feedback! > You're welcome. By the way, I really appreciate how proactive you've been since joining FESCo, it's great to see. > From my perspective the things that make it to and fit within the > > boundaries of the change process work pretty well. Nothing is perfect, > > but it works on the whole for the Linux distribution. Here's what > > doesn't work: changes that fit poorly inside existing processes. And to > > be clear, nothing is an outright disaster, we all talk things through > > and get to a good place eventually, but it could be a lot better. > > > > Some recent examples in my organization include: > > > > > - 2FA for all packagers: My team was working on a proposal when FESCo > > invented a lesser process for the change scoped to proven packagers. We > > assumed the full formal process was needed, but when contemplating > > something similar, FESCo choose a simpler path. We would have engaged > > sooner if we'd known there was a lower bar. > > I don't think that's an entirely fair characterization. We didn't invent > anything. FESCo made a small change to the existing provenpackager > policy after an extensive discussion on the list, using the normal > process for policy changes, that ultimately only affects ~50 users. As I > understand it, you are proposing a much larger change that affects the > entire packager community and requires Infrastructure changes to enforce > the proposed new policy. If your team (or anyone else!) wants to engage > on a topic before a formal Change proposal, posting to the devel list is > very welcome. This is exactly why I brought up the idea of pre-Change > feedback at the start of this thread. > Ah, words failed me here. I mean only that FESCo chose a path other than the documented change proposal path. I like your pre-Change feedback idea. It shares some commonality with the broader thing I suggested to Aoife. More on that below. > > - The AI Developer Desktop initiative. Council seemed like the right > > place to start because we wanted to have clarity on strategic priority, > > but elements of the proposal were arguably in the domain of FESCo, the > > broadly-scoped AI/ML SIG, and so forth. At least part of the friction we > > all felt was because those interests wanted to be consulted > > specifically, before invoking a Council process. > > I think that proposal hit a lot of pain points, some of them procedural > and some social/political. As for process issues, I think there was an > unintentional Council communication breakdown that unfortunately created > a tense situation. The Initiative should not have been approved without > Council interfacing with bodies (FESCo/FPC) whose policies the proposal > violated or without clearly announcing when it was being voted on as an > official proposal (as opposed to when it was a draft/idea). In any case, > that proposal was not a Change Proposal, but rather a Council > Initiative. I believe that Council is currently going through its own > process to change/reform the Initiatives process. > Yes, we knew the subject matter was controversial, and it seemed that following a documented process would provide a better framework for constructive feedback. Perhaps it did? In any case, a normalized the pre-Change socialization activity would probably have helped get FESCo engaged. Many years ago when we were working on the ARM architecture FESCo provided a checklist of concerns about a primary architecture push. Not a promise of approval, just the goalposts they thought would be important for the ARM team to cover. This is at least part of how I think of your pre-Change idea. Early guidance takes work, but it makes voting easier, and there's less friction for everybody. > Which leads back to: the current process is good for FESCo distro-change > > processes, but change process as a whole across the community needs > > work. The bar to clear to initiate change in a way every interest feels > > respected is tough to such a degree that even initiating a conversation > > is fraught. > > Hmm, that perception concerns me. I want people to feel free bring up > ideas and do things in Fedora. > Me too :-) > 2. What level of involvement do you have in processing the changes, > > and what parts do you find taxing? Eg are you a change owner who > > doesn't enjoy interfacing with the wiki? Are you FESCo member who > > finds the tickets less than optimal to review? Are you QA who needs > > better tracking of changes, etc. > > > > > > The mailing list/discourse split is a source of significant strife in > > the community where changes are concerned. Prior to a series of > > unfortunate events, there was a tentative agreement to move the devel > > list to discourse, but that was interrupted by the loss of Ben and we've > > never gotten back to it. > > I have never heard of such agreement. I don't think there was ever > consensus amongst the community or a public FESCo proposal to make such > a change. > That's my read of where https://lists.pagure.io/archives/list/[email protected]/thread/Z2T5WKUTHNLS2SVCVAWNYYRIBK3NGF32/#KFNQOQUD22M73YZ2OVLWU3B6O5RCM2K7 ended up. > 3. What would a brand new process bring the Fedora Linux > > distribution that our current one does not? > > > > My professional opinion is that many elements of the change processes > > should be delegated to the bodies who are expected to follow them, while > > a centralized system could be created for vetting and routing. > > > > Saying it is one thing and doing it is quite another: it can go *very* > > badly if not well managed. This requires things like minimum standards > > all delegates must follow, as well as competent quorum for central > dispatch. > > > > In my mind central dispatch would be composed of the chief change > > wrangler, an additional council member to represent council, a FESCo > > rep, a SIG rep, etc. And the community in general, because the scope of > > change varies, such is its nature. The goal for central dispatch is to > > streamline change, inviting people to the right places, and check on > > follow-through. > > That sounds like a large expansion of the current scope of the Changes > Process which I worry is too much administrivia for the majority of > Changes that go through the process. I also think that some of the steps > you're proposing already happen as part of the current process; they > might just not be super visible. SIGs are already often involved as > Change Owners. The Change Wrangler along with FESCo already keep track > of the status of proposed Changes (that's why we have the Changes > Bugzilla tracking bugs). As for a Council representative, the technical > Changes Process falls under FESCo's authority, so I'm not sure what > their role would be. We already have the FOA (as the Change Wrangler) > and a FESCo Council representative involved, so ideally one of them > would convey any messages about Changes to/from Council if needed. Re. > having a dedicated representative from FESCo assigned to each Change, I > worry that would be too onerous (FESCo is a volunteer body) and not > necessary for many Changes. We do already have the option to appoint a > Change Shepherd (this can be a FESCo member or not) for Changes where > this is deemed necessary. If you/your team is working on a Change and > feel a Change Shepherd is warranted, please do ask. > You're thinking about this as a FESCo member who initiated the conversation, which is totally logical. I'm thinking about it in response to Aoife as the change wrangler in chief and the project as a whole. To me, as a person not involved in its day-to-day, the FESCo change process is a phenomenal success. But changes that happen outside of its scope don't always do so well. Since Aoife put the followup questions out there, and I had thoughts specific to her questions, that's where I was coming from. For your original proposal, I think the pre-change idea is good, and that split between discourse and email is bad, but don't feel like I'm active enough in FESCo-oriented changes right now that my feedback on the particulars of your proposal to be well informed enough to share. > In such a situation, OP's straw man might be fine for FESCo, as long as > > it met the minimum standard defined by the central body. > > I don't follow. Can you clarify? > Sure, I was thumbs0typing before a flight yesterday, but now I'm home and can use all 10 fingers so I can elaborate. Change management is hard, there are so many details in its execution that doing it well can be a lucrative profession unto itself. We all want to respect people's time, limit overhead, and create systems that feature a high degree of autonomy. We also want the thing to consistently work. Currently the change process works, in no small part, because a dedicated person oversees it. If that person were to "level-up" into a broader overseer of all change in Fedora, they wouldn't have as much time to oversee the particulars of the FESCo process. We already had a taste of this with the FOA being on leave for a while, and even with Allison covering, we're all glad Aoife is back because Aoife is awesome. focused, and catches things that might otherwise be missed. In the absence of a dedicated change wrangler for FESCo topics, it would fall to FESCo to manage change itself. In effect, the FOA would be delegating change wrangler status to FESCo, or perhaps a member of FESCo. In that circumstance, you'd want there to be some minimum standards that the delegate must follow. That's the idea. This is theory of course, but it's something I suspect the project would benefit by overall, if pursued. > Distribute announcements, centralize early discourse and target details > > discussion. Make it clear what stage the change is in. This will make > > it easy for community new and old to productively participate, and I > > think everybody will win. > > Yes, I think we have mostly the same goals here. > Absolutely! -- Brendan Conoboy / Community Linux Engineering / Red Hat
-- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
