Thoughts inline below.... Brendan Conoboy / Community Linux Engineering / Red Hat
On Tue, Jun 30, 2026, 8:23 AM Aoife Moloney <[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. >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. - 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. 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. 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. 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. 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 do for the most part agree with much of what has been suggested and am a > firm supporter of reviewing process and ways of doing things periodically > for improvements, (mostly Bens suggestions as a previous change wrangler), > but I would ask folks to examine how much 'hands-on' involvement they have > in the actual mechanics of _processing_ the changes before suggesting ways > to engineer a brand new way to do it. What is it you are missing from the > current process in your own individual needs? Finding a fix to _that_ might > be more simpler than we think. > > P.S I would LOVE to not have to post to discourse and devel-announce and > really like the idea of the weekly change round up post on discourse and > keep main conversation to the mailing list. > > P.P.S There really is a lot of change happening - Fedora Forge, Bugzilla > ....thing..., maybe we see how the changes process adapts to these bigger > items first and then see what were missing and where from > 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. There has been so much changing around us since most processes were created, it's time to pull it all in for the large size and diverse interests all wanting to participate and needing to be heard. On Tue, Jun 30, 2026 at 12:30 PM Kashyap Chamarthy <[email protected]> > wrote: > >> On Tue, Jun 30, 2026 at 11:56:51AM +0200, Pierre-Yves Chibon wrote: >> > On Tue, Jun 30, 2026 at 11:45:34AM +0200, Kashyap Chamarthy wrote: >> >> [...] >> >> > The change process is not just about: here is an idea + some >> discussions + a >> > decision. >> > It's also about the implementation of that idea, tracking the work >> resulting >> > from this idea, ensuring that bugs introduced by that idea are >> identified, >> > centralized and acted on so that the person introducing the idea deals >> with the >> > fall-out, not someone else. >> >> Of course, implementation and its consequences are the core of it all. >> I did consider it. If you read the other email I mentioned with an >> OpenStack "spec" template, it show how implementation and the >> consequences are tracked. >> >> Now, I realize, a change spanning an entire Linux distribution is >> different than traditional upstreams. But OpenStack is a close enough >> analogy -- it's an "umbrealla project" that is a collection of various >> upstream projects. Their "spec" model is worth looking into (see links >> in my previous email) and adapting to Fedora's needs. >> >> > All this to say, I think we need to be looking at the process in its >> entirety >> > before focusing on some part that we'd like to change in order to >> ensure we do >> > not in fact lose some capabilities that we had before and which, turns >> out, we >> > want to keep. >> >> Sure, that only makes sense. I asked as much in my other reply. To be >> clear, I'm not implying to make any changes in isolation; that'd be >> silly. >> >> >> -- >> Kashyap Chamarthy / Red Hat / RISC-V and Fedora >> >> -- >> _______________________________________________ >> 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 >> > > > -- > > Aoife Moloney > > Fedora Operations Architect > > Fedora Project > > Matrix: @amoloney:fedora.im > > IRC: amoloney > > > -- > _______________________________________________ > 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 >
-- _______________________________________________ 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
