fesco

#3559 Clarify permission to implement an approved Change proposal
Closed: Accepted by yselkowitz. Opened by yselkowitz.

Closed: Accepted
Reopen Issue

Following up from discussion in https://pagure.io/fesco/issue/3539:

Currently the fesco ticket template for Change proposals states:

Owners, do not implement this work until the FESCo vote has explicitly ended.
The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.

And the Changes policy states:

Do not implement your proposal until the FESCo vote has ended. When the Change Wrangler (FOA) creates a tracking bug for your issue, that is your indication to proceed.

Ideally, the Change Wrangler would process these immediately, but recently that hasn't been the case, and it has lead to confusion as to whether and when implementation may begin. Given the tight timelines between the Self-Contained Change submission deadline (plus one week for voting) and branchpoint (while not being the deadline for testability, it's more work to implement after branching than before), Change owners are understandably anxious to begin as soon as possible.

In the aforementioned ticket, it seems to be the opinion of at least some FESCo members that ticket approval is sufficient permission, and that waiting for the BZ is unnecessary. Therefore, I propose the language be updated accordingly, i.e. in the issue template:

Owners, do not implement this work until the FESCo vote has explicitly ended.
When a FESCo member has marked this ticket as APPROVED, you may proceed with the implementation. See the FESCo ticket policy and the Changes policy for more information.
If no decision has been rendered after 7 days from the filing of this ticket and no indication (such as a -1 vote) that this will be taken up at a FESCo meeting, please feel free to ping for a status update.

And in the policy:

Do not implement your proposal until the FESCo vote has ended. When a FESCo member has marked the change ticket as APPROVED, you may then proceed with the implementation.

I'm +1 for the proposal as written here.

+1

This (and the surrounding issues with F44 changes) was discussed today by FESCo in open floor. There seems to be additional confusion as to when the Change Wrangler should proceed respective to the state of the ticket. Does this require further clarification as well here and/or in FESCo's procedures?

At the same point in time. Marking as APPROVED is an indication to the Change Owners and the Change Wrangler, as well as anyone else interested in the topic, that the change shall be implemented.

+1 to the proposed changes.

+1

+1

According to the policy, we had 2 votes in the first week, so not enough to approve. We're currently at (+5, 0, 0) and this will be approved in two days.

The proposed changes will have been approved 4 days ago (+5, 0, -0).

Who can update the linked docs and ticket template?

Metadata Update from @decathorpe:
- Issue tagged with: document it

Announced as approved, just needs to be documented still.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/QZDHIQUS76CVUIMUW67TRLEE62R3B4WP/

https://forge.fedoraproject.org/operations/docs/pulls/100 for the policy doc.

No idea where to change the ticket template.

I guess I am the default maintainer for the Fedora Program Operations docs. I can merge @yselkowitz's PR over there, but I am a bit concerned about making this policy change while @amoloney is unaccounted for. The wider context for why tracking bugs are not being created promptly is likely due to Aoife being out on leave until 18 May 2026.

I think the policy needs to account for the fact that the Operations Architect is going to be the most-likely person to carry out this work, but I also see no reason why FESCo does not have the authority to do it either.

Thinking about it, I am going to suggest a simple edit on the docs PR linked above.

I also think FESCo should consider maintaining an Etherpad or some other notepad-like document for @amoloney as an "orientation guide" for coming back from her leave. Changes like this would be important for her to know about how different roles that were exclusively done by the Operations Architect have changed in the period when she was away.

That is just a thought. No idea how y'all would want to keep track of info like this, but I think it is in your interest to have an informed Operations Architect once she comes back from leave in May!

As I answered in the PR, this is a policy change affecting Change Owners, not the FOA:

This is not meant to "write out" the FOA -- they are still responsible to do all the tasks they were before, not that this doc is necessarily the place to explain those -- but to avoid blocking on them (the FOA being a single person, regardless of whom, and hence a potential single point of failure).

Yeah, no need to overthink this.

One down, one to go:

Do not implement your proposal until the FESCo vote has ended. When the Change Wrangler (FOA) creates a tracking bug for your issue, that is your indication to proceed.

I couldn't find this text in any public repo. So I think it must be stored somewhere in private FOA scripts.

I merged the docs PR. This is now updated on the docs site for Program Operations.

https://pagure.io/fedora-pgm/pgm_scripts/pull-request/16 for the ticket template.

https://pagure.io/fedora-pgm/pgm_scripts/pull-request/16 for the ticket template.

This PR was merged. That should complete the implementation of this decision.

Metadata Update from @yselkowitz:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

Metadata Update from @zbyszek:
- Issue untagged with: document it
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.