There are so many places in the wiki to create things. This is probably not an exhaustive list. Hopefully in the future we'll have improved this process by consolidating and automating.
Update the index.html page on the https://fedorapeople.org/groups/schedule/[web view] of the schedule.
Create a release page (`Releases/N`) in the wiki that collects the pages in that category. You can use `{{Special:PrefixIndex/Releases/N/}}` to make it automagic (replacing "N" with the release number). This is a good target for de-wikifying.
Create a release schedule page (`Releases/N/Schedule`) in the wiki. For Fedora 31 and previous, this included a manually-transcribed copy of key milestones. For Fedora 32 and beyond, Ben decided that's a good way to introduce human error and made that page point to the https://fedorapeople.org/groups/schedule/[web view] of the schedule instead.
Create a ChangeSet page (`Releases/N/ChangeSet`) in the wiki. The output of the link:../changes#_create_tracking_bug[change processing scripts] gives you the content for this page.
Create a Spins page (`Releases/N/Spins`) in the wiki. Copy this from the previous version and make any changes as appropriate. This is another good target for de-wikifying.
Create a Release blocking deliverables page (`Releases/N/ReleaseBlocking`) in the wiki. Again, copy this from the previous version and make changes as appropriate. Stop me if you've heard this before, but this is a good target for de-wikifying.
Add the new release to the https://fedoraproject.org/wiki/Releases[Releases wiki page].
Add the new release to the https://fedoraproject.org/wiki/Changes[Changes wiki page].
Create a tracker bug for the release in Bugzilla. This simplifies reporting and branching (particularly for Fedora N+2 proposals that come in before N+1 is branched)
Use the **Changes Tracking** component
Set the Alias to "F<N>Changes"
Add the **Tracking** keyword
Spins keepalive
In order to keep from shipping spins that no one is maintaining anymore, https://pagure.io/fesco/issue/1972[FESCo approved a process] where the Program Manager will check with spin owners to make sure they're still around and wanting to produce the spin. The deadline corresponds with the Self-Contained Change deadline.
A few weeks before the deadline, create Pagure tickets for the spins and tag the appropriate owner. Then you can send this email to devel-announce and spins mailing lists (update the date and versions):
FESco previously approved a requirement that Spin/Labs owners send a
keepalive request in order to keep building the spin or lab. I have
opened Pagure issues[1] for all Spins and Labs listed on the wiki[2].
If you are the owner of one of those spins and labs, please reply in
the appropriate ticket by 30 January 2019 to indicate the spin should
continue to be produced. If there is a spin or lab that does not have
an open ticket, please create one[3].
The reasoning for this is to not ship spins that are not actively
maintained. Future improvements to the release process that will allow
for teams to self-publish solutions will eventually remove the need
for these keepalives.
[1] https://pagure.io/fedora-pgm/pgm_team/issues?status=Open&tags=spins+keepalive&close_status=
[2] https://fedoraproject.org/wiki/Releases/30/Spins
[3] https://pagure.io/fedora-pgm/pgm_team/new_issue