diff --git a/modules/ROOT/pages/changes_guide.adoc b/modules/ROOT/pages/changes_guide.adoc index 93e802a..e94993a 100644 --- a/modules/ROOT/pages/changes_guide.adoc +++ b/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. diff --git a/modules/ROOT/pages/changes_policy.adoc b/modules/ROOT/pages/changes_policy.adoc index 33ef5b1..a5fc1bd 100644 --- a/modules/ROOT/pages/changes_policy.adoc +++ b/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. diff --git a/modules/ROOT/pages/covid19.adoc b/modules/ROOT/pages/covid19.adoc index a4497fe..13080de 100644 --- a/modules/ROOT/pages/covid19.adoc +++ b/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) |=== diff --git a/modules/ROOT/pages/elections.adoc b/modules/ROOT/pages/elections.adoc index f175ff8..8253849 100644 --- a/modules/ROOT/pages/elections.adoc +++ b/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 diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc index 356776a..6f12c4b 100644 --- a/modules/ROOT/pages/index.adoc +++ b/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 diff --git a/modules/ROOT/pages/pgm_guide/changes.adoc b/modules/ROOT/pages/pgm_guide/changes.adoc index 16c0e1d..e31a6c8 100644 --- a/modules/ROOT/pages/pgm_guide/changes.adoc +++ b/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.). diff --git a/modules/ROOT/pages/pgm_guide/council.adoc b/modules/ROOT/pages/pgm_guide/council.adoc index cf8d109..19c0108 100644 --- a/modules/ROOT/pages/pgm_guide/council.adoc +++ b/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. diff --git a/modules/ROOT/pages/pgm_guide/elections.adoc b/modules/ROOT/pages/pgm_guide/elections.adoc index d3722c8..d7a95d0 100644 --- a/modules/ROOT/pages/pgm_guide/elections.adoc +++ b/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. diff --git a/modules/ROOT/pages/pgm_guide/getting_started.adoc b/modules/ROOT/pages/pgm_guide/getting_started.adoc index 0ca14dd..1d5fe39 100644 --- a/modules/ROOT/pages/pgm_guide/getting_started.adoc +++ b/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: diff --git a/modules/ROOT/pages/pgm_guide/inactive_provenpackagers.adoc b/modules/ROOT/pages/pgm_guide/inactive_provenpackagers.adoc index 7e55fbd..5158b30 100644 --- a/modules/ROOT/pages/pgm_guide/inactive_provenpackagers.adoc +++ b/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. diff --git a/modules/ROOT/pages/pgm_guide/index.adoc b/modules/ROOT/pages/pgm_guide/index.adoc index 65d6310..c319599 100644 --- a/modules/ROOT/pages/pgm_guide/index.adoc +++ b/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. diff --git a/modules/ROOT/pages/pgm_guide/pgm_communication.adoc b/modules/ROOT/pages/pgm_guide/pgm_communication.adoc index eba18a2..9785678 100644 --- a/modules/ROOT/pages/pgm_guide/pgm_communication.adoc +++ b/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. diff --git a/modules/ROOT/pages/pgm_guide/release_process.adoc b/modules/ROOT/pages/pgm_guide/release_process.adoc index d08d0a7..fd2e746 100644 --- a/modules/ROOT/pages/pgm_guide/release_process.adoc +++ b/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. diff --git a/modules/ROOT/pages/pgm_guide/schedule.adoc b/modules/ROOT/pages/pgm_guide/schedule.adoc index 9c6c9af..b5c65ec 100644 --- a/modules/ROOT/pages/pgm_guide/schedule.adoc +++ b/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. diff --git a/modules/ROOT/pages/pgm_guide/sop/branch.adoc b/modules/ROOT/pages/pgm_guide/sop/branch.adoc index c341dbe..f53c30d 100644 --- a/modules/ROOT/pages/pgm_guide/sop/branch.adoc +++ b/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 diff --git a/modules/ROOT/pages/pgm_guide/sop/fridays_fedora_facts.adoc b/modules/ROOT/pages/pgm_guide/sop/fridays_fedora_facts.adoc index 8434b4b..bc09854 100644 --- a/modules/ROOT/pages/pgm_guide/sop/fridays_fedora_facts.adoc +++ b/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. diff --git a/modules/ROOT/pages/pgm_guide/sop/release_day.adoc b/modules/ROOT/pages/pgm_guide/sop/release_day.adoc index 7396dcc..03fadad 100644 --- a/modules/ROOT/pages/pgm_guide/sop/release_day.adoc +++ b/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 diff --git a/modules/ROOT/pages/prioritized_bugs.adoc b/modules/ROOT/pages/prioritized_bugs.adoc index ecc8a0b..fc72675 100644 --- a/modules/ROOT/pages/prioritized_bugs.adoc +++ b/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?" diff --git a/modules/ROOT/pages/resources.adoc b/modules/ROOT/pages/resources.adoc index 7ed0a4e..e0c78e5 100644 --- a/modules/ROOT/pages/resources.adoc +++ b/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 diff --git a/releases/modules/ROOT/pages/lifecycle.adoc b/releases/modules/ROOT/pages/lifecycle.adoc index 9d93036..c11603f 100644 --- a/releases/modules/ROOT/pages/lifecycle.adoc +++ b/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 diff --git a/releases/modules/ROOT/pages/spins/creating.adoc b/releases/modules/ROOT/pages/spins/creating.adoc index 3a04221..a7d11a1 100644 --- a/releases/modules/ROOT/pages/spins/creating.adoc +++ b/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. diff --git a/releases/modules/ROOT/pages/spins/index.adoc b/releases/modules/ROOT/pages/spins/index.adoc index 4848be6..a557e5b 100644 --- a/releases/modules/ROOT/pages/spins/index.adoc +++ b/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. diff --git a/releases/modules/ROOT/pages/spins/maintaining.adoc b/releases/modules/ROOT/pages/spins/maintaining.adoc index 7dd466a..cff768c 100644 --- a/releases/modules/ROOT/pages/spins/maintaining.adoc +++ b/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.