Re: How can we improve the Changes Process?

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