Section-by-section guidance
Change Proposal Name
This should be descriptive, but unique. For example "glibc 2.29" is preferable to "glibc upgrade".
Make sure your page is in the `Changes` namespace (e.g. call it `Changes/glibc_2.29`)
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?".
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.
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.
Use your Bugzilla email in the `email` field to make your Program Manager happy.
Current status
Do not edit this section except to set the target release version and update the `[[Category:*]]` tags.
Detailed Description
Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. If there are multiple reasonable approaches, you should indicate why you declined to use the others.
Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals, but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. This section is inspired in part by the "Rejected Ideas" section described by https://www.python.org/dev/peps/pep-0001/#id46[PEP-0001].
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. Either way, when you receive feedback, you should summarize it in this section.
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. If the discussion gets heated, consider asking a neutral party to summarize the discussions for you. This helps avoid bias and emotional response.
Benefit to Fedora
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?