Re: How can we improve the Changes Process?

On Mon, Jun 29, 2026 at 12:20:07PM -0500, Maxwell G wrote:
> Hi Kashyap,

Hey,

> On 6/29/26 9:47 AM, Kashyap Chamarthy wrote:

[...]

> > So much bloat.  IMHO, all of this should be drastically culled and
> > collapsed into one tool, if possible.
> As Ben notes, part of this is by design and accounts for the different
> states/stages of the Changes process, but ideally we can simplify parts of
> this and make it easier for Changes to move between the steps without manual
> work or opportunities for error.

Sounds good.

> > (2) Wiki change is copied to devel list
> 
> This is needed for the community feedback stage. The current process
> involves copying the whole proposal. This allows people and reply and quote
> individual parts of the proposal.

That makes sense, and is critical, of course.  Maybe we could do away
with the wiki.  Submit a draft MR with the change, send a note to the
mailing list with a link to the MR, ask people to reply on the MR
itself.  Aim to keep everything in _one_ place, as much as possible.

> > (3) Wiki change is copied to Discourse (this splits the discussion; and
> >      adds broken formatting)
> 
> I agree with you here, but if we do decide to keep Discourse, the new
> process definitely needs to remove the possibility for these formatting
> errors to creep in.

Sure.  I'm a bit torn on the Discourse/list split: Discourse allows
those who are not on the devel list to also chime in.  But it will also
maintain the status quo of this split-brains situation.  We'll be stuck
with it "forever".  Maybe insisit on having the debate on the MR?  But
it'll break people's preference for lists/Discourse.  Stalemate.

> > (4) FESCo ticket - voting
> 
> FESCo votes are exclusively tracked in the FESCo tracker, so I don't think
> we want to change this part.

I wonder if we can skip this ticket and have the voting be done in the
MR itself by means of ACK / NACKing change.

> > (5) Bugzilla - some other kind of tracking?
> 
> After FESCo approves a Change, Bugzilla is used to track the Change's
> implementation, and any bugs identified with the Change's implementation are
> supposed to Block that bug. If we moved to a different bug tracker, I assume
> this part would change but not go away completely.

Any reason we can't track the Change's implementation in the MR that is
implementing the said change?  Use BZ / Forge for bugs.  But I get it,
using a single "Blocks On" / "Blocks" in Bugzilla is helpful (I don't
know if such a thing is possible in Forge).

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