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!
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.
- 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.
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.
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.
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.
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?
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.
All the best,
Maxwell
--
_______________________________________________
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
