English
Change submission guidance
In general, Changes are for coordination of development effort and for communication (both internally and externally). They aren't mandates that someone else implement an idea (no matter how good that idea). If you have improvement in mind, work to get implementers committed to the effort _before_ filing a Change proposal, rather than expecting them to show up for work once the Change is accepted.
Watch the https://www.youtube.com/watch?v=oERoxg-VYPo[Fedora Changes policy video] for a quick introduction to the process.
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.
Read the xref:changes_policy[policies] for self-contained changes and system-wide changes.
Pick the right category. Remember, the category can be changed to another one based on community or FESCo review!
Fill in the https://fedoraproject.org/wiki/Changes/EmptyTemplate[empty change proposal form] with all details required for selected category (see inline comments and guidance below).
Once you're satisfied with the change proposal page, set the wiki page category to `ChangeReadyForWrangler`, _and_ set the appropriate change category (`SelfContainedChange` or `SystemWideChange`. Both categories must be set! Also ensure that the proposal URL follows the `Changes/<proposalname>` scheme.
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.
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).
A Change is considered _code complete_ when the bug state is moved to ON_QA and when there are no blocking bugs open.
See the xref:changes_policy.adoc#_bugzilla_trackers[Bugzilla trackers] section of the Changes policy for more information on Bugzilla statuses.
In most cases, you should not submit code changes to Rawhide until after FESCo has voted to approve the proposal.
What are the change process deadline dates (Checkpoints)?
See the xref:changes_policy.adoc#_change_process_milestones[Change Process Milestones] section of the Changes policy for information on the process milestones.
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. If you need to defer a change, let the Program Manager know and they will update the wiki page and the Bugzilla tracker appropriately.