I'm impacted by this. As an example, I have a change waiting to move through the process: https://fedoraproject.org/wiki/Changes/EnableFwupdRefreshByDefault

For our F39 Change https://fedoraproject.org/wiki/Changes/ImproveDefaultFontHandling ,
First fedora-comps PR https://pagure.io/fedora-comps/pull-request/862 waiting happened which got merged irrespective of request to merge before branching which resulted another PR to be opened now for F40.
Then our own Change implementation PR https://src.fedoraproject.org/rpms/langpacks/pull-request/31 waiting for FESCo approval. All this results actual testing to be delayed.

For our F39 Change https://fedoraproject.org/wiki/Changes/ImproveDefaultFontHandling ,
First fedora-comps PR https://pagure.io/fedora-comps/pull-request/862 waiting happened which got merged irrespective of request to merge before branching which resulted another PR to be opened now for F40.
Then our other Change implementation PR https://src.fedoraproject.org/rpms/langpacks/pull-request/31 waiting for FESCo approval for https://fedoraproject.org/wiki/Changes/Indic_Noto_fonts. All this results actual testing to be delayed.

We're still smarting from the loss of the FPM. During Flock it was announced that the position will be recreated under a different name. To anyone impacted by this: please just do whatever needs to be done. FESCo members will try to fill in some blanks, but things will slipping through the cracks in the foreseeable future.

I marked Indic_Noto_fonts as approved / pending announcement now.
ImproveDefaultFontHandling was approved a while back.

I opened a ticket for EnableFwupdRefreshByDefault. FESCo, please vote.

I didn't create tracking issues or other stuff. Owners of the changes will need to do that themselves.

Tracker bugs are probably not that important (when we evaluate changes we often look at other things anyway), but what is important is the starting points for the discussions (i.e. devel-announce and Discourse post ...)

→ https://communityblog.fedoraproject.org/job-posting-fedora-operations-architect/

I hope FESCo will be okay if we change owners will go ahead and update our code in packages provided Change is approved and announced by FESCo but Change wiki page still shows "ChangeReadyForFesco"

The category is just informative. But if you see a wrong category, just adjust it.
Anyway, I went through the pages in ChangeReadyForFesco and moved them all to AcceptedFedora39.

Thank you @zbyszek for your quick help here.

I'm not sure if there's anything to do here. If there's a specific issue, please leave a comment.

Until there's a new person whose official responsibility it is to do that, I think we need to at least make sure that Changes that are ChangeReadyForWrangler get processed in a timely fashion, i.e. get an announcement post / discussion thread / fesco ticket. Having Changes sit in "ready limbo" for weeks is likely to impact release schedule / readiness otherwise.

I have https://fedoraproject.org/wiki/Changes/Revitalize_Forge_Macros waiting. Should I announce it on the mailing list myself using https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/changes-announce/?

Also, it looks like Changes/SQLAlchemy 2 has been waiting for almost a month.

Please do.

Please do.

See https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/C6O3U6XTE55W4FHW3DOJS2BN6HMIFC4K/. A moderator needs to ack the devel-announce post.

So, should this technically go to the web thingy I am unable to follow instead of the mailing list?

Yes, it should.

To be honest, it might be simpler to put the discourse thing on hold until things are less chaotic. Can users even create posts in the change proposals category? ...

Proposal: The change process uses the devel mailing list and experimenting with discourse is on hold until things are less chaotic.

+1, much easier for now.

+1

I'm also thinking about other ways to streamline the process (by possibly making some steps self-service for Change Owners

I don't like requiring Change owners to announce their own Changes, as then nobody quality checks before sending out the announcement, but we might not have a choice :frowning:.

So, should this technically go to the web thingy I am unable to follow instead of the mailing list?

Yeah, I forgot about this, and it looks like I don't have permissions to post in that topic to begin with.

Proposal: The change process uses the devel mailing list and experimenting with discourse is on hold until things are less chaotic.

I think this makes sense. The Discourse process is not at all documented (it was implemented after we lost Ben, which was a bad idea in hindsight), and it's more complicated (it requires announcing Changes in multiple places).

Perhaps FESCo should consider keeping the second part of the Changes/Telemetry discussion on Discourse, though. As much as I didn't like the way the discussion went and the breakout topic sprawl, changing the the discussion forum part way through feels wrong.

-1 to @churchyard's proposal.

Things are chaotic, but it's not caused by the locations of discussions about the tickets. Yesterday @kevin changed discussion settings so that anyone from FESCo can create tickets in the "Change proposal" category, so we should be able to create discussion threads. We agreed to try this for F40, and I think we should stick to the decision, rather then creating even more churn by reversing it.

Tracker bugs seem rather important to me, as they are the sensible place where we check whether Changes are actually meeting the deadlines, and ask maintainers about deferrals etc. They are also the source of truth for the Change state in the summary view at https://fedoraproject.org/wiki/Releases/39/ChangeSet , which is very important for us (QA) and probably others.

I have created all the outstanding tracker bugs for F39, updated the statuses of each one, and needinfo'd maintainers where I could not confidently determine the state of the Change. I've regenerated https://fedoraproject.org/wiki/Releases/39/ChangeSet with the changes, so it should now be up to date. I will file a ticket asking FESCo to review all outstanding changes that are definitely behind schedule for F39 (not currently 100% code complete) - there are a lot of them.

And if we're going to stick with the discourse plan, that really needs to be documented. The rest of the process is excellently documented by Ben, which is why I was able to do all the work on the tracker bugs. We need to keep that standard up.

This entire process should be way more automated. I already have a design for a lot of that in my head, but I don't know if I'll be able to implement it, since it's not really my job. But there should really be no need for human intervention in creating tickets, sending announcement mails, creating tracker bugs, creating releng review tickets, updating the ChangeSet page, or moving Changes between most of the states in the proess. All of that should happen automatically. Humans should only be needed in a few places, I think:

• Wrangler should manually review Change proposals before tagging them as ready to be announced, at which point automation should handle sending the announcement(s) and moving the Change to the ChangeAnnounced category
• Wrangler should decide when an announced Change is 'ready for FESCo' and tag it as such, at which point automation should create the FESCo ticket and move the Change to ChangeReadyForFesco
• FESCo should vote on each Change, at which point automation should respond appropriately to the vote (trigger: noticing when tickets with a Change-related tag are set to Accepted or Rejected) by doing all the stuff at https://docs.fedoraproject.org/en-US/program_management/pgm_guide/sop/changes-process/ , all of which could be fully automated (rather than script-assisted)
• Wrangler and FESCo should review Change status periodically according to the current process, but nobody should have to manually regenerate the ChangeSet page when a Change tracker bug changes state, automation should catch the event from bugzilla and do it (or just regenerate it every day, if you want to keep it simple)

FWIW I was on vacation for a lot of August and not around to help out with the change process as I had been in previous months, but I am still happy to pitch in and fill the gaps where needed as best I can too until the position is filled.
For the interim and to be transparent on what kind of help I can offer at this point in the F39 & F40 cycles, I have the bandwidth to help out on facilitating F39 meetings & sending reports (bugs, F39 decision outcomes, etc) and I'll hkeep an eye on the ReadyforWrangler page as well with others to get F40 change proposals out for discussion to confirm, on discourse?

Sounds good.

FWIW: I think we'll have a full-time person in the new "Operations Architect" role before the F39 release.

Yay for that. Until we do, I can help out @amoloney with temporary wrangling, now I've figured out the process for updating the tracker bugs and ChangeSet page.

Changes are again piling up in https://fedoraproject.org/wiki/Category:ChangeReadyForWrangler, and tracking bugs are still not being created. This is becoming a big problem.

I can do a sweep through those when F39 Beta calms down a bit, if nobody else gets to it first.

Note, tracking bugs are not created until after a change has been announced, submitted to FESCo, and then approved. I have created the tracking bug for your change and am updating the wiki pages, @gotmax23 . Aoife did the announcements for all the changes that had piled up in the readyforwrangler category earlier today.

Do we need to do anything anymore now that @amoloney officially does this?

I don't think so. I'll close this ticket then, since it was also me who opened it :)