🚚 Meta: Rename Fedora Program Manager to Fedora Operations Architect

The "Fedora Program Manager" (FPgM) title was retired and replaced with
"Fedora Operations Architect" (FOA) to better reflect the scope and
nature of the role within the Fedora Project. This commit updates all
documentation across both the main operations module and the
releases module, replacing:

- "Fedora Program Manager" → "Fedora Operations Architect"
- "Program Manager" (when referring to role) → "Operations Architect"
- "FPgM" → "FOA"

Also updates stale content exposed by the rename:

- Page titles and descriptions now use "Program Operations" branding
- Contact information updated to current staff (@amoloney, @jspaleta,
  @jnsamyak) replacing former holders
- Election wrangler backup corrected from "Fedora Action and Impact
  Coordinator" to "Fedora Community Architect"
- Council role description updated from "auxiliary member" to "permanent
  seat"
- Cross-reference targets updated from `council::fpgm.adoc` to
  `council::foa.adoc`
- Repository links migrated from Pagure to Forgejo where applicable
- Removed stale FOA office hours reference from index page

Note: The WordPress featured image for Friday's Fedora Facts still uses
the "fpgm" identifier and old title text — that asset lives in the
WordPress media library and must be updated separately.

Assisted-by: Claude Opus 4.6 (1M context)
Signed-off-by: Justin Wheeler <jwheel@redhat.com>

modules/ROOT/pages/changes_guide.adoc

@@ -30,12 +30,12 @@ TIP: You can remove the HTML comments in the template if you choose.
 WARNING: Make sure to finish your change proposal by the change proposal submission deadline!
 If you do not meet this deadline, you must seek an exception from FESCo.
 
-The Program Manager is responsible for the actual announcement of the change proposal, creating the FESCo ticket and tracking bug in Bugzilla.
+The Operations Architect is responsible for the actual announcement of the change proposal, creating the FESCo ticket and tracking bug in Bugzilla.
 
 == How do I show the status of a change I own?
 The progress of development is shown in Bugzilla with defined bug states as explained in the change proposal template.
 Use this tracking bug to show blockers, using the Blocks/Depends on fields (for example package reviews), update the bug description with an actual status, and modify the bug status to reflect current state.
-You may be asked by the Program Manager or FESCo members to provide more detailed status (especially for system-wide changes).
+You may be asked by the Operations Architect or FESCo members to provide more detailed status (especially for system-wide changes).
 
 A Change is considered _code complete_ when the bug state is moved to ON_QA and when there are no blocking bugs open.
 
@@ -49,7 +49,7 @@ See the xref:changes_policy.adoc#_change_process_milestones[Change Process Miles
 == What if I don't complete a change?
 Changes which cannot be completed for the release are automatically deferred to the next release.
 You do not need to re-propose the Change unless you are making substantial revisions to it.
-If you need to defer a change, let the Program Manager know and they will update the wiki page and the Bugzilla tracker appropriately.
+If you need to defer a change, let the Operations Architect know and they will update the wiki page and the Bugzilla tracker appropriately.
 
 == What if I have to modify my Change?
 
@@ -75,7 +75,7 @@ Give a brief description of packages or services where it makes sense.
 === Owner
 For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
 
-TIP: Use your Bugzilla email in the `email` field to make your Program Manager happy.
+TIP: Use your Bugzilla email in the `email` field to make your Operations Architect happy.
 
 === Current status
 Do not edit this section except to set the target release version and update the `[[Category:*]]` tags.
@@ -98,7 +98,7 @@ In the future, there will be more specific guidance about how to post pre-propos
 Either way, when you receive feedback, you should summarize it in this section.
 
 TIP: You should fill in this section as feedback is received.
-As this is optional the Program Manager does not need to wait for you to complete this section before submitting to FESCo.
+As this is optional the Operations Architect does not need to wait for you to complete this section before submitting to FESCo.
 If the discussion gets heated, consider asking a neutral party to summarize the discussions for you.
 This helps avoid bias and emotional response.
 

modules/ROOT/pages/changes_policy.adoc

@@ -108,7 +108,7 @@ This includes Release Engineering, Fedora Packaging Committee, and trademark app
 The change owner may be asked to provide more details or address proposed concerns.
 * FESCo members are encouraged to ask questions on the discussion post ahead of the change ticket being openend.
 * The Change Wrangler (FOA) files a FESCo ticket no sooner than one week after the announcement on the mailing list and discussion post.
-* Change owners are subscribed to the FESCo ticket once it has been created by the Program Manager.
+* Change owners are subscribed to the FESCo ticket once it has been created by the Operations Architect.
 ** Occasionally, more information is needed on some proposals, and FESCo members may use the ticket filed for clarificiation instead of waiting for the meeting.
 * FESCo will then vote to approve or deny a change proposal in accordance with the xref:fesco:ROOT:index.adoc#_ticket_policy[FESCo ticket policy].
 Do not implement your proposal until the FESCo vote has ended.

modules/ROOT/pages/covid19.adoc

@@ -3,7 +3,7 @@
 
 The primary concern of the Fedora leadership remains the health and safety of the Fedora community.
 However, we are tracking the risk to Fedora release deliverables as the situation evolves.
-This document is maintained by the Fedora Program Manager (Ben Cotton) with the Fedora Project Leader (Matthew Miller) as a backup.
+This document is maintained by the Fedora Operations Architect (Aoife Moloney) with the Fedora Project Leader (Jef Spaleta) as a backup.
 
 
 == Status
@@ -46,10 +46,10 @@ This document is maintained by the Fedora Program Manager (Ben Cotton) with the
 |===
 |Area{set:cellbgcolor:!}|Name|Email|Location/time zone
 
-|Program Management|Ben Cotton|bcotton AT redhat DOT com|Indiana, US (Eastern)
-|Fedora Project Leader|Matthew Miller|mattdm AT redhat DOT com|Massachusetts, US (Eastern)
+|Program Operations|Aoife Moloney|amoloney AT redhat DOT com|Cork, IE
+|Fedora Project Leader|Jef Spaleta|jspaleta AT redhat DOT com|Virginia, US (Eastern)
 |Infrastructure|Kevin Fenzi|kfenzi AT redhat DOT com|Oregon, US (Pacific)
-|Release Engineering|Mohan Boddu|mboddu AT redhat DOT com|Massachusetts, US (Eastern)
+|Release Engineering|Samyak Jain|samjain AT redhat DOT com|New Delhi, IN
 |QA|Adam Williamson|awilliam AT redhat DOT com|British Columbia, CA (Pacific)
 |===
 

modules/ROOT/pages/elections.adoc

@@ -6,7 +6,7 @@ See the xref:_schedule[schedule below] for key dates.
 ////
 
 Fedora has several elected bodies that regularly conduct elections every release cycle.
-In addition, Fedora teams can request one-off elections from the Fedora Program Manager when trying to select new leadership or otherwise reach a decision through a formal voting process.
+In addition, Fedora teams can request one-off elections from the Fedora Operations Architect when trying to select new leadership or otherwise reach a decision through a formal voting process.
 
 == Upcoming elections
 The following elections will take place after each release:
@@ -34,13 +34,13 @@ If they wish to nominate someone else, please consult with that person ahead of
 
 === Interviews
 Nominees are requested to answer the selected questions using a https://pagure.io/fedora-pgm/elections-interviews/issues[private issue in Pagure].
-In this way, only the Program Manager and Fedora Action and Impact Coordinator (as election wrangler substitute) are allowed to see these answers.
+In this way, only the Operations Architect and Fedora Community Architect (as election wrangler substitute) are allowed to see these answers.
 
 === Voting Setup & Validation & Publishing of interviews
-It is the responsibility of the Program Manager to validate the eligibility of nominees for elections.
+It is the responsibility of the Operations Architect to validate the eligibility of nominees for elections.
 In compliance with https://pagure.io/Fedora-Council/tickets/issue/135[Fedora Council decision #135], nominees not having completed their interviews (as a private issue in Pagure) are excluded from the list of nominees.
 
-The Program Manager is responsible for publishing these interviews on the https://communityblog.fedoraproject.org/[Fedora Community Blog] as well as setup of the https://elections.fedoraproject.org/[voting machine] for the elections.
+The Operations Architect is responsible for publishing these interviews on the https://communityblog.fedoraproject.org/[Fedora Community Blog] as well as setup of the https://elections.fedoraproject.org/[voting machine] for the elections.
 
 === Voting Information
 

modules/ROOT/pages/index.adoc

@@ -1,9 +1,9 @@
-= Fedora Program Management
+= Fedora Program Operations
 
-Keep up to date with program management information on the https://communityblog.fedoraproject.org/category/program-management/[Fedora Community Blog] or by attending the weekly FPgM office hours at https://calendar.fedoraproject.org/council/#m9847[0900] or https://calendar.fedoraproject.org/meeting/9915/[1600] (America/Indiana/Indianapolis) Wednesdays in https://web.libera.chat/?channels=#fedora-meeting-1[#fedora-meeting-1].
+Keep up to date with program management information on the https://communityblog.fedoraproject.org/category/program-management/[Fedora Community Blog].
 
 TIP: To report issues with schedules, file an issue in the https://pagure.io/fedora-pgm/schedule[schedule repo].
-To report an issue with this document, file an issue in the https://pagure.io/fedora-pgm/pgm_docs/[pgm_docs repo].
+To report an issue with this document, file an issue in the https://forge.fedoraproject.org/operations/docs/[operations/docs repo].
 
 == Fedora Operations Architect
 

modules/ROOT/pages/pgm_guide/changes.adoc

@@ -5,6 +5,6 @@ We need to know about disrupting changes coming to the next release to set the s
 For more details on Change Process, see the xref:program_management::changes_policy.adoc[Changes Policy].
 
 == Responsibilities
-The Program Manager's key responsibility is to maintain the Changes Process — xref:pgm_guide/sop/changes-announce.adoc[announcements], xref:pgm_guide/sop/changes-submit.adoc[submission], xref:pgm_guide/sop/changes-process.adoc[processing], xref:pgm_guide/sop/changes-contingency.adoc[tracking], xref:pgm_guide/sop/changes-defer.adoc[deferring], xref:pgm_guide/sop/changes-drop.adoc[dropping]. Completed Changes are closed as part of the xref:pgm_guide/sop/release_day.adoc[Release Day SOP].
+The Operations Architect's key responsibility is to maintain the Changes Process — xref:pgm_guide/sop/changes-announce.adoc[announcements], xref:pgm_guide/sop/changes-submit.adoc[submission], xref:pgm_guide/sop/changes-process.adoc[processing], xref:pgm_guide/sop/changes-contingency.adoc[tracking], xref:pgm_guide/sop/changes-defer.adoc[deferring], xref:pgm_guide/sop/changes-drop.adoc[dropping]. Completed Changes are closed as part of the xref:pgm_guide/sop/release_day.adoc[Release Day SOP].
 One of the main responsibilities is helping Change owners through the submission process.
-The Program Manager works on the xref:program_management::changes_policy.adoc[Changes Policy] with the xref:fesco::index.adoc[Fedora Engineering Steering Committee] (FESCo), Working Groups and other Fedora teams and bodies (documentation, marketing, etc.).
+The Operations Architect works on the xref:program_management::changes_policy.adoc[Changes Policy] with the xref:fesco::index.adoc[Fedora Engineering Steering Committee] (FESCo), Working Groups and other Fedora teams and bodies (documentation, marketing, etc.).

modules/ROOT/pages/pgm_guide/council.adoc

@@ -1,5 +1,5 @@
 = Council meetings and processes
 
-The Fedora Program Manager sits on the Fedora Council as an auxiliary member.
-The FPgM generally leads the regular Council meetings and keeps an eye on the https://pagure.io/Fedora-Council/tickets/issues[ticket queue].
+The Fedora Operations Architect maintains a permanent seat on the Fedora Council.
+The FOA generally leads the regular Council meetings and keeps an eye on the https://forge.fedoraproject.org/council/tickets/[ticket queue].
 There is not much to say here, just help bring some structure to the Council and make sure tickets are appropriately categorized and don't languish.

modules/ROOT/pages/pgm_guide/elections.adoc

@@ -1,11 +1,11 @@
 = Elections
 
-The Fedora Program Manager is responsible for conducting elections for various bodies within Fedora.
+The Fedora Operations Architect is responsible for conducting elections for various bodies within Fedora.
 After each release, the Fedora Engineering Steering Committee run an election. The Fedora Council, Mindshare Committee and EPEL Steering Committee run an election on a once per year basis.
 Other teams may request elections at any time if they have a need.
 
 The Fedora Community Architect (FCA) is the backup elections wrangler.
-The FCA & FPgM cannot be candidates for elected positions.
+The FCA & FOA cannot be candidates for elected positions.
 
 NOTE: FESCo has a xref:fesco::FESCo_election_policy.adoc[separate election policy] that requires more candidates than open seats.
 

modules/ROOT/pages/pgm_guide/getting_started.adoc

@@ -1,7 +1,7 @@
 = Getting started
 
 Congratulations!
-You're the new Fedora Program Manager.
+You're the new Fedora Operations Architect.
 Whether you're new to Red Hat, to the Fedora Community, or both, there's a lot to learn.
 Here's a list of things you'll need to get started:
 

modules/ROOT/pages/pgm_guide/inactive_provenpackagers.adoc

@@ -4,7 +4,7 @@ The `provenpackagers` group grants members write privileges across all Fedora pa
 Thus, we want to make sure the privilege doesn't linger on inactive accounts.
 In early 2021, https://pagure.io/fesco/issue/2549[FESCo adopted] a policy for xref:fesco::Provenpackager_policy.adoc#_maintaining_provenpackager_status[maintaining provenpackager status].
 
-The Fedora Program Manager is charged with performing an audit of these accounts.
+The Fedora Operations Architect is charged with performing an audit of these accounts.
 This should take place at about the branch point of each development cycle.
 
 The https://pagure.io/fedora-pgm/pgm_scripts/blob/main/f/provenpackager/inactive_provenpackagers.py[inactive_provenpackagers.py] script will check for provenpackagers that have not submitted a Koji build in the last six months.

modules/ROOT/pages/pgm_guide/index.adoc

@@ -1,6 +1,6 @@
-= Fedora Program Manager Guide
+= Fedora Operations Architect Guide
 
-This guide provides information on how to do the work of the Fedora Program Manager.
-If you are not the Fedora Program Manager, you are welcome to keep reading — this document may be informative for you — but if you don't understand something, that's probably okay.
+This guide provides information on how to do the work of the Fedora Operations Architect.
+If you are not the Fedora Operations Architect, you are welcome to keep reading — this document may be informative for you — but if you don't understand something, that's probably okay.
 
 

modules/ROOT/pages/pgm_guide/pgm_communication.adoc

@@ -27,7 +27,7 @@ For items without a defined deadline, I leave them for 1–4 weeks, depending on
 These generally come from observing the meeting minutes and mailing lists of teams within Fedora.
 I generally leave them for a few weeks.
 * *Upcoming meetings & test days* — Project-level meetings that will occur within the next week.
-I generally include Council meetings, blocker review meetings, prioritized bugs meetings, and the xref:_fpgm_office_hours[FPgM office hours] as regular entries.
+I generally include Council meetings, blocker review meetings, prioritized bugs meetings, and the xref:_foa_office_hours[FOA office hours] as regular entries.
 I also include the xref:release_process.adoc#_gono_go_meeting[Go/No-Go] meetings when appropriate.
 If the QA team has organized test days, I will include those as well.
 * *Fedora N* — Information about the current in-progress Fedora release (you may have N+1 as well).
@@ -49,7 +49,7 @@ You can also use:
 * http://www.wikicfp.com/cfp/call?conference=open%20source
 * https://www.cfpland.com/
 
-== FPgM office hours
+== FOA office hours
 This is no longer active, but if a need for it resurfaces, content can be found in the file `office_hours.md` in the `pgm_communication` repository.
 
 

modules/ROOT/pages/pgm_guide/release_process.adoc

@@ -88,13 +88,13 @@ Release Engineering or QA will confirm that a candidate compose exists.
 If there is no candidate compose, skip straight to a "no-go" decision.
 
 If there are proposed or accepted blocker bugs, the meeting becomes a blocker review meeting to evaluate them.
-This portion of the meeting can be led by a member of the QA team or by the Program Manager.
+This portion of the meeting can be led by a member of the QA team or by the Operations Architect.
 It is not uncommon to defer some bugs until later in the meeting so that last-minute testing can be performed.
 
 In the test matrices section, QA will review the results of tests.
 Some optional tests may not be complete.
 
-Finally, the Program Manager polls each of the constituent teams.
+Finally, the Operations Architect polls each of the constituent teams.
 If they all vote "go", then the release is "go" and will be released on the coming Tuesday.
-The Program Manager's work is done (at least as far as this goes).
+The Operations Architect's work is done (at least as far as this goes).
 If the release is "no-go", then a follow-up meeting must happen.

modules/ROOT/pages/pgm_guide/schedule.adoc

@@ -1,6 +1,6 @@
 = Schedule
 
-Developing and maintaining the https://fedorapeople.org/groups/schedule/[Fedora Project's schedule] may be the most important part of the Fedora Program Manager's job.
+Developing and maintaining the https://fedorapeople.org/groups/schedule/[Fedora Project's schedule] may be the most important part of the Fedora Operations Architect's job.
 The good news is that it is not very hard.
 https://pagure.io/fesco/issue/2211#comment-590831[FESCo approved] reusing the same general structure for every release, with target release dates of the third Tuesday in April and October.
 Now it will only change if there are major requirements that necessitate a deviation.

modules/ROOT/pages/pgm_guide/sop/branch.adoc

@@ -3,7 +3,7 @@
 This document outlines the procedures for activities that occur on "branch day":
 when the next Fedora Linux release branches from Rawhide.
 
-Many of the branching activities are handled by Release Engineering, but several are in the scope of the Fedora Program Manager.
+Many of the branching activities are handled by Release Engineering, but several are in the scope of the Fedora Operations Architect.
 
 == Timing/trigger
 

modules/ROOT/pages/pgm_guide/sop/fridays_fedora_facts.adoc

@@ -119,7 +119,7 @@ The command `date +%Y-%V` will give you the correct date stamp.
 . Set the category to "Program Management".
 . Add the following tags: "releases", "Fedora release changeset", "Friday's Fedora Facts".
 In addition, use "Call for Papers (CfP)", "Help wanted", "Test Days", "elections", and any other tags that might apply to the contents of this week's report.
-. Set the featured image to be "fpgm" (a photo of a clipboard with the text "From the Fedora Program Manager") in the WordPress media library.
+. Set the featured image to be "fpgm" (a photo of a clipboard with the text "From the Fedora Operations Architect") in the WordPress media library.
 . After publishing the update, remove outdated content from the `fridays_fedora_facts.md` file.
 
 Refer to the Community Blog https://communityblog.fedoraproject.org/writing-community-blog-article/[contribution documentation] and https://communityblog.fedoraproject.org/editor-guidelines/[article guidelines] for more details.

modules/ROOT/pages/pgm_guide/sop/release_day.adoc

@@ -7,7 +7,7 @@ Unless otherwise specified, it applies to both Beta and Final releases.
 
 Ensure the following people are in the https://matrix.to/#/#release-day:fedora.im[Release Day chat channel]:
 
-* You, as the Program Manager
+* You, as the Operations Architect
 * A representative from the Infrastructure team with access to force a re-sync of web proxies
 * A representative from the Websites team
 * A representative from the Magazine team

modules/ROOT/pages/prioritized_bugs.adoc

@@ -41,7 +41,7 @@ The list of currently nominated bugs waiting for evaluation can be seen using th
 === Evaluation
 
 Evaluation of nominated bugs is done by the Evaluation team.
-This team is comprised of the xref:council::fpl.adoc[Fedora Project Leader] (FPL), xref:council::fpgm.adoc[Fedora Program Manager] (FPgM), and people representing Fedora Working Groups and Special Interest Groups, as well as interested community members.
+This team is comprised of the xref:council::fpl.adoc[Fedora Project Leader] (FPL), xref:council::foa.adoc[Fedora Operations Architect] (FOA), and people representing Fedora Working Groups and Special Interest Groups, as well as interested community members.
 The team does not have fixed group of members.
 Instead members of the Evaluation team are formed at the beginning of the meeting during Roll Call.
 
@@ -64,10 +64,10 @@ After all, we prioritize relatively few bugs.
 However that doesn't always pan out for a variety of reasons.
 This is a rough idea of what happens after a bug is accepted as a Prioritized Bug:
 
-* The FPgM marks the bug as prioritized in Bugzilla after the meeting
-* After ~1 weeks with no visible progress or acknowledgement, the FPgM marks the assignee as NEEDINFO in Bugzilla
-* After another ~1 week with no visible progress or acknowledgement, the FPgM contacts the assignee outside of Bugzilla
-* After another ~2 weeks with no visible progress or acknowledgement, the FPL or FPgM will escalate the bug to the assignee's manager (if they are a Red Hat employee acting in their work role) or to a provenpackager
+* The FOA marks the bug as prioritized in Bugzilla after the meeting
+* After ~1 weeks with no visible progress or acknowledgement, the FOA marks the assignee as NEEDINFO in Bugzilla
+* After another ~1 week with no visible progress or acknowledgement, the FOA contacts the assignee outside of Bugzilla
+* After another ~2 weeks with no visible progress or acknowledgement, the FPL or FOA will escalate the bug to the assignee's manager (if they are a Red Hat employee acting in their work role) or to a provenpackager
 
 NOTE: The escalation is not intended to be "this person isn't doing their job" in character.
 It is a "hey, can you make sure your team has resources to look at this problem that Fedora has identified as a priority?"

modules/ROOT/pages/resources.adoc

@@ -1,7 +1,7 @@
-= Program Management resources
+= Program Operations resources
 
 This page collects training and reference resources.
-You may find this useful if you're doing program or project management in Fedora.
+You may find this useful if you're doing program operations in Fedora.
 
 == General program/project management
 

releases/modules/ROOT/pages/lifecycle.adoc

@@ -26,7 +26,7 @@ Beta and General Availability (final) releases happen at approximately 14:00 UTC
 === Development Planning
 
 Fedora development planning is handled by the xref:program_management::changes_policy.adoc[Release Planning Process].
-So-called ''Changes'' are proposed, initially reviewed, and monitored through the development process by the xref:fesco::index.adoc[Fedora Engineering Steering Committee] (FESCo) and xref:program_management::index.adoc#_fedora_program_manager[Fedora Program Manager].
+So-called ''Changes'' are proposed, initially reviewed, and monitored through the development process by the xref:fesco::index.adoc[Fedora Engineering Steering Committee] (FESCo) and xref:council::foa.adoc[Fedora Operations Architect].
 
 === Development Process
 
@@ -49,7 +49,7 @@ This freeze is lifted once the milestone is finished, and so packages begin to m
 
 Fedora Linux release schedules repeat ad infinitum with "early target" dates of the third Tuesday in April and October.
 Significant changes to the release schedule must be approved by FESCo.
-The Fedora Program Manager works with teams across the project to incorporate their activities into the overall schedule and will make updates that do not affect release milestones.
+The Fedora Operations Architect works with teams across the project to incorporate their activities into the overall schedule and will make updates that do not affect release milestones.
 
 
 === Development Schedule Rationale

releases/modules/ROOT/pages/spins/creating.adoc

@@ -60,6 +60,6 @@ Create an issue in the https://github.com/FedoraQt/MediaWriter/issues[MediaWrite
 == Adopting a Spin
 
 If a Spin is abandoned and you want to take it over, it doesn't take much beyond raising your hand.
-If the Program Manager has announced that the Spin is abandoned, just reply to their email.
+If the Operations Architect has announced that the Spin is abandoned, just reply to their email.
 For a Spin that has been retired, first make sure there's a good use case for bringing it back.
 If there is, submit a Self-Contained xref:program_management::changes_policy.adoc[Change proposal] as if it were a new Spin.

releases/modules/ROOT/pages/spins/index.adoc

@@ -19,7 +19,7 @@ For historical information, see the per-release information on the sidebar.
 Teams within Fedora are responsible for curating their Spins.
 The release-specific Spins listings on the sidebar have links to the maintainers for each Spin.
 
-Each release, the Fedora Program Manager checks with each Spin maintainer to make sure they still want to keep their Spin active.
+Each release, the Fedora Operations Architect checks with each Spin maintainer to make sure they still want to keep their Spin active.
 If they do not, or if there is no reply, the Spin is offered to the community for adoption.
 Unmaintained Spins are dropped in order to make sure our users get the intended experience.
 

releases/modules/ROOT/pages/spins/maintaining.adoc

@@ -26,5 +26,5 @@ Most failures these days are systemic (in other words, they represent an actual
 
 == Keepalive
 
-Once per release cycle, the Fedora Program Manager will check with all Spin maintainers to ensure the Spin should continue to be produced.
-If you do not respond, the Program Manager will attempt to find someone to take maintainership of the Spin.
+Once per release cycle, the Fedora Operations Architect will check with all Spin maintainers to ensure the Spin should continue to be produced.
+If you do not respond, the Operations Architect will attempt to find someone to take maintainership of the Spin.