From 25881af983a39d47a487d066ac4bf09c5d398a88 Mon Sep 17 00:00:00 2001 From: René Genz Date: Apr 21 2022 12:59:04 +0000 Subject: Various minor changes for program_management - fix typos - add/fix links - fix lists - delete surplus empty spaces --- diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index a8c5c93..d3b022c 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -27,4 +27,4 @@ ** xref:pgm_guide/getting_started.adoc[Getting started] ** SOPs *** xref:pgm_guide/sop/release-new.adoc[New releases] -*** Xref:pgm_guide/sop/release-delay.adoc[Release delay] +*** xref:pgm_guide/sop/release-delay.adoc[Release delay] diff --git a/modules/ROOT/pages/changes_guide.adoc b/modules/ROOT/pages/changes_guide.adoc index 5d18a55..cebbc06 100644 --- a/modules/ROOT/pages/changes_guide.adoc +++ b/modules/ROOT/pages/changes_guide.adoc @@ -9,7 +9,7 @@ TIP: Watch the https://www.youtube.com/watch?v=oERoxg-VYPo[Fedora Changes policy == How do I propose a new change? In order to be considered an official change proposal accepted for the next Fedora Linux release, the change proposal must be formally documented on a separate wiki page. -TIP: Read the xref:changes_policy[policies] for self-contained changes and system-wide changes. +TIP: Read the xref:changes_policy.adoc[policies] for self-contained changes and system-wide changes. TIP: Pick the right category. Remember, the category can be changed to another one based on community or FESCo review! @@ -36,7 +36,7 @@ The Program Manager is responsible for the actual announcement of the change pro 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). - + A Change is considered _code complete_ when the bug state is moved to ON_QA and when there are no blocking bugs open. NOTE: See the xref:changes_policy.adoc#_bugzilla_trackers[Bugzilla trackers] section of the Changes policy for more information on Bugzilla statuses. @@ -48,7 +48,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 substantional revisions to it. +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. == Section-by-section guidance @@ -61,14 +61,14 @@ For example "glibc 2.29" is preferable to "glibc upgrade". TIP: Make sure your page is in the `Changes` namespace (e.g. call it `Changes/glibc_2.29`) === Summary -A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. +A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. Note that motivation for the change should be in the Motivation section below, and this part should answer the question "What?" rather than "Why?". TIP: Assume that not everyone who sees this will know what you're talking about. 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. +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. @@ -89,7 +89,7 @@ This section is inspired in part by the "Rejected Ideas" section described by ht For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. This could be done via a post to the devel mailing list for full community feedback, or sharing with some additional people who you trust to give you candid feedback. -//In thie future, there will be more specific guidance about how to post pre-proposal feedback. +//In the future, there will be more specific guidance about how to post pre-proposal feedback. Either way, when you receive feedback, you should summarize it in this section. TIP: You should fill in this section as feedback is received. @@ -99,7 +99,7 @@ This helps avoid bias and emotional response. === Benefit to Fedora -What is the benefit to the distribution? +What is the benefit to the distribution? Will the software we generate be improved? How will the process of creating Fedora Linux releases be improved? @@ -112,25 +112,25 @@ For example: This change allows package upgrades to be performed automatically a * Does this improve some specific package or set of packages? For example: This change modifies a package to use a different language stack that reduces install size by removing dependencies. * Does this improve specific Spins or Editions? -* For example: This change modifies the default install of Fedora Workstation to be more in line with the base install of Fedora Server. +For example: This change modifies the default install of Fedora Workstation to be more in line with the base install of Fedora Server. * Does this make the distribution more efficient? For example: This change replaces thousands of individual %post scriptlets in packages with one script that runs at the end. * Is this an improvement to maintainer processes? For example: Gating Fedora packages on automatic QA tests will make rawhide more stable and allow changes to be implemented more smoothly. -* Is this an improvement targeted as specific contributors? -For example: Ensuring that a minimal set of tools required for contribution to Fedora are installed by default eases the onboarding of new contributors. +* Is this an improvement targeted at specific contributors? +For example: Ensuring that a minimal set of tools required for contribution to Fedora are installed by default eases the onboarding of new contributors. TIP: When a Change has multiple benefits, it's better to list them all. === Scope * Proposal owners: What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes? -* Other developers: *REQUIRED FOR SYSTEM WIDE CHANGES* What work do other developers have to accomplish to complete the feature in time for release? +* Other developers: *REQUIRED FOR SYSTEM-WIDE CHANGES* What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes? -* Release engineering: *REQUIRED FOR SYSTEM WIDE CHANGES* Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? +* Release engineering: *REQUIRED FOR SYSTEM-WIDE CHANGES* Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuild required? -Include a link to the releng issue. +Include a link to the releng issue. The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication. * Policies and guidelines: Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? @@ -138,11 +138,11 @@ If a FPC ticket exists, add a link here. Where possible, file a pull request against the appropriate policy documents _before submitting the change proposal_. That way, the community and FESCo can evaluate the specific changes required. * Trademark approval: If your Change may require trademark approval (for example, if it is a new Spin), file a https://pagure.io/Fedora-Council/tickets/issues[Fedora Council ticket] requesting trademark approval. -* Alignment with Objectives: Does your proposal align with the https://docs.fedoraproject.org/en-US/project/objectives/[current Fedora Objectives]? This will not apply to many Changes, but it's important to consider when proposing a Change. -Being out of alignment isn't an automatic rejection, it's just one more aspect to consider. +* Alignment with Objectives: Does your proposal align with the xref:project::objectives.adoc[current Fedora Objectives]? This will not apply to many Changes, but it's important to consider when proposing a Change. +Being out of alignment isn't an automatic rejection, it's just one more aspect to consider. === Upgrade/compatibility impact -*REQUIRED FOR SYSTEM WIDE CHANGES* +*REQUIRED FOR SYSTEM-WIDE CHANGES* What happens to systems that have had a previous versions of Fedora Linux installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? @@ -151,7 +151,7 @@ Will any existing functionality be no longer supported? This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done. If it needs to be tested with different hardware or software configurations, indicate them. -The more specific you can be, the better the community testing can be. +The more specific you can be, the better the community testing can be. Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change. @@ -171,9 +171,10 @@ This section should be primarily about the User Experience, written in a way tha More detailed technical description should be left for the Benefit to Fedora section. Describe what Users will see or notice, for example: + * Packages are compressed more efficiently, making downloads and upgrades faster by 10%. * Kerberos tickets can be renewed automatically. Users will now have to authenticate less and become more productive. Credential management improvements mean a user can start their work day with a single sign on and not have to pause for reauthentication during their entire day. -* Libreoffice is one of the most commonly installed applications on Fedora Linux and it is now available by default to help users "hit the ground running". +* LibreOffice is one of the most commonly installed applications on Fedora Linux and it is now available by default to help users "hit the ground running". * Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora Linux users being the most relaxed users of any operating system. === Dependencies @@ -185,13 +186,12 @@ Other upstream projects like the kernel (if this is not a kernel change)? === Contingency Plan *REQUIRED FOR SYSTEM-WIDE CHANGES* - If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). -If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. +If your feature is not completed in time, we want to assure others that other parts of Fedora will not be in jeopardy. -A contigency plan should include: +A contingency plan should include: * Contingency mechanism: (What to do? Who will do it?) * Contingency deadline: When is the last time the contingency mechanism can be put in place? @@ -207,8 +207,8 @@ Link to that material here so other interested developers can get involved. === Release Notes The Fedora Linux Release Notes inform end-users about what is new in the release. -Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ +Examples of past release notes are here: https://docs.fedoraproject.org/en-US/fedora/latest/release-notes/ The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this change, indicate them here. A link to upstream documentation will often satisfy this need. -This information forms the basis of the release notes edited by the documentation team and shipped with the release. +This information forms the basis of the release notes edited by the documentation team and shipped with the release. diff --git a/modules/ROOT/pages/changes_policy.adoc b/modules/ROOT/pages/changes_policy.adoc index 5509f28..f9ff3fa 100644 --- a/modules/ROOT/pages/changes_policy.adoc +++ b/modules/ROOT/pages/changes_policy.adoc @@ -17,15 +17,15 @@ Watch the https://www.youtube.com/watch?v=oERoxg-VYPo[Fedora Changes policy vide The motivation for the Changes process is to raise the visibility of planned changes and make coordination and planning effort easier. It is nearly impossible to follow all changes happening in a big project such as Fedora. By providing a mechanism for sharing changes, it is easier for contributors to know what is coming and to ensure that we can address impacts of changes well before the release date. -Change proposals should be shared as early as possible, before the change is implemented and even in the very early state of the idea, to gather community feedback and review. +Change proposals should be shared as early as possible, before the change is implemented and even in the very early state of the idea, to gather community feedback and review. The list of accepted changes, or _change set_, is used by different teams across the project. -For example, the change set may be used to prepare external facing materials like release notes and release announcements. +For example, the change set may be used to prepare external facing materials like release notes and release announcements. Change owners are trusted _and depended upon_ to highlight all relevant changes. -Not noting important changes (whether due to oversight, different opinion of importance, or intentionally) breaks the Change process. +Not noting important changes (whether due to oversight, different opinion of importance, or intentionally) breaks the Change process. -The Change process is an internal planning and tracking tool, and the final release is not required to reflect all proposed changes. +The Change process is an internal planning and tracking tool, and the final release is not required to reflect all proposed changes. == Change Categories Fedora Engineering and Steering Committee (FESCo) has defined two Change categories: @@ -34,14 +34,14 @@ Fedora Engineering and Steering Committee (FESCo) has defined two Change categor 2. System-wide changes === Self-Contained Changes -A self-contained change is a change to isolated package(s), or a general change with limited scope and impact on the rest of distribution/project. +A self-contained change is a change to isolated package(s), or a general change with limited scope and impact on the rest of the distribution/project. Examples include addition of a group of leaf packages, or a coordinated effort within a Special Interest Group (SIG) with limited impact outside the SIG's functional area. Self-contained changes could be used for early idea state proposals for wider and complex changes. xref:releases::spins/creating.adoc[Creating a new Solution] (e.g. a Spin/Lab) is a Self-Contained Change. -Public announcement of a new self contained change promotes cooperation on the change, and extends its visibility. +Public announcement of a new self-contained change promotes cooperation on the change, and extends its visibility. Change owners may find help from the community or useful comments. -Based on the community review, the self contained change can be updated to the system-wide change category, and the owner may be asked to provide more details and extend the change proposal page. +Based on the community review, the self-contained change can be updated to the system-wide change category, and the owner may be asked to provide more details and extend the change proposal page. === System-Wide Changes System-wide changes involve system-wide defaults, critical path components, or other changes that are not eligible as self-contained changes. @@ -52,6 +52,7 @@ Promoting a deliverable to Edition status is a System-Wide Change by xref:counci .Change proposal sections |=== |Element|Self-Contained|System-Wide + |Summary|required|required |Owner|required|required |Current status|required|required @@ -76,7 +77,7 @@ Promoting a deliverable to Edition status is a System-Wide Change by xref:counci == Essential Communication === Fedora Packaging Committee -For changes that require modifications to the https://docs.fedoraproject.org/en-US/packaging-guidelines/[Fedora Packaging Guidelines]: +For changes that require modifications to the xref:packaging-guidelines::index.adoc[Fedora Packaging Guidelines]: * The person or group proposing the Change is responsible for providing a first draft of packaging guideline changes to the FPC. * Ideally, this draft will be available as a pull request _before submitting the Change proposal_ so that the community and FESCo can evaluate the specific changes. @@ -99,11 +100,11 @@ This is the general flow for change proposals: This includes Release Engineering, Fedora Packaging Committee, and trademark approval tickets where necessary. * Once the change proposal is correct, the Program Manager announces it on the devel-announce and devel mailing lists. * The Program Manager files a FESCo ticket no sooner than a week after the announcement on the mailing list. -** FESCo will vote to approve or deny a change proposal in accordance with the xref:fesco:ROOT:index.adoc#_ticket_policy[FESCo ticket policy] +** FESCo will vote to approve or deny a change proposal in accordance with the xref:fesco:ROOT:index.adoc#_ticket_policy[FESCo ticket policy]. ** Any team can share their views on the devel mailing list and escalate a proposed change to FESCo. The change owner may be asked to provide more details or address proposed concerns. FESCo members are encouraged to ask questions on the mailing list instead of waiting for the meeting. -** Optionally, FESCo assigns the change to one of the FESCo members or a trusted community member within the functional area (a _change shepherd_), who follows the detailed status of the change with FESCo and helps with processes within Fedora. For example, the change shepherd may communicate high-impact aspects of the change, or point out that a buildroot will be neccessary. The shepherd follows the status of the change until final release. +** Optionally, FESCo assigns the change to one of the FESCo members or a trusted community member within the functional area (a _change shepherd_), who follows the detailed status of the change with FESCo and helps with processes within Fedora. For example, the change shepherd may communicate high-impact aspects of the change, or point out that a buildroot will be necessary. The shepherd follows the status of the change until final release. * Change owners are encouraged to subscribe to the FESCo ticket once it has been created by the Program Manager. * The Program Manager will create Bugzilla trackers in the _Changes Tracking_ component and issues in the Release Notes repository for approved changes. * FESCo will re-review the status of changes one week before the beta freeze. @@ -120,7 +121,7 @@ NOTE: In most cases, you should not submit code changes to Rawhide until after F New change proposals may be submitted using the guidelines described elsewhere and until the appropriate change proposal submission deadline. For a given release, this date is available in the https://fedorapeople.org/groups/schedule/[release schedule] and will be announced well in advance. -NOTE: Changes to not have to be accepted by this deadline, but they must have been submitted to the Program Manager by then. +NOTE: Changes do not have to be accepted by this deadline, but they must have been submitted to the Program Manager by then. ==== Code complete (testable) deadline @@ -131,11 +132,11 @@ NOTE: Changes to not have to be accepted by this deadline, but they must have be NOTE: At this point, Rawhide and the immediately-upcoming "N+1" release are already separate branches. If development, testing, integration — and integration testing! — are not really all lined up by this point, there is no shame in re-targeting for the next (N+2) release. Now is the time for you to bring that to FESCo. -Or, if this change is time-sensitive but needs more resources or attention from across the community, bring that to FESCo, to the Fedora Council, and to the Fedora community at large. +Or, if this change is time-sensitive, but needs more resources or attention from across the community, bring that to FESCo, to the Fedora Council, and to the Fedora community at large. ==== Code complete (100%) deadline -* Changes must be code complete, meaning all the code required to enable to the new change is finished. +* Changes must be code complete, meaning all the code required to enable the new change is finished. * The level of code completeness is reflected as tracker bug state *ON_QA*. The change does not have to be fully tested by this deadline. @@ -148,6 +149,7 @@ Approved change proposals will have Bugzilla issues created by the Program Manag .Bugzilla tracker statuses |=== |BZ Status|Meaning + |ASSIGNED|Change approved by FESCo |MODIFIED|Change is code complete enough to be testable |ON_QA|Change is 100% code complete diff --git a/modules/ROOT/pages/covid19.adoc b/modules/ROOT/pages/covid19.adoc index 25a1c30..a4497fe 100644 --- a/modules/ROOT/pages/covid19.adoc +++ b/modules/ROOT/pages/covid19.adoc @@ -10,7 +10,8 @@ This document is maintained by the Fedora Program Manager (Ben Cotton) with the .Project status |=== -|Project |Status +|Project|Status + |Fedora 35{set:cellbgcolor:!}|On track{set:cellbgcolor:green} |=== @@ -44,6 +45,7 @@ This document is maintained by the Fedora Program Manager (Ben Cotton) with the .Points of contact |=== |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) |Infrastructure|Kevin Fenzi|kfenzi AT redhat DOT com|Oregon, US (Pacific) diff --git a/modules/ROOT/pages/elections.adoc b/modules/ROOT/pages/elections.adoc index 0e5aee4..9f005ef 100644 --- a/modules/ROOT/pages/elections.adoc +++ b/modules/ROOT/pages/elections.adoc @@ -25,7 +25,7 @@ Dates may change based on the final release date. From the set of collected questions for nominees to FESCo (Engineering), Fedora Council, and Mindshare|Mindshare teams, top 3 questions are selected, based on https://pagure.io/Fedora-Council/tickets/issue/156[Council decision]. The selected questions will be given to each candidate to answer before the voting period begins as part of campaign. -The top selected questions for each body are put in teamplates in the elections-interviews repo (`ssh://git@pagure.io/tickets/fedora-pgm/elections-interviews.git`). +The top selected questions for each body are put in templates in a non-public part of the elections-interviews repo (`ssh://git@pagure.io/tickets/fedora-pgm/elections-interviews.git`). === Nominations for Elected Positions During this period people may self-nominate to open seats. @@ -37,7 +37,7 @@ In this way, only the Program Manager and Fedora Action and Impact Coordinator ( === Voting Setup & Validation & Publishing of interviews It is the responsibility of the Program Manager 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 aprivate issue in Pagure]) are excluded from the list of nominees. +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. diff --git a/modules/ROOT/pages/index.adoc b/modules/ROOT/pages/index.adoc index 19aabae..c3f882d 100644 --- a/modules/ROOT/pages/index.adoc +++ b/modules/ROOT/pages/index.adoc @@ -1,6 +1,6 @@ = Fedora Program Management -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://apps.fedoraproject.org/calendar/council/#m9570[0900] or https://apps.fedoraproject.org/calendar/meeting/9915/[1600] (America/Indiana/Indianapolis) Wednesdays in #fedora-meeting-1. +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]. 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]. @@ -12,11 +12,11 @@ Within the Fedora Project, the Program Manager (FPgM) is primarily responsible f * planning and http://fedorapeople.org/groups/schedule/[scheduling] of xref:releases::index.adoc[Fedora Linux releases] * tracking the https://fedoraproject.org/wiki/Changes[changes] during the development cycle * release coordination (with QA, Release Engineering, FESCo, etc.) -* xref:elections/index.adoc[elections] management +* xref:elections.adoc[elections] management * leading the xref:pgm_team.adoc[Program Management Team] -* serving as an auxillary member of the xref:council::index.adoc[Fedora Council] +* serving as an auxiliary member of the xref:council::index.adoc[Fedora Council] -The position is currently held by https://fedoraproject.org/wiki/User:Bcotton[Ben Cotton]. +The position is currently held by https://fedoraproject.org/wiki/User:Bcotton[Ben Cotton]. == Release Planning * https://fedorapeople.org/groups/schedule/[Release schedules] @@ -25,4 +25,4 @@ The position is currently held by https://fedoraproject.org/wiki/User:Bcotton[Be === Program management SOPs -The xref:pgm_guide/index.adoc[Program Management Guide] contains documentation for how to perform program management functions in Fedora +The xref:pgm_guide/index.adoc[Program Management Guide] contains documentation for how to perform program management functions in Fedora, i.e. Standard Operating Procedures (SOPs). diff --git a/modules/ROOT/pages/pgm_guide/changes.adoc b/modules/ROOT/pages/pgm_guide/changes.adoc index a3da9c9..b556d95 100644 --- a/modules/ROOT/pages/pgm_guide/changes.adoc +++ b/modules/ROOT/pages/pgm_guide/changes.adoc @@ -1,12 +1,13 @@ = Changes Process + Fedora's Change Process is important to coordinate the development of the next Fedora release. -We need to know about disrupting changes coming to the next release to set the scope of release but it also helps as marketing tool even for leaf changes. -For more details on Change Process, see the https://fedoraproject.org/wiki/Changes/Policy[Changes Policy]. +We need to know about disrupting changes coming to the next release to set the scope of release, but it also helps as marketing tool even for leaf changes. +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 Changes Process — scheduling, submission, announcements, reporting and tracking. One of the main responsibilities is helping Change owners through the submission process. -The Program Manager works on the https://fedoraproject.org/wiki/Changes/Policy[Changes Policy] with the https://docs.fedoraproject.org/en-US/fesco/[Fedora Engineering Steering Committee] (FESCo), Working Groups and other Fedora teams and bodies (documentation, marketing, etc.). +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.). == SOP The SOP consists of two phases: Change submissions and Changes tracking. @@ -14,12 +15,12 @@ The SOP consists of two phases: Change submissions and Changes tracking. === Submission Change submission is done in the Fedora Project Wiki. -* Set up infrastructure for Changes on the Fedora Project Wiki (for a new release) — correct categories, ChangeSet page etc +* Set up infrastructure for Changes on the Fedora Project Wiki (for a new release) — correct categories, ChangeSet page etc. ** Create `Category:ChangeAcceptedFXX`, where XX is Fedora version ** Create `Releases/XX/ChangeSet` page, where XX is Fedora version * Each change has to be proposed by Change Owner. -Once Change category is set to `ChangeReadyForWrangler`, checks formal correctness - all required fields are filled in, right category is set, page structure is correct (important, as scripts are used to parse the document). +Once Change category is set to `ChangeReadyForWrangler`, check formal correctness - all required fields are filled in, right category is set, page structure is correct (important, as scripts are used to parse the document). ** If a proposal has missing, incomplete, or confusing information, set the category back to `ChangePageIncomplete` and email the change owner(s) to let them know what you're looking for. * Once Change page is correct enough, it has to be announced on devel-announce and devel mailing lists. ** Include the version, type (Self-Contained or System-Wide), and title in the email subject @@ -48,7 +49,7 @@ TIP: Submitting to both mailing lists at the same time will give the threads ide === Tracking ==== Create tracking bug -After a change is accepted, you can use the scripts in the https://pagure.io/fedora-pgm/change-management[change-management repo] to create Bugzilla bugs. +After a change is accepted, you can use the scripts in the https://pagure.io/fedora-pgm/pgm_scripts[pgm_scripts repo] to create Bugzilla bugs. 1. Run `make version= type= build` to pull the contents of change proposals 2. Run `make bz` to create Bugzilla tracking bugs @@ -60,7 +61,7 @@ After a change is accepted, you can use the scripts in the https://pagure.io/fed 5. Create an issue in the https://pagure.io/fedora-docs/release-notes/new_issue[Release Notes tracker] and add that URL to the wiki page in the *Current Status* section WARNING: The Bugzilla script isn't very smart. -If you re-run it (e.g. to correct an email address), it will create duplicate bugs for any changes it already processed. +If you re-run it (e.g. to correct an email address), it will create duplicate bugs for any changes it already processed. Edit the `feature-pages.csv` file to remove already-processed bugs or run `make clean` and re-run steps 1 and 2 above. TIP: The Bugzilla API will reject email addresses that don't exist in Bugzilla. @@ -88,7 +89,7 @@ Work with Change Owners during this two weeks to collect status for FESCo. Use m The day after the deadline, open a https://pagure.io/fesco/new_issue[FESCo ticket] with Changes that did not meet required status. See https://pagure.io/fesco/issue/2218[FESCo #2218] for an example. -WARNING: We don't have a good way of tracking the contigency deadline for Changes with a contingency plan. +WARNING: We don't have a good way of tracking the contingency deadline for Changes with a contingency plan. This essentially means we trust Change owners to self-enforce. If you want to make life better, come up with a better solution. diff --git a/modules/ROOT/pages/pgm_guide/council.adoc b/modules/ROOT/pages/pgm_guide/council.adoc index 06963e9..cf8d109 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 auxillary member. +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]. 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 160e521..a8c7b1a 100644 --- a/modules/ROOT/pages/pgm_guide/elections.adoc +++ b/modules/ROOT/pages/pgm_guide/elections.adoc @@ -4,10 +4,10 @@ The Fedora Program Manager is responsible for conducting elections for various b After each release, the Fedora Council, Mindshare Committee, and Fedora Engineering Steering Committee run elections. Other teams may request elections if they have a need. -The Fedora Community Action and Impact Coordinator (FCAIC) is the backup elections wranger. +The Fedora Community Action and Impact Coordinator (FCAIC) is the backup elections wrangler. The FCAIC & FPgM cannot be candidates for elected positions. -NOTE: FESCo has a https://docs.fedoraproject.org/en-US/fesco/FESCo_election_policy/[separate election policy] that requires more candidates than open seats. +NOTE: FESCo has a xref:fesco::FESCo_election_policy.adoc[separate election policy] that requires more candidates than open seats. == Pre-voting @@ -37,7 +37,7 @@ Perhaps you would like to extend the voting app to allow nomination and election * Convert interviews to community blog ** One post per-candidate -** Include FAS acocunt, IRC, wiki page (see previous examples) +** Include FAS account, IRC, wiki page (see previous examples) ** Set the candidate as the author * Write a wrap-up post (look at 2017 elections interview as example). link to interview post and user wiki @@ -55,7 +55,7 @@ The elections app runs on https://elections.fedoraproject.org[elections.fedorapr * maximum range: # of candidates * URL: link to wiki page with nominations * Admin groups: automatically includes the elections group -* When adding users, add link to interview on commblog +* When adding users, add link to interview on Community Blog * Edit the link:https://fedoraproject.org/wiki/Template:Election_Banner[election banner template] in the wiki to update the dates and current status WARNING: The “Candidates are FAS users?” validation check is buggy, don't use it. @@ -87,7 +87,7 @@ Ben Cotton hopes to have this fixed before Fedora 32 elections. * Update the link:https://fedoraproject.org/wiki/FESCo_meeting_process[meeting process wiki page]. === Mindshare -* Update permissions on link:https://pagure.io/group/fedora-mindshare[Mindshare Pagure group] +* Update permissions on link:https://pagure.io/group/fedora-mindshare[Mindshare Pagure group]. * Update the https://pagure.io/mindshare/blob/master/f/website/modules/ROOT/pages/index.adoc[Mindshare members section]. TIP: Convincing teams to give you admin access to things will make life easier. diff --git a/modules/ROOT/pages/pgm_guide/getting_started.adoc b/modules/ROOT/pages/pgm_guide/getting_started.adoc index 2923720..b8ff10d 100644 --- a/modules/ROOT/pages/pgm_guide/getting_started.adoc +++ b/modules/ROOT/pages/pgm_guide/getting_started.adoc @@ -6,12 +6,12 @@ Whether you're new to Red Hat, to the Fedora Community, or both, there's a lot t Here's a list of things you'll need to get started: == Fedora Account System (FAS) -You can't do much of anything in Fedora without this. Visit the https://admin.fedoraproject.org/accounts/user/new[account signup page] to create an account. If you already have one from your previous work with Fedora, then you're all set. +You can't do much of anything in Fedora without this. Visit the https://accounts.fedoraproject.org[account signup page] to create an account. If you already have one from your previous work with Fedora, then you're all set. === FAS Groups * *elections* — Used to manage the xref:elections.adoc[elections]. * *council* — Grants access to Council-related things -* *gitfedora-project-schedule* — Grants access to the xref:schedule.adoc[schedule] project on fedorapeople.org +* *gitfedora-project-schedule* — Grants access to the xref:pgm_guide/schedule.adoc[schedule] project on fedorapeople.org == Mailing lists @@ -27,17 +27,17 @@ Some you can self-subscribe to, others you will need to be added to. You can joi * *https://lists.fedoraproject.org/archives/list/triage@lists.fedoraproject.org/[triage]* — Discussion for xref:prioritized_bugs.adoc[prioritized bugs] === Red Hat mailing lists -* *http://post-office.corp.redhat.com/mailman/listinfo/fedora-infrastructure[Fedora infrastructure]* -* *http://post-office.corp.redhat.com/mailman/listinfo/fedora-redhat[Fedora-Red Hat]* +* *https://listman.redhat.com/mailman/listinfo/fedora-infrastructure-list/[Fedora infrastructure]* +* *https://listman.redhat.com/mailman/listinfo/fedora-list/[Fedora-Red Hat]* == Pagure groups * *https://pagure.io/group/Fedora-Council[Fedora-Council]* * *https://pagure.io/group/fedora-pgm[fedora-pgm]* == Other tools -* *https://smartsheet.com[Smartsheet]* — This is where the xref:schedule.adoc[scheduling] magic happens +* *https://smartsheet.com[Smartsheet]* — This is where the xref:pgm_guide/schedule.adoc[scheduling] magic happens * *https://pp.engineering.redhat.com/pp/[Product Pages] admin access* — This is the Red Hat internal tracking tool for products. To request access, fill out the https://docs.google.com/forms/d/e/1FAIpQLSdX2lc4n3AT7rHyth_lNpZAJ-7JMsCHiyfDnQJC92jS2eYQOA/viewform[PLM+ACI Google Form] (Red Hat only) * *https://bugzilla.redhat.com[Bugzilla]* — You will also need to request membership in the *editcomponents* group so that you can modify the Fedora component as needed. -More Red Hat internal setup information is in the https://docs.google.com/document/d/1giFWzeOp-_WVH-CZgYKFYlOF9Zre5aDGymOwmVhdm7U/edit[Engingeering Program Management Guide]. +More Red Hat internal setup information is in the https://docs.google.com/document/d/1giFWzeOp-_WVH-CZgYKFYlOF9Zre5aDGymOwmVhdm7U/edit[Engineering Program Management Guide]. diff --git a/modules/ROOT/pages/pgm_guide/inactive_provenpackagers.adoc b/modules/ROOT/pages/pgm_guide/inactive_provenpackagers.adoc index a9e295a..7e55fbd 100644 --- a/modules/ROOT/pages/pgm_guide/inactive_provenpackagers.adoc +++ b/modules/ROOT/pages/pgm_guide/inactive_provenpackagers.adoc @@ -2,12 +2,12 @@ The `provenpackagers` group grants members write privileges across all Fedora packages. 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 https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_maintaining_provenpackager_status[maintaining provenpackager status]. +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. This should take place at about the branch point of each development cycle. -The https://pagure.io/fedora-pgm/pgm_communication/blob/main/f/scripts/provenpackager/inactive_provenpackagers.py[inactive_provenpackagers.py] script will check for provenpackagers that have not submitted a Koji build in the last six months. +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. It produces a list of accounts that fail this test, as well as accounts that do not exist in Koji. After running this script, send the output to the named accounts as well as devel-announce. diff --git a/modules/ROOT/pages/pgm_guide/pgm_communication.adoc b/modules/ROOT/pages/pgm_guide/pgm_communication.adoc index b7f9c39..40feadc 100644 --- a/modules/ROOT/pages/pgm_guide/pgm_communication.adoc +++ b/modules/ROOT/pages/pgm_guide/pgm_communication.adoc @@ -27,8 +27,8 @@ 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:_office_hours[FPgM office hours] as regular entries. -I also include the xref:release_process#_gono_go_meeting[Go/No-Go] and xref:release_process#_release_readiness_meeting[Release Readiness] meetings when appropriate. +I generally include Council meetings, blocker review meetings, prioritized bugs meetings, and the xref:_fpgm_office_hours[FPgM 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). ** *Schedule* — Upcoming schedule milestones, generally within the next month @@ -41,7 +41,7 @@ I include this once I begin producing the xref:_blocker_report[blocker bug repor === CfP sources -There's no one, unified place to get relevant CfPs, +There's no one, unified place to get relevant CfPs. Pay attention to social media (particularly upstream accounts), etc. You can also use: diff --git a/modules/ROOT/pages/pgm_guide/prioritized_bugs.adoc b/modules/ROOT/pages/pgm_guide/prioritized_bugs.adoc index b015b07..e0da8f2 100644 --- a/modules/ROOT/pages/pgm_guide/prioritized_bugs.adoc +++ b/modules/ROOT/pages/pgm_guide/prioritized_bugs.adoc @@ -1,14 +1,14 @@ = Prioritized Bugs -The link:../../prioritized_bugs[Prioritized Bugs] process is designed to get attention for issues that are not blockers but are still high-impact or high-visibility. +The link:../../prioritized_bugs[Prioritized Bugs] process is designed to get attention for issues that are not blockers, but are still high-impact or high-visibility. The criteria are intentionally subjective and we will drop bugs from the list if we can't convince developers to make progress. We run the meeting every two weeks. It is open to anyone, but in practice it's usually the FPgM and FPL who attend. Send the nominated and open accepted bugs a day in advance to the triage (and optionally test and devel) mailing list. -On Fridays (or whatever day you prefer), it's good to review the accepted Prioritizied Bugs and make sure they're not getting stale. -See the link:/program_management/prioritized_bugs#_process_for_accepted_bugs[process documentation] for guidance on how to give nudges. +On Fridays (or whatever day you prefer), it's good to review the accepted Prioritized Bugs and make sure they're not getting stale. +See the link:../../prioritized_bugs#_process_for_accepted_bugs[process documentation] for guidance on how to give nudges. TIP: Invite the assignees of nominated and accepted bugs so they can provide input. diff --git a/modules/ROOT/pages/pgm_guide/release_process.adoc b/modules/ROOT/pages/pgm_guide/release_process.adoc index 6b123ff..890aa20 100644 --- a/modules/ROOT/pages/pgm_guide/release_process.adoc +++ b/modules/ROOT/pages/pgm_guide/release_process.adoc @@ -82,12 +82,12 @@ for these keepalives. .... A couple of days before the deadline, send an email to spins and devel-announce mailing lists saying which ones will be retired. -If no one adopts them, file a ticket with Release Engineering to stop producing the spin and with the Websties team to remove them from the website for the next release. +If no one adopts them, file a ticket with Release Engineering to stop producing the spin and with the Websites team to remove them from the website for the next release. NOTE: You can be really flexible with the deadline, as RelEng does not need much lead time to stop making something. NOTE: Ignore the Test Days spin. -It's useful to QA but we don't release it publicly. +It's useful to QA, but we don't release it publicly. == Rawhide Rebase Warning * Send the message below to devel-announce@lists.fedoraproject.org 1–3 weeks before the branch point. @@ -131,10 +131,10 @@ Adjust wording of the https://bugzilla.redhat.com/editproducts.cgi?action=edit&p .... Bugs related to the components of the Fedora distribution. If you are reporting a bug -against a stable release or a branched pre-release version please select that -version number. The currently maintained released versions are: Fedora N-1, Fedora N. -The branched pre-released version is Fedora N+1. If you have a bug to report against -the daily development tree (rawhide) please choose 'rawhide' as the version. +against a stable release or a branched pre-release version, please select that +version number. The currently maintained released versions are: Fedora N-1, Fedora N. +The branched pre-released version is Fedora N+1. If you have a bug to report against +the daily development tree (rawhide), please choose 'rawhide' as the version. For more information about filing a bug against Fedora packages, see https://docs.fedoraproject.org/en-US/quick-docs/howto-file-a-bug/ @@ -144,7 +144,7 @@ https://docs.fedoraproject.org/en-US/quick-docs/howto-file-a-bug/ * Create N+1 in Bugzilla's https://bugzilla.redhat.com/editversions.cgi?product=Fedora[Fedora] and https://bugzilla.redhat.com/editversions.cgi?product=Fedora%20Container%20Images[Fedora Container Images] product versions. === Rawhide Rebase -All of the following condiditions must be met: +All of the following conditions must be met: * product == "Fedora" or "Fedora Container Images" * version == rawhide @@ -179,7 +179,7 @@ It has become the place to file these bugs, even if not against the rawhide kern == Go/No-Go meeting Before each public release, FESCo, QA, and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the https://fedoraproject.org/wiki/Go_No_Go_Meeting[Go/No-Go Meeting]. -FPgM is responsibile for scheduling and leading this important meeting. +FPgM is responsible for scheduling and leading this important meeting. === Occurrence This meeting is held for every public release (Beta and Final) and may reoccur for each milestone if the release slips. Meetings are generally held the Thursday before a target release date. @@ -187,7 +187,7 @@ This meeting is held for every public release (Beta and Final) and may reoccur f === SOP ==== Pre-meeting -* Schedule the meeting in Fedocal's https://apps.fedoraproject.org/calendar/Fedora%20release/[Fedora release] calendar. The Go/No-Go meeting is traditionally held on the Thursday prior to the release date from 17:00–19:00 UTC. +* Schedule the meeting in Fedocal's https://calendar.fedoraproject.org/Fedora%20release/[Fedora release] calendar. The Go/No-Go meeting is traditionally held on the Thursday prior to the release date from 17:00–19:00 UTC. Select an available meeting channel. #fedora-meeting-1 has generally been available at this slot. It is best to set the meeting to recur weekly for 3 weeks in case of multiple slips. @@ -215,6 +215,7 @@ However for small issues that can be fixed for the next compose, we may choose t If the release is still no-go at that point, the next meeting should happen on Thursday as regularly scheduled. ===== IRC script + .... #startmeeting F31 Beta Go/No-Go meeting #meetingname F31-Beta-Go_No_Go-meeting @@ -248,7 +249,7 @@ QA? #agreed Fedora 31 Beta is GO #info Fedora 31 Beta will release on 2019-09-17 - --- or --- + --- or --- #agreed Fedora 31 Beta is NO-GO #info The next F31 Beta Go/No-Go meeting will be Thursday, 2019-09-19 at 1700 UTC @@ -280,10 +281,10 @@ Adjust wording of the https://bugzilla.redhat.com/editproducts.cgi?action=edit&p .... Bugs related to the components of the Fedora Linux distribution. If you are reporting a -bug against a stable release or a branched pre-release version please select that +bug against a stable release or a branched pre-release version please select that version number. The currently maintained released versions are: Fedora Linux N-2, Fedora Linux N-1, and Fedora Linux N. If you have a bug to report against the daily -development tree (rawhide) please choose 'rawhide' as the version. +development tree (rawhide), please choose 'rawhide' as the version. For more information about filing a bug against Fedora Linux packages, see https://docs.fedoraproject.org/en-US/quick-docs/howto-file-a-bug/ @@ -322,8 +323,8 @@ For example, to warn that Fedora 29 will be EOL on 19 November 2019: WARNING: This script will take a while to run. Execute it from a machine with stable power and networking. -TIP: By default, the script will check to see that the version of the bug matches the EOL version you specfify. -You will need to add the version field to your bugzilla query for this to work. +TIP: By default, the script will check to see that the version of the bug matches the EOL version you specify. +You will need to add the version field to your Bugzilla query for this to work. If for some reason you like to live dangerously, you can set `CHECK_VERSION = 0` in the script. == EOL day @@ -347,8 +348,8 @@ For example, to close Fedora 29 bugs with an EOL date of 19 November 2019: WARNING: This script will take a while to run. Execute it from a machine with stable power and networking. -TIP: By default, the script will check to see that the version of the bug matches the EOL version you specfify. -You will need to add the version field to your bugzilla query for this to work. +TIP: By default, the script will check to see that the version of the bug matches the EOL version you specify. +You will need to add the version field to your Bugzilla query for this to work. If for some reason you like to live dangerously, you can set `CHECK_VERSION = 0` in the script. === Update product description @@ -356,9 +357,9 @@ Adjust wording of the https://bugzilla.redhat.com/editproducts.cgi?action=edit&p .... Bugs related to the components of the Fedora distribution. If you are reporting a bug -against a stable release or a branched pre-release version please select that -version number. The currently maintained released versions are: Fedora N-1, Fedora N. -If you have a bug to report against the daily development tree (rawhide) please choose +against a stable release or a branched pre-release version, please select that +version number. The currently maintained released versions are: Fedora N-1, Fedora N. +If you have a bug to report against the daily development tree (rawhide), please choose 'rawhide' as the version. For more information about filing a bug against Fedora packages, see @@ -367,7 +368,6 @@ https://docs.fedoraproject.org/en-US/quick-docs/howto-file-a-bug/ === Disable EOL version * Disable the EOL release in Bugzilla's https://bugzilla.redhat.com/editversions.cgi?product=Fedora[Fedora] and https://bugzilla.redhat.com/editversions.cgi?product=Fedora%20Container%20Images[Fedora Container Images] product versions. -. === Wiki and website edits diff --git a/modules/ROOT/pages/pgm_guide/schedule.adoc b/modules/ROOT/pages/pgm_guide/schedule.adoc index b22fa7d..9c6c9af 100644 --- a/modules/ROOT/pages/pgm_guide/schedule.adoc +++ b/modules/ROOT/pages/pgm_guide/schedule.adoc @@ -11,7 +11,7 @@ This may mean adding, removing, or moving some tasks. Or it might mean changing which teams are reflecting in the https://fedorapeople.org/groups/schedule/[web view] of the schedule. NOTE: FESCo https://pagure.io/fesco/issue/2329[authorized] Release Engineering to start the mass rebuild up to five days after the scheduled start date. -This allows RelEng to accomodate travel for Flock and DevConf.CZ, which often fall near the start of the mass rebuild. +This allows RelEng to accommodate travel for Flock and DevConf.CZ, which often fall near the start of the mass rebuild. == Smartsheet @@ -22,7 +22,7 @@ In your new schedule: * Update the “Fedora XX Release” * Find and replace N-1 with N (have to do it manually so as to not get dates) -* Find and replace N-3 with N-1 (same) +* Find and replace N-2 with N-1 (same) Tasks are assigned to teams with flags. The `pp` flag has no meaning for the community, but is used to keep in sync with other Red Hat products. @@ -50,17 +50,19 @@ When schedules slip: The files used to publish the scripts live in a https://pagure.io/fedora-pgm/schedule[git repository]. To create a schedule for a new version (f-30 in this example): -1. `mkdir f-30` -2. `cp ../f-29/Makefile . && vi Makefile` # copy forward from previous and change the version -3. Export the XML file (see previous section) -4. `git add Fedora.Schedule.xml Makefile` -6. `git commit -m ‘Your commit message here’` -7. to see the changes locally: `make` (`make clean` cleans up your mess) -8. `make publish` #publish html and friends to fedorapeople -NOTE:: The rsync invocations in the Makefile assume you have your user name set in `~/.ssh/config` if your local name does not match your Fedora account. +. `mkdir f-30` +. `cp ../f-29/Makefile . && vi Makefile` # copy forward from previous and change the version +. Export the XML file (see previous section) +. `git add Fedora.Schedule.xml Makefile` +. `git commit -m ‘Your commit message here’` +. to see the changes locally: `make` # `make clean` cleans up your mess +. `make publish` # publish html and friends to fedorapeople + +NOTE: The rsync invocations in the Makefile assume you have your user name set in `~/.ssh/config` if your local name does not match your Fedora account. To update the index page of the website, or the CSS file used to style it, start from the schedule repo above: + 1. `cd html` 2. Edit the appropriate file 3. `make publish` to rsync to fedorapeople @@ -69,21 +71,21 @@ To update the index page of the website, or the CSS file used to style it, start == Product Pages -https://pp.engineering.redhat.com/[Product Pages] is the central resource for Red Hat product schedule and status information. - -To register a new verison in product pages: - -1.Go to admin page (*Platforms* > *Fedora Project* > *Overview*) -2. Click *Add new release* button -3. Short name: 30 -4. Select all the sections to copy -5. Click *OK* -7. Click *Schedules* tab -8. Click *Add schedules* button -9. Handle: -10. Switch draft to approved -11. Set phase to planning - +https://pp.engineering.redhat.com/[Product Pages] is the central resource for Red Hat internal product schedule and status information. + +To register a new version in product pages: + +. Go to admin page (*Platforms* > *Fedora Project* > *Overview*) +. Click *Add new release* button +. Short name: 30 +. Select all the sections to copy +. Click *OK* +. Click *Schedules* tab +. Click *Add schedules* button +. Handle: +. Switch draft to approved +. Set phase to planning + TIP: Prior to May 2021, we used a Red Hat CVS server for the schedule files. They now are pulled directly into Product Pages from Smartsheet. @@ -93,7 +95,7 @@ Key fields: * *Documents*: just make a link to the wiki * *People*: update this as appropriate * *Communication*: list of important IRC channels and mailing lists - + === Status updates Update the phases when there's a significant change (e.g. Beta release -> change to testing). @@ -103,7 +105,7 @@ Green means no risks and no slippage; you don't need to say much. Yellow means there are risks, but we have it under control. Describe what went wrong and how we're going to address it. Red means "oh noes!"; explain a lot more. - + == Historical notes This section is a collection of loosely-organized facts that give some of the history of schedule wrangling. diff --git a/modules/ROOT/pages/pgm_guide/sop/release-delay.adoc b/modules/ROOT/pages/pgm_guide/sop/release-delay.adoc index c29d243..bdb2e5f 100644 --- a/modules/ROOT/pages/pgm_guide/sop/release-delay.adoc +++ b/modules/ROOT/pages/pgm_guide/sop/release-delay.adoc @@ -3,8 +3,8 @@ The document outlines the procedure for delaying the release. Refer to the xref:releases::lifecycle.adoc#_schedule_contingency_planning[schedule contingency planning] docs for when to delay future milestones. -1. In xref:pgm_guide/schedule.adoc#_smartsheet_[Smartsheet], add a new milestone (if needed) and update the Current (Beta|Final) Target date milestone to have the new target date as a predecessor. -2. Save the updated shechedule to the xref:pgm_guide/schedule.adoc#_git_repo[git repository] and publish to the web. +1. In xref:pgm_guide/schedule.adoc#_smartsheet[Smartsheet], add a new milestone (if needed) and update the Current (Beta|Final) Target date milestone to have the new target date as a predecessor. +2. Save the updated schedule to the xref:pgm_guide/schedule.adoc#_git_repo[git repository] and publish to the web. 3. Update xref:pgm_guide/schedule.adoc#_product_pages[Product Pages]. If the new target date is beyond target date #1 or you have reason to believe the release will slip further, set the status to yellow. If the new target date is beyond target date #2 or you have reason to believe the release will slip further, set the status to red. diff --git a/modules/ROOT/pages/pgm_guide/sop/release-new.adoc b/modules/ROOT/pages/pgm_guide/sop/release-new.adoc index 02c411c..061cc74 100644 --- a/modules/ROOT/pages/pgm_guide/sop/release-new.adoc +++ b/modules/ROOT/pages/pgm_guide/sop/release-new.adoc @@ -18,7 +18,7 @@ If a Change proposal is submitted for the release, that's a good time to start t .. Set the description to "This is a tracking bug for FNN Changes." .. Click "Submit Bug" so you can add additional information .. Add "Tracking" to the Keywords field -.. Click "Show advanced fields", if they're not already visible +.. Click "Show advanced fields" if they're not already visible .. Click "Edit" on the Alias and set it to "FNNChanges" .. Click "Save Changes" . Add docs to the xref:releases::index.adoc[Releases] module diff --git a/modules/ROOT/pages/pgm_team.adoc b/modules/ROOT/pages/pgm_team.adoc index e6e9c4a..23e3029 100644 --- a/modules/ROOT/pages/pgm_team.adoc +++ b/modules/ROOT/pages/pgm_team.adoc @@ -8,7 +8,7 @@ The Program Management Team serves two functions: == Contacting the team If you wish to request help from the Program Management Team, https://pagure.io/fedora-pgm/pgm_team/new_issue?template=support_request[file an issue in the pgm_team repo]. -To contact the team for other matters, we can be reached on: +To contact the team for other matters, we can be reached on: * IRC : https://web.libera.chat/?channels=#fedora-pgm[#fedora-pgm] * Matrix : https://matrix.to/#/#pgm:fedoraproject.org?web-instance%5Belement.io%5D=chat.fedoraproject.org[#pgm:fedoraproject.org] @@ -65,6 +65,6 @@ However, other team members may be asked to fill in when the FPgM’s absence is These duties explicitly _do not_ include anything: * Requiring access to Red Hat internal resources -* Relating to the Legal Liaison role, as that role is coincidentally held by the current FPgM but not a part of the FPgM’s duties +* Relating to the Legal Liaison role, as that role is coincidentally held by the current FPgM, but not a part of the FPgM’s duties * Involving the FPgM’s role as a Fedora Council member * Related to Fedora elections, as the FCAIC provides backup to those duties diff --git a/modules/ROOT/pages/pgm_team/other_repos.adoc b/modules/ROOT/pages/pgm_team/other_repos.adoc index 0ee1307..005336c 100644 --- a/modules/ROOT/pages/pgm_team/other_repos.adoc +++ b/modules/ROOT/pages/pgm_team/other_repos.adoc @@ -12,7 +12,7 @@ This includes the weekly Friday's Fedora Facts on the Community Blog and scripts * https://pagure.io/fedora-pgm/pgm_scripts[pgm_scripts]. Scripts for wrangling changes, doing Bugzilla housekeeping, etc. Primarily this means parsing the wiki pages and creating new Bugzillas. -* https://pagure.io/fedora-pgm/schedule[schedule] +* https://pagure.io/fedora-pgm/schedule[schedule]. Tooling for managing the release schedule. * https://pagure.io/fedora-pgm/elections-interviews[elections-interviews]. The issues are used for elections interviews. diff --git a/modules/ROOT/pages/pgm_team/repo.adoc b/modules/ROOT/pages/pgm_team/repo.adoc index b57eb7d..c7f0318 100644 --- a/modules/ROOT/pages/pgm_team/repo.adoc +++ b/modules/ROOT/pages/pgm_team/repo.adoc @@ -18,11 +18,11 @@ The following guidelines apply: * Active work should be in a markdown file in the `current/` directory. * Previous work should be moved into the `past/` directory. * If you have additional supporting information with no better place to store it, create a directory with the same name as the markdown file. -* The top of the markdown file should contain basic information about the project (e.g. main contact, links to resources, etc) +* The top of the markdown file should contain basic information about the project (e.g. main contact, links to resources, etc.) * Put the latest updates at the top of the update section (so updates should appear newest to oldest) * Add updates as frequently as appropriate, but generally at least once a month. For most projects, once every one or two weeks is probably better. -* Include links to specific issues, etc that are blocking the work or that are major unresolved decisions. +* Include links to specific issues, etc. that are blocking the work or that are major unresolved decisions. TIP: Remember that these files are so that others can step in to help you if needed. Try to document what you'd want to know if you were coming into the project. @@ -48,15 +48,15 @@ Propose it! === Priorities -The respository intentionally does not have any priorities defined. +The repository intentionally does not have any priorities defined. We will need to use it for a while and see what naturally arises for us. === Boards -The respository intentionally does not have any boards set up. +The repository intentionally does not have any boards set up. We will need to use it for a while and see what naturally arises for us. === Roadmap -The respository intentionally does not have any roadmap milestones defined. +The repository intentionally does not have any roadmap milestones defined. We will need to use it for a while and see what naturally arises for us. diff --git a/modules/ROOT/pages/prioritized_bugs.adoc b/modules/ROOT/pages/prioritized_bugs.adoc index 0067f01..51e8fb5 100644 --- a/modules/ROOT/pages/prioritized_bugs.adoc +++ b/modules/ROOT/pages/prioritized_bugs.adoc @@ -28,7 +28,7 @@ This occasionally lead to collisions with how development teams used those field === Nomination -Issues eligible for this status are those which do not necessarily fail a release criterion but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective. +Issues eligible for this status are those which do not necessarily fail a release criterion, but which have critical impact on a Fedora Edition or on a council-approved Fedora Objective. Issues may also be nominated from the Common Bugs list when they are deemed by QA to have critical impact. Anyone from the Fedora community can nominate a bug to be evaluated for inclusion to the "Prioritized bugs and issues" list. @@ -41,11 +41,11 @@ 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 https://docs.fedoraproject.org/en-US/council/fpl/[Fedora Project Leader] (FPL), https://docs.fedoraproject.org/en-US/council/fpgm/[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::fpgm.adoc[Fedora Program Manager] (FPgM), 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. -The team of evaluators meets on regular bi-weekly meetings on Wednesdays at 11:00 AM US/Eastern in the #fedora-meeting-2 channel. +The team of evaluators meets on regular bi-weekly meetings on Wednesdays at 11:00 AM US/Eastern in the https://web.libera.chat/?channels=#fedora-meeting-1[#fedora-meeting-1] channel. See https://calendar.fedoraproject.org/base/[Base Fedocal] for the authoritative meeting schedule. The purpose of the regular meeting is to review bugs nominated to the "Prioritized bugs and issues" list and follow up on previously-approved bugs. @@ -66,10 +66,10 @@ This is a rough idea of what happens after a bug is accepted as a Prioritized Bu * 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 assginee outside of 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 -NOTE: The ecalation is not intended to be "this person isn't doing their job" in character. +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?" NOTE: When need dictates (e.g. a coming release milestone), the timeline above may be compressed. diff --git a/modules/ROOT/partials/bz_status.adoc b/modules/ROOT/partials/bz_status.adoc index aabbfd6..c403a9a 100644 --- a/modules/ROOT/partials/bz_status.adoc +++ b/modules/ROOT/partials/bz_status.adoc @@ -5,10 +5,10 @@ |NEW|The default state. Generally indicates bug has not been actively investigated by the assignee. |ASSIGNED|Can be used by maintainers to indicate that the bug has been vetted and is assigned for work. |ON_DEV|Can be used by maintainers to indicate that work is actively in progress. This is especially useful if there exists a team of maintainers for a package. -|POST|Indicates a fix is ready but not applied. This is often used when a pull request is open upstream. +|POST|Indicates a fix is ready, but not applied. This is often used when a pull request is open upstream. |MODIFIED|Indicates a fix has been built in an update. Bodhi will set this status automatically when an update is created if the bug is associated with the update. |ON_QA|Indicates an update with a fix is in the _testing_ repo. Bodhi will set this status automatically when an update reaches _updates-testing_ if the bug is associated with the update. |VERIFIED|Indicates a bug has a confirmed fix in an update. |RELEASE_PENDING|(Generally unused in Fedora. Used for Red Hat Enterprise Linux workflows.) -|CLOSED|Indicates the bug has been fixed or will not be fixed. The CLOSED status has different resolutions to indicate why the bug was closed. Bodhi will set this status automatically when an update reaches the _updates_ repo if the bug is associated with the update. +|CLOSED|Indicates the bug has been fixed or will not be fixed. The CLOSED status has different resolutions to indicate why the bug was closed. Bodhi will set this status automatically when an update reaches the _updates_ repo if the bug is associated with the update. |===