From de3c0ae6e0c0e24d92ef0bdfe2529a07ba50c32b Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sun, 6 Sep 2026 19:07:46 +0300 Subject: [PATCH 01/45] feat: updated release procedure to be more up-to-date --- src/en/wizden-staff/release-procedure.md | 138 +++++++++++++++-------- 1 file changed, 94 insertions(+), 44 deletions(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 060c2b7178..51e9bd4c9a 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -1,15 +1,30 @@ -# Release Procedures (Proposal) +# Release Procedures All times are in CEST/UTC+2 We can always just deviate from the established times below, if necessary. But having a particular time written down would help us know when we should consider some part of the process to be overdue and start asking about it -## Thursday 20:00 - Staging +This page describes how our release cycle functions. +In short, we use 4-week based release cycle. 'Anchor' for cycle start and end is 'maintainers meeting' event. One release cycle does not technically (calendar-wise) 'end' with 'maintainers meeting', it 'overlaps' with next one, we are allowed to add code for next release (in master branch), while we are stabilizing our release ('staing' or later - 'stable' branch). Each cycle SHOULD lead to creation of new stable release. + +## Week 3 of cycle - Saturday 20:00 - Staging cutoff + +Week 1-3 of release cycle contain no special events related to our new release, PRs are merged into master. Activities, targeted at previous release (stabilization/hotfixing/etc) are described at later parts of this document. ### 0. Coordinate -Before you start, probably make sure no one else is already on it. Lead Maintainers usually do the staging and there is *typically* no need for anyone not frequently taking part in the setup process to get involved. +Before process starts, 'Release captain' should be chosen. It is temporary informal role during this release, controlling execution of all release key steps. When the person is chosen - announce so in staff channel and tag @maintainers with message (can be done together with staging cutoff announcement), to ensure no one else is already on it. It is producer's role job **(currently decided that Jezithyr and Slam will be taking turns on doing this)**. + +'Release captain' hat can be handed over for the rest of duration of release or just temporarily in case current 'captain' cannot fully operate due to any problems, having person who can properly dedicate time to release coordination is of most importance. + +'Release captain' should start with creating new instance of checklist (from temlate - https://outline.spacestation14.com/settings/templates/release-check-list-Qacv6vN8XM) and should keep it up to date. + +### 1. Cut the staging branch -### 1. Update the staging branch - Use the ```ss14-prepstaging``` function from [Myra's powershell script](https://gist.github.com/VasilisThePikachu/762b90187a5f9a0cca3249cc335cab31), which does most of it automatically (and also creates the Review Thread text for simplicity) +Announce cutoff 1 hour before starting with message in #maintainers Discord channel +```@Maintainers Hello crew, i am your Release captain for this release! We are starting to prepare things up now. Staging cutoff in 1 hour.``` + +Cutoff can be postponed if there are any problem with priority greater then p1. + +Otherwise run the `ss14-prepstaging` function from [Myra's powershell script](https://gist.github.com/VasilisThePikachu/762b90187a5f9a0cca3249cc335cab31). It does the whole cut for you: it fetches `upstream`, syncs your local `staging` with `upstream/staging` (**oldest** commit in the update), merges `upstream/master` into it and pushes the result (**newest** commit), then prints a ready-to-paste Release Review Thread skeleton (title, commit range, compare URL and a placeholder for the Outline doc link). >If you need to do it manually: >``` @@ -31,58 +46,56 @@ Before you start, probably make sure no one else is already on it. Lead Maintain >git push upstream staging >``` -Further merges into Staging should only happen if it's REALLY necessary, to ensure that we have time to review proposed changes and don't break things in the last moment. The process for this follows the [Hotfix Procedure](https://docs.spacestation14.com/en/wizden-staff/maintainer/hotfix-procedure.html). Revert or other changes may also be the result of a Maintainer vote after the meeting, this will be detailed below. - -### 2. Hedgedoc -Copy [this template](https://hedgedoc.spacestation14.com/c5nwAvfqSIOIO5mcaNjy7w) and create a new doc for the current release +Starting that point - further merges into Staging should only happen if it's REALLY necessary, to ensure that we have time to review proposed changes and don't break things in the last moment. The process for this follows the [Hotfix Procedure](https://docs.spacestation14.com/en/wizden-staff/maintainer/hotfix-procedure.html). Revert or other changes may also be the result of a Maintainer vote after the meeting, this will be detailed below. -### 3. Make the new Release Review Thread in #maint-reviews -Review threads are currently on Discord, but may move to Discourse in the future. +### 2. Create the Outline doc and open the Release Review Thread -If you used the script, it will automatically generate all the required text for you so you can just copy that and drop in the link to the new hedgedoc you made. +1. Create the upcoming Maintainer Meeting doc from a template in [Outline](https://outline.spacestation14.com/settings/templates/yyyy-mm-dd-maintainer-meeting-mmNlS0WVxq) from the meeting doc template. +2. In #maint-reviews, open the Release Review Thread titled `YYYY-MM-DD Release Review Thread` with the text printed by `ss14-prepstaging`, drop in the link to the Outline doc, and ping all Maintainers. Review threads are currently on Discord, but may move to Discourse in the future. > Manual setup: > * Title format: "YYYY-MM-DD Release Review Thread" > * List the current commit range: <`oldest commit hash`> - <`newest commit hash`> > * Link the current commit range: `https://github.com/space-wizards/space-station-14/compare/...` -> * link the hedgedoc +> * link created outline Maintainer Meeting doc -Ping all Maintainers. +### 3. Add the list of Feature Changes to the Outline doc -### 4. Add the list of Feature Changes to hedgedoc -Go through the commit range list and note every feature/balance PR in the current release. See the hedgedoc template for the format to be used. +Go through the commit range list and note every feature/balance PR in the current release. See the template for the format to be used. > You can use [this script](https://discord.com/channels/310555209753690112/909229454449078333/1350070411571757086) to generate the correctly formatted string for each PR, but you need to pick out the PRs from the full commit list manually -If there are topically related PRs, reverts or hotfixes, it's nice to group those together. Otherwise the list can be in the order of the original commit list. -Smaller mapping changes to existing maps, PRs that only fix bugs without larger implications, or refactors and cleanups with no user-facing effects do not need to be listed. +Notify maintainers in discord 'Release Review Thread' when PR list is up. -This list should be double-checked for any feature change PRs that may be mistakenly left off. It's easy to miss something, and it's unreasonable to ask one person to spend excessive amounts of time double-checking it. It makes sense for at least one other person to check any remaining PRs if they should also be added. Anyone is free to review and add additional PRs to be listed but it's best do this right after the thread is opened, to reduce the possibility that late-added entries get skipped by early reviews. +```@Maintainers PR list is up, please run over list and leave notes when nessesary. Reminder to lease 'BLOCKER' keyword for PRs that you view as highly problematic and needs revert (or at least no release should be done with them 'as-is'). Make sure to add yourself to 'finished reviewing' section after looking at all of the items in list.``` -If you add new entries after people have already reviewed the list (as noted on hedgedoc), then mention the new PRs in the review thread. +## Until the Meeting - Review PRs in list -## Until the Meeting - Reviews - -### 1. Maintainers add any proposed meeting topics to hedgedoc +### 1. Maintainers add topics that need discussion to the Outline doc ### 2. Maintainers review the feature changes Add any concerns/comments you have directly to the doc, you can also respond to other notes. Once you finished reviewing, add yourself to the "finished reviewing" list in the doc. -If something is unfinished/broken/etc enough that you think it should not be in the current release (in its current state), add a note starting with "BLOCK", followed by the concern or reasoning. You can further add what hotfix/conditions you think could salvage the PR in question for the current release, or if it should just be reverted outright. - #### The BLOCK tags +If something is unfinished/broken/etc enough that maintainer thinks it should not be in the current release (in its current state), add a note starting with "BLOCK", followed by the concern or reasoning. You can further add what hotfix/conditions you think could salvage the PR in question for the current release, or if it should just be reverted outright. + Using this unambiguous tag will help us have a smoother meeting and make the later vote/hotfix/revert process easier to decide. If you do not mark your comment with BLOCK, we will still go over it during the meeting but it will be treated as a "non-binding" lesser concern/suggestion/idea/future feature, not something that demands a vote. (If you will be at the meeting, you will still be able to change this to a BLOCK then) -Two such objections are required for a PR to go to a revert vote, if someone adds a second one at this stage then we can see ahead of time that there will be a vote, and can maybe even figure out/address any concerns before the meeting. This helps everyone involved, so if at all possible, review and log BLOCKs early. +Two such objections are required for a PR to go **instantly** to a revert vote (should be done in 'Release Review Thread' in discord), if someone adds a second one at this stage then we can see ahead of time that there will be a vote, and can maybe even figure out/address any concerns before the meeting. This helps everyone involved, so if at all possible, review and log BLOCKs early. #### In Absentia These comments also serve as the best way for people who can't make it to the meeting to engage with the revert process in a fair way. If you can't show up but have a concern, leave a BLOCK note along with your concern/reason/considtions, the meeting will not remove BLOCKs just because you are not there to argue for them. (Although if no one else seconds it before or during the meeting, then it will still not go to a vote) -## Saturday 20:00 - Maintainer Meeting +## Week 4 Saturday 20:00 - Maintainer Meeting + +It would be nice if we all showed up on the clock, so we could start sooner. -It would be nice if we all showed up on the clock, so we could start sooner. Ping 10 minutes before the meeting. +Make sure to note maintainers with messages when appropriate +```@Maintainers Maintainer meeting in 1 hour``` +```@Maintainers Maintainer meeting in 10 minutes``` +```@Maintainers Maintainer meeting is starting NOW!``` Historically, meetings have started with the Topics section. That will not be detailed in this doc. At some point, the meeting will get to the feature reviews. @@ -90,12 +103,12 @@ Historically, meetings have started with the Topics section. That will not be de Go through any PRs that have comments. See if any notes need to be edited to become BLOCKing, if anyone seconds them, or if anyone changes their mind in some other way. If at least two Maintainers have chosen to block a PR, there will be a vote after the meeting. Decide and document **now** what the vote options will be. The default option should be Revert, for simplicity. **Check the chat for any Maintainers not on voice trying to get a word in edgewise**. If the PR's author is present, consider consulting them. -Agree now who will start all the votes, both so the votes don't get forgotten and to force the future-votemaker to double-check if sufficient details about the votes have been noted down. (It sucks trying to figure out missing details by yourself after the fact) +Agree now **who** will start all the votes ('Release captain' should do it), both so the votes don't get forgotten and to force the future-votemaker to double-check if sufficient details about the votes have been noted down. (It sucks trying to figure out missing details by yourself after the fact) ### Hotfix votes -Optionally, some SIMPLE/straightforward change to the PR may be suggested. Such as tweaking numbers to something **specific** not just "it should do less damage", removing some specific, concrete part, or fixing a well-defined bug/issue. It should be discussed who will/might write this fix, not just hope that someone will start writing it afterwards. It does not need to be set in stone or a volunteer from the meeting, but we should have some idea at least. +Optionally, some SIMPLE/straightforward change to the PR may be suggested. Such as tweaking numbers to something **specific** not just "it should do less damage", removing some specific, concrete part, or fixing a well-defined bug/issue. It should be discussed **who** will/might write this fix, not just hope that someone will start writing it afterwards. It does not need to be set in stone or a volunteer from the meeting, but we should have some idea at least. Final deadline for fix should be chosen right away, and actions upon not reaching results on said deadline. -Since unlike a revert, a hotfix can't be finished in moments, we have to consider the possibility that there will be a schedule slip. As such, for hotfixing to be considered an option, we will specify an acceptable delay. **If we are unwilling to risk such a delay for the feature, then we should simply vote for a revert instead**, and fix it by the next release. Recommended default delay is 24 hours after the original expected Release. (Note that the time chosen is the maximum, we might finish sooner. But we should be willing to accept the full length of the delay. Record the delay's end time in the meeting notes. +Since unlike a revert, a hotfix can't be finished in moments, we have to consider the possibility that there will be a schedule slip. As such, for hotfixing to be considered an option, we will specify an acceptable delay. **If we are unwilling to risk such a delay for the feature, then we should simply vote for a revert instead**, and fix it by the next release. Recommended default delay is 24 hours after the original expected Release. (Note that the time chosen is the maximum, we might finish sooner. But we should be willing to accept the full length of the delay. Record the delay's 'End time' in the meeting notes. > All votes, whether for revert or hotfix, are RELEASE BLOCKERS. If some issue is minor enough that we could just release with it, then it might be better to just address it in the next release or hotfix it after release through the regular hotfix procedure. @@ -105,20 +118,23 @@ Feedback Pop-Ups is a feature that allows us to request players ingame to provid *No action is required* to have a pop-up remain only on the testing server, as the `PopupOrigin` property being set to `wizden_master` ensures it does not show on the stable servers. If a pop-up should be made visible on the stable servers, change the property to `wizden_master wizden_stable`. ## Right after the Meeting -Votes are immediately started for blocked PRs. Open a Discourse thread for each vote in Internal/Maintainer. If multiple PRs are conceptually linked, and/or were contested "as one", they can be combined into one thread. Copy the summary about the situation from the meeting notes, for anyone who was not present at the Meeting. The recording might not yet be available for review before votes have to be cast. +Votes are immediately started for blocked PRs. Open a Discourse thread for each vote in Discord 'Release Review Thread'. If multiple PRs are conceptually linked, and/or were contested "as one", they can be combined into one thread. Copy the summary about the situation from the meeting notes, for anyone who was not present at the Meeting. The recording might not yet be available for review before votes have to be cast. Polls will be kept open until the official release time (roughly 24 hours later), so that every Maintainer can get their chance to vote. They must have only 2 outcomes, plus Abstain: such as Keep/Revert/Abstain, or Keep/Hotfix/Abstain. Abstain votes will not have any effect on the outcome, they merely serve to indicate that someone has seen the vote but is not participating. >Binary votes leave no requirement for interpretation when they finish, so we don't need to have the Maintainer team assembled for closing up the release. Whoever is there can enact the results, even if alone, with no special pressure or responsibility for making "the correct call", since it has already been determined by (the best available) consensus. Afterwards, link the threads in #ongoing-votes and ping all maintainers. +``` @Maintainers Votes for reverts/hotfixes are up, please make sure to leave a vote, it will be closed in next 24h``` -## Sunday, before Release +## Week 4 - Sunday, before Release The proposed hotfix(es) can be prepared before release, but no one should feel forced to code just so we don't have a delay. If we are voting on a hotfix then we have already accepted a potential delay. It's also possible that the vote will decide to keep the PR, making the fix/change unnecessary. -## 21:00 - The Official Release Time +Release can be postponed but status on hotfixes should be regularly checked, this is activity for 'Release captain'. + +## Week 4 - Sunday, 21:00 - The Official Release Time -The Maintainers present can begin. If necessary, coordinate in the Release Review Thread who's doing what. Close the votes and check the status of any other release blockers. +The Maintainers present can begin. If necessary, coordinate in the 'Release Review Thread' who's doing what. Close the votes and check the status of any other release blockers. * If a vote's result is KEEP, the PR is no longer considered a blocker even if we want to later fix it. * If a vote's result is REVERT, create a PR to revert the feature from Staging. This does not require multiple maint approvals - it already has them from the vote. Since we are reverting a feature from master, before it ever hit stable, remove it from the changelog as well @@ -133,13 +149,13 @@ If no blockers remain, go to The Release. ## Delay If the hotfixes could not be finished or tested in time, we enter a Delay. The expected maximum duration of the Delay has been agreed upon during the Maintainer meeting, and within this timeframe we should consider the delay acceptable enough not to be "concerned". -If the fix gets completed before the End Time, then any Maintainers present can start the release immediately, but they are also free to just note it and leave someone else to do it later within the accepted Delay. +If the fix gets completed before the 'End Time', then 'Release captain' can start the release immediately, but they are also free to just note it and leave someone else to do it later within the accepted Delay. -Available Maintainers should reconvene at the End Time, to decide the continued fate of the blocking PR(s). At this point there will likely be Maintainer consensus established in some way, written decisions from the Lead Maintainers, or Lead Maintainers will be present, but if they aren't, then the Maintainers present decide whether to revert the PR in question or go into overtime waiting for the fix. There is no script for after going into overtime. +'Release captain' should reconvene at the End Time, to decide the continued fate of the blocking PR(s). At this point there will likely be Maintainer consensus established in some way, written decisions from the Lead Maintainers / Game Director, or Lead Maintainers will be present, but if they aren't, then the Maintainers present decide whether to revert the PR in question or go into overtime waiting for the fix. There is no script for after going into overtime. -> Our level of priority for hitting release targets is currently in general unspecified +> It is up to 'Release captain' to choose if problem fixes worth additional time until release, but as a general rule it should be noted that complex/heavy fixes are undesirable (highly discouraged), as 'staging' branch does not have any testing grounds. -## The Release +## The Release (timinig depends on 'when its ready'™) ### 1. Merge Staging into Stable @@ -156,12 +172,24 @@ git merge staging git push upstream stable ``` -### 2. If there were any hotfixes on Staging that weren't already merged back, merge Stable into Master. +### 2. Add tag to release -This needs to be done via PR on github (because the master branch is protected from pushing). -You can merge this PR by yourself immediately, but **DO NOT SQUASH IT**. +Add release version tag on commit that will be used for our new release. + +version in following script should be formed using following template +```wizden-v{YEAR}.{START-MONTH}.{HOTFIX}``` +replace `START-MONTH` with two-digit month number in which release should have been published originally, and `HOTFIX` is zero-based number of publishes done for the sake of hotfixes. + +example - previous release was supposed to be out on Sunday 2026-07-26 - that is start of new release cycle (the fact that it got out on 2026-07-27 does not matter - we use planned calendar dates), so next maintainers meeting and release is supposed to be in 4 weeks, 2026-08-23, so our version number for it will be `wizden-v2026.08.0` even if after A LOT of hotfixes it will be out on 2026-09-01. And any following small hotifxes, that will be released following it but without staging branch usage - will be called `wizden-v2026.08.1`, `wizden-v2026.08.2` etc. + + +``` +git checkout stable +git pull upstream stable +git tag +git push upstream +``` -If there are merge conflicts at this step, note that you could publish stable before you get bogged down fixing the conflict for master so meanwhile the publish tests can run. ### 3. Run Publish @@ -171,6 +199,28 @@ To do it manually, go to [github's web GUI](https://github.com/space-wizards/spa ![runpublish.png](../assets/images/wizden-staff/runpublish.png) -### 4. Monitor if Salamander and Lizard actually deploy the new release after their next restart + +Make sure that publish workflow finishes green, and check changelog discord channel to make sure new updates are published. + +// TODO - need to add steps that will create GitHub release record for new release, ideally without any additional manual actions + + +### 4. If there were any hotfixes on Staging that weren't already merged back, merge Stable into Master. + +This needs to be done via PR on github (because the master branch is protected from pushing). +You can merge this PR by yourself immediately, but **DO NOT SQUASH IT**. + +If there are merge conflicts at this step, note that you could publish stable before you get bogged down fixing the conflict for master so meanwhile the publish tests can run. + + +### 5. Monitor if Salamander actually gets the new release after their next restart Specifically these two servers sometimes restart for the patch, but don't actually get it due to "funny network reasons". If this happens, any Maintainer can run ```!updateserver servername``` on Discord to restart them again. + +### 6. Announce that release is out and works on it are finished + +Notify maintainers that all works related to release are finished. + +``` @Maintainers Relase '' is finished, out on CDN and Salamander! If you will notice any critical problems - please share them and make sure to prioritize hotfixes or reverts over other kind of works. ``` + +'Release captain' should orchestrate works on any urgent fixes / reverts that will surface once new version is available to players. Pay extra attentntion to Admins and forks (#space-wizards-enclave Discord channel) feedback. \ No newline at end of file From 8190146391111b7fd7288aef59ff6ef04692458e Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 7 Sep 2026 20:45:32 +0300 Subject: [PATCH 02/45] Update src/en/wizden-staff/release-procedure.md according to Slam request, using just generic role is better Co-authored-by: SlamBamActionman <83650252+SlamBamActionman@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 51e9bd4c9a..62f59529ea 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -11,7 +11,7 @@ In short, we use 4-week based release cycle. 'Anchor' for cycle start and end is Week 1-3 of release cycle contain no special events related to our new release, PRs are merged into master. Activities, targeted at previous release (stabilization/hotfixing/etc) are described at later parts of this document. ### 0. Coordinate -Before process starts, 'Release captain' should be chosen. It is temporary informal role during this release, controlling execution of all release key steps. When the person is chosen - announce so in staff channel and tag @maintainers with message (can be done together with staging cutoff announcement), to ensure no one else is already on it. It is producer's role job **(currently decided that Jezithyr and Slam will be taking turns on doing this)**. +Before process starts, 'Release captain' should be chosen. It is temporary informal role during this release, controlling execution of all release key steps. When the person is chosen - announce so in staff channel and tag @maintainers with message (can be done together with staging cutoff announcement), to ensure no one else is already on it. It is the Producer role team's responsibility to arrange who will be Release Captain. 'Release captain' hat can be handed over for the rest of duration of release or just temporarily in case current 'captain' cannot fully operate due to any problems, having person who can properly dedicate time to release coordination is of most importance. From e8f440ca25b46200e7d4008a778d0571fedc6f41 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:06:23 +0300 Subject: [PATCH 03/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 62f59529ea..e42f69a3ef 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -4,7 +4,7 @@ All times are in CEST/UTC+2 We can always just deviate from the established times below, if necessary. But having a particular time written down would help us know when we should consider some part of the process to be overdue and start asking about it This page describes how our release cycle functions. -In short, we use 4-week based release cycle. 'Anchor' for cycle start and end is 'maintainers meeting' event. One release cycle does not technically (calendar-wise) 'end' with 'maintainers meeting', it 'overlaps' with next one, we are allowed to add code for next release (in master branch), while we are stabilizing our release ('staing' or later - 'stable' branch). Each cycle SHOULD lead to creation of new stable release. +In short, we use a 4-week based release cycle. The 'anchor' for cycle start and end is the 'maintainer meeting' event. One release cycle does not technically (calendar-wise) 'end' with the 'maintainer meeting', it 'overlaps' with the start of the next cycle. We are allowed to add code for the next release (in master branch), while we are stabilizing our release ('staging' or later - 'stable' branch). Each cycle SHOULD lead to the creation of a new stable release. ## Week 3 of cycle - Saturday 20:00 - Staging cutoff From bbb0277c9eb9f67c9c9dcc7f6e86392a51330d3b Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:06:46 +0300 Subject: [PATCH 04/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index e42f69a3ef..1838c806e1 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -8,7 +8,7 @@ In short, we use a 4-week based release cycle. The 'anchor' for cycle start and ## Week 3 of cycle - Saturday 20:00 - Staging cutoff -Week 1-3 of release cycle contain no special events related to our new release, PRs are merged into master. Activities, targeted at previous release (stabilization/hotfixing/etc) are described at later parts of this document. +Weeks 1-3 of the release cycle contain no special events related to our new release, PRs are merged into master. Activities targeted at the previous release (stabilization/hotfixing/etc) are described later in this document. ### 0. Coordinate Before process starts, 'Release captain' should be chosen. It is temporary informal role during this release, controlling execution of all release key steps. When the person is chosen - announce so in staff channel and tag @maintainers with message (can be done together with staging cutoff announcement), to ensure no one else is already on it. It is the Producer role team's responsibility to arrange who will be Release Captain. From ff19069bc222c49fdad9675ede904a55c8e918f3 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:07:17 +0300 Subject: [PATCH 05/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 1838c806e1..6e01354d86 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -13,7 +13,7 @@ Weeks 1-3 of the release cycle contain no special events related to our new rele ### 0. Coordinate Before process starts, 'Release captain' should be chosen. It is temporary informal role during this release, controlling execution of all release key steps. When the person is chosen - announce so in staff channel and tag @maintainers with message (can be done together with staging cutoff announcement), to ensure no one else is already on it. It is the Producer role team's responsibility to arrange who will be Release Captain. -'Release captain' hat can be handed over for the rest of duration of release or just temporarily in case current 'captain' cannot fully operate due to any problems, having person who can properly dedicate time to release coordination is of most importance. +The 'release captain' hat can be handed over for the rest of duration of the release or just temporarily, in case the current 'captain' cannot fully operate due to any problems. Having someone who can properly dedicate time to the release coordination is of utmost importance. 'Release captain' should start with creating new instance of checklist (from temlate - https://outline.spacestation14.com/settings/templates/release-check-list-Qacv6vN8XM) and should keep it up to date. From f7125a1493c0f44d6431ad50f1c3d3bc6180faa8 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:07:49 +0300 Subject: [PATCH 06/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 6e01354d86..72452e7708 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -15,7 +15,7 @@ Before process starts, 'Release captain' should be chosen. It is temporary infor The 'release captain' hat can be handed over for the rest of duration of the release or just temporarily, in case the current 'captain' cannot fully operate due to any problems. Having someone who can properly dedicate time to the release coordination is of utmost importance. -'Release captain' should start with creating new instance of checklist (from temlate - https://outline.spacestation14.com/settings/templates/release-check-list-Qacv6vN8XM) and should keep it up to date. +The 'release captain' should start with creating a new instance of the checklist (from template - https://outline.spacestation14.com/settings/templates/release-check-list-Qacv6vN8XM) and should keep it up to date throughout the release process. ### 1. Cut the staging branch From b5f33f3f6ec756eb9f61b3125f01340c40198eb1 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:08:12 +0300 Subject: [PATCH 07/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 72452e7708..8d9ef07b48 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -19,7 +19,7 @@ The 'release captain' should start with creating a new instance of the checklist ### 1. Cut the staging branch -Announce cutoff 1 hour before starting with message in #maintainers Discord channel +Announce cutoff 1 hour before starting, with a message in the #maintainers Discord channel. ```@Maintainers Hello crew, i am your Release captain for this release! We are starting to prepare things up now. Staging cutoff in 1 hour.``` Cutoff can be postponed if there are any problem with priority greater then p1. From da59490a089768a66e67c0ef6fa61214c357061a Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:08:31 +0300 Subject: [PATCH 08/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 8d9ef07b48..be81635a80 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -20,7 +20,7 @@ The 'release captain' should start with creating a new instance of the checklist ### 1. Cut the staging branch Announce cutoff 1 hour before starting, with a message in the #maintainers Discord channel. -```@Maintainers Hello crew, i am your Release captain for this release! We are starting to prepare things up now. Staging cutoff in 1 hour.``` +```@Maintainers Hello crew, I will be coordinating this release. Staging cutoff in 1 hour.``` Cutoff can be postponed if there are any problem with priority greater then p1. From 0efda641c543475dd2362a2b939b4fe1081567f9 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:08:48 +0300 Subject: [PATCH 09/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index be81635a80..6f2da0d6e6 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -217,7 +217,7 @@ If there are merge conflicts at this step, note that you could publish stable be Specifically these two servers sometimes restart for the patch, but don't actually get it due to "funny network reasons". If this happens, any Maintainer can run ```!updateserver servername``` on Discord to restart them again. -### 6. Announce that release is out and works on it are finished +### 6. Announce that the release is out and works on it are finished Notify maintainers that all works related to release are finished. From bef295d809cfb5bc467b57861c6852b3922a8b60 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:09:26 +0300 Subject: [PATCH 10/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 6f2da0d6e6..cdd65f8f15 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -223,4 +223,4 @@ Notify maintainers that all works related to release are finished. ``` @Maintainers Relase '' is finished, out on CDN and Salamander! If you will notice any critical problems - please share them and make sure to prioritize hotfixes or reverts over other kind of works. ``` -'Release captain' should orchestrate works on any urgent fixes / reverts that will surface once new version is available to players. Pay extra attentntion to Admins and forks (#space-wizards-enclave Discord channel) feedback. \ No newline at end of file +'Release captain' should orchestrate works on any urgent fixes / reverts that might surface once the new version is available to players. Pay extra attention to Admin and Downstream (#space-wizards-enclave Discord channel) feedback. \ No newline at end of file From 58ddcc0ae491c7119363815fba97822daeaa65e2 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:09:55 +0300 Subject: [PATCH 11/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index cdd65f8f15..53408f00a6 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -22,7 +22,7 @@ The 'release captain' should start with creating a new instance of the checklist Announce cutoff 1 hour before starting, with a message in the #maintainers Discord channel. ```@Maintainers Hello crew, I will be coordinating this release. Staging cutoff in 1 hour.``` -Cutoff can be postponed if there are any problem with priority greater then p1. +Cutoff can be postponed if there are any problems with priority greater then P1. Otherwise run the `ss14-prepstaging` function from [Myra's powershell script](https://gist.github.com/VasilisThePikachu/762b90187a5f9a0cca3249cc335cab31). It does the whole cut for you: it fetches `upstream`, syncs your local `staging` with `upstream/staging` (**oldest** commit in the update), merges `upstream/master` into it and pushes the result (**newest** commit), then prints a ready-to-paste Release Review Thread skeleton (title, commit range, compare URL and a placeholder for the Outline doc link). From 163f6f5d033f27a9bc68e4faa275edf945b353d1 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:10:40 +0300 Subject: [PATCH 12/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 53408f00a6..32c7745f9e 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -11,7 +11,7 @@ In short, we use a 4-week based release cycle. The 'anchor' for cycle start and Weeks 1-3 of the release cycle contain no special events related to our new release, PRs are merged into master. Activities targeted at the previous release (stabilization/hotfixing/etc) are described later in this document. ### 0. Coordinate -Before process starts, 'Release captain' should be chosen. It is temporary informal role during this release, controlling execution of all release key steps. When the person is chosen - announce so in staff channel and tag @maintainers with message (can be done together with staging cutoff announcement), to ensure no one else is already on it. It is the Producer role team's responsibility to arrange who will be Release Captain. +Before the process starts, a 'Release captain' should be chosen. It is a temporary, informal role during this release, controlling the execution of all release key steps. When the person is chosen - announce so in the staff channel and tag @maintainers (can be done together with the staging cutoff announcement), to ensure no one else is already on it. It is the Producer role team's responsibility to arrange who will be Release Captain. The 'release captain' hat can be handed over for the rest of duration of the release or just temporarily, in case the current 'captain' cannot fully operate due to any problems. Having someone who can properly dedicate time to the release coordination is of utmost importance. From 8b21e9bb94593a3548697efe68b0f5cb1e1a1c2d Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:10:59 +0300 Subject: [PATCH 13/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 32c7745f9e..f4187ac02c 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -46,7 +46,7 @@ Otherwise run the `ss14-prepstaging` function from [Myra's powershell script](ht >git push upstream staging >``` -Starting that point - further merges into Staging should only happen if it's REALLY necessary, to ensure that we have time to review proposed changes and don't break things in the last moment. The process for this follows the [Hotfix Procedure](https://docs.spacestation14.com/en/wizden-staff/maintainer/hotfix-procedure.html). Revert or other changes may also be the result of a Maintainer vote after the meeting, this will be detailed below. +Starting from this point, further merges into Staging should only happen if it's REALLY necessary, to ensure that we have time to review proposed changes and don't break things in the last moment. The process for this follows the [Hotfix Procedure](https://docs.spacestation14.com/en/wizden-staff/maintainer/hotfix-procedure.html). Revert or other changes may also be the result of a Maintainer vote after the meeting, this will be detailed below. ### 2. Create the Outline doc and open the Release Review Thread From 98eb3bd8ca5e1223a76f79370eeda94cc2a8640d Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:11:26 +0300 Subject: [PATCH 14/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index f4187ac02c..2baacfb99e 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -130,7 +130,7 @@ Afterwards, link the threads in #ongoing-votes and ping all maintainers. The proposed hotfix(es) can be prepared before release, but no one should feel forced to code just so we don't have a delay. If we are voting on a hotfix then we have already accepted a potential delay. It's also possible that the vote will decide to keep the PR, making the fix/change unnecessary. -Release can be postponed but status on hotfixes should be regularly checked, this is activity for 'Release captain'. +Release can be postponed but status on hotfixes should be kept up to date by the 'Release captain'. ## Week 4 - Sunday, 21:00 - The Official Release Time From f2e2e671198f8abb9eeee58772e8a14a13940e9b Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:16:38 +0300 Subject: [PATCH 15/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 2baacfb99e..d13d9f79fd 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -221,6 +221,6 @@ Specifically these two servers sometimes restart for the patch, but don't actual Notify maintainers that all works related to release are finished. -``` @Maintainers Relase '' is finished, out on CDN and Salamander! If you will notice any critical problems - please share them and make sure to prioritize hotfixes or reverts over other kind of works. ``` +``` @Maintainers Relase '' has completed, it's out on the CDN. If you notice any critical problems - please share them and make sure to prioritize hotfixes or reverts over other kinds of work. ``` 'Release captain' should orchestrate works on any urgent fixes / reverts that might surface once the new version is available to players. Pay extra attention to Admin and Downstream (#space-wizards-enclave Discord channel) feedback. \ No newline at end of file From 4486c6320da5a7bad96c78ea78463a18eb5afa2b Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:31:20 +0300 Subject: [PATCH 16/45] Update src/en/wizden-staff/release-procedure.md Errant fixed my typos Co-authored-by: Errant <35878406+Errant-4@users.noreply.github.com> --- src/en/wizden-staff/release-procedure.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index d13d9f79fd..7735f51891 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -66,7 +66,8 @@ Go through the commit range list and note every feature/balance PR in the curren Notify maintainers in discord 'Release Review Thread' when PR list is up. -```@Maintainers PR list is up, please run over list and leave notes when nessesary. Reminder to lease 'BLOCKER' keyword for PRs that you view as highly problematic and needs revert (or at least no release should be done with them 'as-is'). Make sure to add yourself to 'finished reviewing' section after looking at all of the items in list.``` +```@Maintainers PR list is up, please go over the list and leave any notes you have. Reminder to please use the 'BLOCKER' keyword for PRs that you view as problematic and wish to revert or change before release. +Make sure to add yourself to the 'finished reviewing' section after looking at all of the items on the list.``` ## Until the Meeting - Review PRs in list From 7daadcac5af7d241869ac74cd89138d0c3da89ea Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 22:40:14 +0300 Subject: [PATCH 17/45] refactor: use BLOCKER tag instead of BLOCK --- src/en/wizden-staff/release-procedure.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 7735f51891..7bf9f51b66 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -76,18 +76,18 @@ Make sure to add yourself to the 'finished reviewing' section after looking at a ### 2. Maintainers review the feature changes Add any concerns/comments you have directly to the doc, you can also respond to other notes. Once you finished reviewing, add yourself to the "finished reviewing" list in the doc. -#### The BLOCK tags +#### The BLOCKER tags -If something is unfinished/broken/etc enough that maintainer thinks it should not be in the current release (in its current state), add a note starting with "BLOCK", followed by the concern or reasoning. You can further add what hotfix/conditions you think could salvage the PR in question for the current release, or if it should just be reverted outright. +If something is unfinished/broken/etc enough that maintainer thinks it should not be in the current release (in its current state), add a note starting with "BLOCKER", followed by the concern or reasoning. You can further add what hotfix/conditions you think could salvage the PR in question for the current release, or if it should just be reverted outright. Using this unambiguous tag will help us have a smoother meeting and make the later vote/hotfix/revert process easier to decide. -If you do not mark your comment with BLOCK, we will still go over it during the meeting but it will be treated as a "non-binding" lesser concern/suggestion/idea/future feature, not something that demands a vote. (If you will be at the meeting, you will still be able to change this to a BLOCK then) +If you do not mark your comment with BLOCKER, we will still go over it during the meeting but it will be treated as a "non-binding" lesser concern/suggestion/idea/future feature, not something that demands a vote. (If you will be at the meeting, you will still be able to change this to a BLOCKER then) -Two such objections are required for a PR to go **instantly** to a revert vote (should be done in 'Release Review Thread' in discord), if someone adds a second one at this stage then we can see ahead of time that there will be a vote, and can maybe even figure out/address any concerns before the meeting. This helps everyone involved, so if at all possible, review and log BLOCKs early. +Two such objections are required for a PR to go **instantly** to a revert vote (should be done in 'Release Review Thread' in discord), if someone adds a second one at this stage then we can see ahead of time that there will be a vote, and can maybe even figure out/address any concerns before the meeting. This helps everyone involved, so if at all possible, review and log BLOCKERs early. #### In Absentia -These comments also serve as the best way for people who can't make it to the meeting to engage with the revert process in a fair way. If you can't show up but have a concern, leave a BLOCK note along with your concern/reason/considtions, the meeting will not remove BLOCKs just because you are not there to argue for them. (Although if no one else seconds it before or during the meeting, then it will still not go to a vote) +These comments also serve as the best way for people who can't make it to the meeting to engage with the revert process in a fair way. If you can't show up but have a concern, leave a BLOCKER note along with your concern/reason/considtions, the meeting will not remove tags just because you are not there to argue for them. (Although if no one else seconds it before or during the meeting, then it will still not go to a vote) ## Week 4 Saturday 20:00 - Maintainer Meeting From 464fab611980e04f46805b65653465a08d84506b Mon Sep 17 00:00:00 2001 From: Fildrance Date: Sat, 12 Sep 2026 23:25:03 +0300 Subject: [PATCH 18/45] refactor: clarify who is in charge of delaying cutoff --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 7bf9f51b66..b0d2185655 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -22,7 +22,7 @@ The 'release captain' should start with creating a new instance of the checklist Announce cutoff 1 hour before starting, with a message in the #maintainers Discord channel. ```@Maintainers Hello crew, I will be coordinating this release. Staging cutoff in 1 hour.``` -Cutoff can be postponed if there are any problems with priority greater then P1. +Cutoff can be postponed by the 'release captain' in case there are any problems with priority greater than P1. Otherwise run the `ss14-prepstaging` function from [Myra's powershell script](https://gist.github.com/VasilisThePikachu/762b90187a5f9a0cca3249cc335cab31). It does the whole cut for you: it fetches `upstream`, syncs your local `staging` with `upstream/staging` (**oldest** commit in the update), merges `upstream/master` into it and pushes the result (**newest** commit), then prints a ready-to-paste Release Review Thread skeleton (title, commit range, compare URL and a placeholder for the Outline doc link). From d229cec1f2ad79896ff1562a4b940bf6fcf52f37 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:05:33 +0300 Subject: [PATCH 19/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index b0d2185655..438a86106e 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -4,7 +4,7 @@ All times are in CEST/UTC+2 We can always just deviate from the established times below, if necessary. But having a particular time written down would help us know when we should consider some part of the process to be overdue and start asking about it This page describes how our release cycle functions. -In short, we use a 4-week based release cycle. The 'anchor' for cycle start and end is the 'maintainer meeting' event. One release cycle does not technically (calendar-wise) 'end' with the 'maintainer meeting', it 'overlaps' with the start of the next cycle. We are allowed to add code for the next release (in master branch), while we are stabilizing our release ('staging' or later - 'stable' branch). Each cycle SHOULD lead to the creation of a new stable release. +In short, we use a 4-week-based release cycle. The 'anchor' for the cycle start and end is the 'maintainer meeting' event. One release cycle does not technically (calendar-wise) 'end' with the 'maintainer meeting', it 'overlaps' with the start of the next cycle. We are allowed to add code for the next release (in master branch), while we are stabilizing our release ('staging' or later - 'stable' branch). Each cycle SHOULD lead to the creation of a new stable release. ## Week 3 of cycle - Saturday 20:00 - Staging cutoff From 09c7d422eb891340f74a9e4f651c1e1ad24eaa0c Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:05:50 +0300 Subject: [PATCH 20/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 438a86106e..3508e0d819 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -8,7 +8,7 @@ In short, we use a 4-week-based release cycle. The 'anchor' for the cycle start ## Week 3 of cycle - Saturday 20:00 - Staging cutoff -Weeks 1-3 of the release cycle contain no special events related to our new release, PRs are merged into master. Activities targeted at the previous release (stabilization/hotfixing/etc) are described later in this document. +Weeks 1-3 of the release cycle contain no special events related to our new release; PRs are merged into master. Activities targeted at the previous release (stabilization/hotfixing/etc.) are described later in this document. ### 0. Coordinate Before the process starts, a 'Release captain' should be chosen. It is a temporary, informal role during this release, controlling the execution of all release key steps. When the person is chosen - announce so in the staff channel and tag @maintainers (can be done together with the staging cutoff announcement), to ensure no one else is already on it. It is the Producer role team's responsibility to arrange who will be Release Captain. From 73ae1a0dd801d8f2157e0fdefc0fdfccd105c088 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:06:17 +0300 Subject: [PATCH 21/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 3508e0d819..8bfd125d60 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -11,7 +11,7 @@ In short, we use a 4-week-based release cycle. The 'anchor' for the cycle start Weeks 1-3 of the release cycle contain no special events related to our new release; PRs are merged into master. Activities targeted at the previous release (stabilization/hotfixing/etc.) are described later in this document. ### 0. Coordinate -Before the process starts, a 'Release captain' should be chosen. It is a temporary, informal role during this release, controlling the execution of all release key steps. When the person is chosen - announce so in the staff channel and tag @maintainers (can be done together with the staging cutoff announcement), to ensure no one else is already on it. It is the Producer role team's responsibility to arrange who will be Release Captain. +Before the process starts, a 'Release captain' should be chosen. It is a temporary, informal role during this release, controlling the execution of all release key steps. When the person is chosen, announce it in the staff channel and tag @maintainers (can be done together with the staging cutoff announcement) to ensure no one else is already on it. It is the Producer role team's responsibility to arrange who will be the Release Captain. The 'release captain' hat can be handed over for the rest of duration of the release or just temporarily, in case the current 'captain' cannot fully operate due to any problems. Having someone who can properly dedicate time to the release coordination is of utmost importance. From efc01ee6e5261c201e2a83ca839040e7085c2e84 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:06:30 +0300 Subject: [PATCH 22/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 8bfd125d60..a9a8887132 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -13,7 +13,7 @@ Weeks 1-3 of the release cycle contain no special events related to our new rele ### 0. Coordinate Before the process starts, a 'Release captain' should be chosen. It is a temporary, informal role during this release, controlling the execution of all release key steps. When the person is chosen, announce it in the staff channel and tag @maintainers (can be done together with the staging cutoff announcement) to ensure no one else is already on it. It is the Producer role team's responsibility to arrange who will be the Release Captain. -The 'release captain' hat can be handed over for the rest of duration of the release or just temporarily, in case the current 'captain' cannot fully operate due to any problems. Having someone who can properly dedicate time to the release coordination is of utmost importance. +The 'release captain' hat can be handed over for the rest of the duration of the release or just temporarily, in case the current 'captain' cannot fully operate due to any problems. Having someone who can properly dedicate time to the release coordination is of utmost importance. The 'release captain' should start with creating a new instance of the checklist (from template - https://outline.spacestation14.com/settings/templates/release-check-list-Qacv6vN8XM) and should keep it up to date throughout the release process. From 6ccef3b35bb1d426995c26d27ecdf68106fe2dea Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:06:47 +0300 Subject: [PATCH 23/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index a9a8887132..a3b017510f 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -15,7 +15,7 @@ Before the process starts, a 'Release captain' should be chosen. It is a tempora The 'release captain' hat can be handed over for the rest of the duration of the release or just temporarily, in case the current 'captain' cannot fully operate due to any problems. Having someone who can properly dedicate time to the release coordination is of utmost importance. -The 'release captain' should start with creating a new instance of the checklist (from template - https://outline.spacestation14.com/settings/templates/release-check-list-Qacv6vN8XM) and should keep it up to date throughout the release process. +The 'release captain' should start by creating a new instance of the checklist (from the template: https://outline.spacestation14.com/settings/templates/release-check-list-Qacv6vN8XM) and should keep it up to date throughout the release process. ### 1. Cut the staging branch From 7ea17469b8a4f2816fd5337008981987a44e8048 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:07:22 +0300 Subject: [PATCH 24/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index a3b017510f..e12db12a58 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -216,7 +216,7 @@ If there are merge conflicts at this step, note that you could publish stable be ### 5. Monitor if Salamander actually gets the new release after their next restart -Specifically these two servers sometimes restart for the patch, but don't actually get it due to "funny network reasons". If this happens, any Maintainer can run ```!updateserver servername``` on Discord to restart them again. +Specifically, these two servers sometimes restart for the patch but don't actually get it due to "funny network reasons". If this happens, any Maintainer can run ```!updateserver servername``` on Discord to restart them again. ### 6. Announce that the release is out and works on it are finished From eb79e4c0e416485c158ec14fd7d6a42411afa52f Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:07:46 +0300 Subject: [PATCH 25/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index e12db12a58..6ba39a4c7d 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -83,7 +83,7 @@ If something is unfinished/broken/etc enough that maintainer thinks it should no Using this unambiguous tag will help us have a smoother meeting and make the later vote/hotfix/revert process easier to decide. If you do not mark your comment with BLOCKER, we will still go over it during the meeting but it will be treated as a "non-binding" lesser concern/suggestion/idea/future feature, not something that demands a vote. (If you will be at the meeting, you will still be able to change this to a BLOCKER then) -Two such objections are required for a PR to go **instantly** to a revert vote (should be done in 'Release Review Thread' in discord), if someone adds a second one at this stage then we can see ahead of time that there will be a vote, and can maybe even figure out/address any concerns before the meeting. This helps everyone involved, so if at all possible, review and log BLOCKERs early. +Two such objections are required for a PR to go **instantly** to a revert vote (should be done in the 'Release Review Thread' in Discord). If someone adds a second one at this stage, then we can see ahead of time that there will be a vote and can maybe even figure out/address any concerns before the meeting. This helps everyone involved, so if at all possible, review and log BLOCKERs early. #### In Absentia From e4938620efba34171f3a21856626c88ff0fba163 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:08:03 +0300 Subject: [PATCH 26/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 6ba39a4c7d..59d40f9c8a 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -119,7 +119,7 @@ Feedback Pop-Ups is a feature that allows us to request players ingame to provid *No action is required* to have a pop-up remain only on the testing server, as the `PopupOrigin` property being set to `wizden_master` ensures it does not show on the stable servers. If a pop-up should be made visible on the stable servers, change the property to `wizden_master wizden_stable`. ## Right after the Meeting -Votes are immediately started for blocked PRs. Open a Discourse thread for each vote in Discord 'Release Review Thread'. If multiple PRs are conceptually linked, and/or were contested "as one", they can be combined into one thread. Copy the summary about the situation from the meeting notes, for anyone who was not present at the Meeting. The recording might not yet be available for review before votes have to be cast. +Votes are immediately started for blocked PRs. Open a Discourse thread for each vote in the Discord 'Release Review Thread'. If multiple PRs are conceptually linked, and/or were contested "as one", they can be combined into one thread. Copy the summary of the situation from the meeting notes for anyone who was not present at the Meeting. The recording might not yet be available for review before votes have to be cast. Polls will be kept open until the official release time (roughly 24 hours later), so that every Maintainer can get their chance to vote. They must have only 2 outcomes, plus Abstain: such as Keep/Revert/Abstain, or Keep/Hotfix/Abstain. Abstain votes will not have any effect on the outcome, they merely serve to indicate that someone has seen the vote but is not participating. >Binary votes leave no requirement for interpretation when they finish, so we don't need to have the Maintainer team assembled for closing up the release. Whoever is there can enact the results, even if alone, with no special pressure or responsibility for making "the correct call", since it has already been determined by (the best available) consensus. From 256dd278fcac3cf25ff742423bcabec1e87247b8 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:08:45 +0300 Subject: [PATCH 27/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 59d40f9c8a..71087b2212 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -104,7 +104,7 @@ Historically, meetings have started with the Topics section. That will not be de Go through any PRs that have comments. See if any notes need to be edited to become BLOCKing, if anyone seconds them, or if anyone changes their mind in some other way. If at least two Maintainers have chosen to block a PR, there will be a vote after the meeting. Decide and document **now** what the vote options will be. The default option should be Revert, for simplicity. **Check the chat for any Maintainers not on voice trying to get a word in edgewise**. If the PR's author is present, consider consulting them. -Agree now **who** will start all the votes ('Release captain' should do it), both so the votes don't get forgotten and to force the future-votemaker to double-check if sufficient details about the votes have been noted down. (It sucks trying to figure out missing details by yourself after the fact) +Agree now on **who** will start all the votes ('Release captain' should do it), so the votes don't get forgotten and to force the future vote-maker to double-check whether sufficient details about the votes have been noted down. (It sucks trying to figure out missing details by yourself after the fact) ### Hotfix votes Optionally, some SIMPLE/straightforward change to the PR may be suggested. Such as tweaking numbers to something **specific** not just "it should do less damage", removing some specific, concrete part, or fixing a well-defined bug/issue. It should be discussed **who** will/might write this fix, not just hope that someone will start writing it afterwards. It does not need to be set in stone or a volunteer from the meeting, but we should have some idea at least. Final deadline for fix should be chosen right away, and actions upon not reaching results on said deadline. From a852dbd9d544f316fb03a99739cab623cc580441 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:09:15 +0300 Subject: [PATCH 28/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 71087b2212..f922f19f4f 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -156,7 +156,7 @@ If the fix gets completed before the 'End Time', then 'Release captain' can star > It is up to 'Release captain' to choose if problem fixes worth additional time until release, but as a general rule it should be noted that complex/heavy fixes are undesirable (highly discouraged), as 'staging' branch does not have any testing grounds. -## The Release (timinig depends on 'when its ready'™) +## The Release (timing depends on 'when it's ready'™) ### 1. Merge Staging into Stable From d62331744e43fe8026b107c18686fd439438f315 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:09:50 +0300 Subject: [PATCH 29/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index f922f19f4f..f9206501ed 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -154,7 +154,7 @@ If the fix gets completed before the 'End Time', then 'Release captain' can star 'Release captain' should reconvene at the End Time, to decide the continued fate of the blocking PR(s). At this point there will likely be Maintainer consensus established in some way, written decisions from the Lead Maintainers / Game Director, or Lead Maintainers will be present, but if they aren't, then the Maintainers present decide whether to revert the PR in question or go into overtime waiting for the fix. There is no script for after going into overtime. -> It is up to 'Release captain' to choose if problem fixes worth additional time until release, but as a general rule it should be noted that complex/heavy fixes are undesirable (highly discouraged), as 'staging' branch does not have any testing grounds. +> It is up to the 'Release captain' to decide whether problem fixes are worth the additional time until release, but as a general rule, it should be noted that complex/heavy fixes are undesirable (highly discouraged), as the 'staging' branch does not have any testing grounds. ## The Release (timing depends on 'when it's ready'™) From 16f0bd81e9e3ce341629e9fd413702ea3cd8b8c8 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:10:35 +0300 Subject: [PATCH 30/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index f9206501ed..c387095087 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -152,7 +152,7 @@ If the hotfixes could not be finished or tested in time, we enter a Delay. The e If the fix gets completed before the 'End Time', then 'Release captain' can start the release immediately, but they are also free to just note it and leave someone else to do it later within the accepted Delay. -'Release captain' should reconvene at the End Time, to decide the continued fate of the blocking PR(s). At this point there will likely be Maintainer consensus established in some way, written decisions from the Lead Maintainers / Game Director, or Lead Maintainers will be present, but if they aren't, then the Maintainers present decide whether to revert the PR in question or go into overtime waiting for the fix. There is no script for after going into overtime. +'Release captain' should reconvene at the End Time, to decide the continued fate of the blocking PR(s). At this point, there will likely be Maintainer consensus established in some way, written decisions from the Lead Maintainers / Game Director, or Lead Maintainers will be present; but if they aren't, then the Maintainers present decide whether to revert the PR in question or go into overtime waiting for the fix. There is no script for after going into overtime. > It is up to the 'Release captain' to decide whether problem fixes are worth the additional time until release, but as a general rule, it should be noted that complex/heavy fixes are undesirable (highly discouraged), as the 'staging' branch does not have any testing grounds. From c169b0f64d3f0c781fe4b63ab95e442f995dedd7 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:10:58 +0300 Subject: [PATCH 31/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index c387095087..76385fc52a 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -150,7 +150,7 @@ If no blockers remain, go to The Release. ## Delay If the hotfixes could not be finished or tested in time, we enter a Delay. The expected maximum duration of the Delay has been agreed upon during the Maintainer meeting, and within this timeframe we should consider the delay acceptable enough not to be "concerned". -If the fix gets completed before the 'End Time', then 'Release captain' can start the release immediately, but they are also free to just note it and leave someone else to do it later within the accepted Delay. +If the fix is completed before the 'End Time', then the 'Release captain' can start the release immediately, but they are also free to just note it and leave someone else to do it later within the accepted Delay. 'Release captain' should reconvene at the End Time, to decide the continued fate of the blocking PR(s). At this point, there will likely be Maintainer consensus established in some way, written decisions from the Lead Maintainers / Game Director, or Lead Maintainers will be present; but if they aren't, then the Maintainers present decide whether to revert the PR in question or go into overtime waiting for the fix. There is no script for after going into overtime. From f9ec7726fec33e82a5c1f7063e8b9d013faa04d8 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:11:20 +0300 Subject: [PATCH 32/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 76385fc52a..94b324c118 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -125,7 +125,7 @@ Polls will be kept open until the official release time (roughly 24 hours later) >Binary votes leave no requirement for interpretation when they finish, so we don't need to have the Maintainer team assembled for closing up the release. Whoever is there can enact the results, even if alone, with no special pressure or responsibility for making "the correct call", since it has already been determined by (the best available) consensus. Afterwards, link the threads in #ongoing-votes and ping all maintainers. -``` @Maintainers Votes for reverts/hotfixes are up, please make sure to leave a vote, it will be closed in next 24h``` +``` @Maintainers: Votes for reverts/hotfixes are up. Please make sure to leave a vote; it will be closed in the next 24 hours.``` ## Week 4 - Sunday, before Release From 115e9bb15110e973c7c34468b54e0f969d426371 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:11:42 +0300 Subject: [PATCH 33/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 94b324c118..102513d8a0 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -135,7 +135,7 @@ Release can be postponed but status on hotfixes should be kept up to date by the ## Week 4 - Sunday, 21:00 - The Official Release Time -The Maintainers present can begin. If necessary, coordinate in the 'Release Review Thread' who's doing what. Close the votes and check the status of any other release blockers. +The Maintainers present can begin. If necessary, coordinate in the 'Release Review Thread' on who's doing what. Close the votes and check the status of any other release blockers. * If a vote's result is KEEP, the PR is no longer considered a blocker even if we want to later fix it. * If a vote's result is REVERT, create a PR to revert the feature from Staging. This does not require multiple maint approvals - it already has them from the vote. Since we are reverting a feature from master, before it ever hit stable, remove it from the changelog as well From 970b4168d1796657f276a9de4a1121c3549b60b5 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:12:20 +0300 Subject: [PATCH 34/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 102513d8a0..520c9a8b89 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -121,7 +121,7 @@ Feedback Pop-Ups is a feature that allows us to request players ingame to provid ## Right after the Meeting Votes are immediately started for blocked PRs. Open a Discourse thread for each vote in the Discord 'Release Review Thread'. If multiple PRs are conceptually linked, and/or were contested "as one", they can be combined into one thread. Copy the summary of the situation from the meeting notes for anyone who was not present at the Meeting. The recording might not yet be available for review before votes have to be cast. -Polls will be kept open until the official release time (roughly 24 hours later), so that every Maintainer can get their chance to vote. They must have only 2 outcomes, plus Abstain: such as Keep/Revert/Abstain, or Keep/Hotfix/Abstain. Abstain votes will not have any effect on the outcome, they merely serve to indicate that someone has seen the vote but is not participating. +Polls will be kept open until the official release time (roughly 24 hours later), so that every Maintainer can get their chance to vote. They must have only 2 outcomes, plus Abstain: such as Keep/Revert/Abstain, or Keep/Hotfix/Abstain. Abstain votes will not have any effect on the outcome; they merely serve to indicate that someone has seen the vote but is not participating. >Binary votes leave no requirement for interpretation when they finish, so we don't need to have the Maintainer team assembled for closing up the release. Whoever is there can enact the results, even if alone, with no special pressure or responsibility for making "the correct call", since it has already been determined by (the best available) consensus. Afterwards, link the threads in #ongoing-votes and ping all maintainers. From b90a70a4a3d4a0af802265c269bed5e634d4e174 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:12:55 +0300 Subject: [PATCH 35/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 520c9a8b89..da18ba453c 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -131,7 +131,7 @@ Afterwards, link the threads in #ongoing-votes and ping all maintainers. The proposed hotfix(es) can be prepared before release, but no one should feel forced to code just so we don't have a delay. If we are voting on a hotfix then we have already accepted a potential delay. It's also possible that the vote will decide to keep the PR, making the fix/change unnecessary. -Release can be postponed but status on hotfixes should be kept up to date by the 'Release captain'. +The release can be postponed, but the status of hotfixes should be kept up to date by the 'Release Captain'. ## Week 4 - Sunday, 21:00 - The Official Release Time From 91f2f23e202d2b66b482888bcf4ba7e70fa0ce22 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:13:22 +0300 Subject: [PATCH 36/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index da18ba453c..4796eb455e 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -19,7 +19,7 @@ The 'release captain' should start by creating a new instance of the checklist ( ### 1. Cut the staging branch -Announce cutoff 1 hour before starting, with a message in the #maintainers Discord channel. +Announce the cutoff 1 hour before starting, with a message in the #maintainers Discord channel. ```@Maintainers Hello crew, I will be coordinating this release. Staging cutoff in 1 hour.``` Cutoff can be postponed by the 'release captain' in case there are any problems with priority greater than P1. From 13a813c98ccb2d84e1d6cec67c4c59cecf6c5ef1 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:13:56 +0300 Subject: [PATCH 37/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 4796eb455e..7477b0ba2a 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -20,7 +20,7 @@ The 'release captain' should start by creating a new instance of the checklist ( ### 1. Cut the staging branch Announce the cutoff 1 hour before starting, with a message in the #maintainers Discord channel. -```@Maintainers Hello crew, I will be coordinating this release. Staging cutoff in 1 hour.``` +```@Maintainers Hello, crew. I will be coordinating this release. Staging cutoff in 1 hour.``` Cutoff can be postponed by the 'release captain' in case there are any problems with priority greater than P1. From 772c01f0272b737f46f9bc6dc85218eb705acf51 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:14:28 +0300 Subject: [PATCH 38/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 7477b0ba2a..08166400a2 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -22,7 +22,7 @@ The 'release captain' should start by creating a new instance of the checklist ( Announce the cutoff 1 hour before starting, with a message in the #maintainers Discord channel. ```@Maintainers Hello, crew. I will be coordinating this release. Staging cutoff in 1 hour.``` -Cutoff can be postponed by the 'release captain' in case there are any problems with priority greater than P1. +The cutoff can be postponed by the 'release captain' if there are any problems with a priority higher than P1. Otherwise run the `ss14-prepstaging` function from [Myra's powershell script](https://gist.github.com/VasilisThePikachu/762b90187a5f9a0cca3249cc335cab31). It does the whole cut for you: it fetches `upstream`, syncs your local `staging` with `upstream/staging` (**oldest** commit in the update), merges `upstream/master` into it and pushes the result (**newest** commit), then prints a ready-to-paste Release Review Thread skeleton (title, commit range, compare URL and a placeholder for the Outline doc link). From 71bd20d9c27665708162b367bc27c27cff874211 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:14:54 +0300 Subject: [PATCH 39/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 08166400a2..64db1f7d3e 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -24,7 +24,7 @@ Announce the cutoff 1 hour before starting, with a message in the #maintainers D The cutoff can be postponed by the 'release captain' if there are any problems with a priority higher than P1. -Otherwise run the `ss14-prepstaging` function from [Myra's powershell script](https://gist.github.com/VasilisThePikachu/762b90187a5f9a0cca3249cc335cab31). It does the whole cut for you: it fetches `upstream`, syncs your local `staging` with `upstream/staging` (**oldest** commit in the update), merges `upstream/master` into it and pushes the result (**newest** commit), then prints a ready-to-paste Release Review Thread skeleton (title, commit range, compare URL and a placeholder for the Outline doc link). +Otherwise, run the `ss14-prepstaging` function from [Myra's PowerShell script](https://gist.github.com/VasilisThePikachu/762b90187a5f9a0cca3249cc335cab31). It does the whole cut for you: it fetches `upstream`, syncs your local `staging` with `upstream/staging` (**oldest** commit in the update), merges `upstream/master` into it and pushes the result (**newest** commit), then prints a ready-to-paste Release Review Thread skeleton (title, commit range, compare URL, and a placeholder for the Outline doc link). >If you need to do it manually: >``` From 1cc6c2e8ddb93773e4ed2d708ba67678e7343bd6 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:15:21 +0300 Subject: [PATCH 40/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 64db1f7d3e..c8c702187f 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -46,7 +46,7 @@ Otherwise, run the `ss14-prepstaging` function from [Myra's PowerShell script](h >git push upstream staging >``` -Starting from this point, further merges into Staging should only happen if it's REALLY necessary, to ensure that we have time to review proposed changes and don't break things in the last moment. The process for this follows the [Hotfix Procedure](https://docs.spacestation14.com/en/wizden-staff/maintainer/hotfix-procedure.html). Revert or other changes may also be the result of a Maintainer vote after the meeting, this will be detailed below. +Starting from this point, further merges into Staging should only happen if it's REALLY necessary, to ensure that we have time to review proposed changes and don't break things at the last moment. The process for this follows the [Hotfix Procedure](https://docs.spacestation14.com/en/wizden-staff/maintainer/hotfix-procedure.html). Reverts or other changes may also be the result of a Maintainer vote after the meeting; this will be detailed below. ### 2. Create the Outline doc and open the Release Review Thread From 39cf6b1d40209607cbae5fa6b4f0d797c4c7ee23 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:15:44 +0300 Subject: [PATCH 41/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index c8c702187f..7332e685e7 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -78,7 +78,7 @@ Add any concerns/comments you have directly to the doc, you can also respond to #### The BLOCKER tags -If something is unfinished/broken/etc enough that maintainer thinks it should not be in the current release (in its current state), add a note starting with "BLOCKER", followed by the concern or reasoning. You can further add what hotfix/conditions you think could salvage the PR in question for the current release, or if it should just be reverted outright. +If something is unfinished/broken/etc. enough that maintainers think it should not be in the current release (in its current state), add a note starting with "BLOCKER", followed by the concern or reasoning. You can further add what hotfix/conditions you think could salvage the PR in question for the current release, or if it should just be reverted outright. Using this unambiguous tag will help us have a smoother meeting and make the later vote/hotfix/revert process easier to decide. If you do not mark your comment with BLOCKER, we will still go over it during the meeting but it will be treated as a "non-binding" lesser concern/suggestion/idea/future feature, not something that demands a vote. (If you will be at the meeting, you will still be able to change this to a BLOCKER then) From 7ea6d0ec1215ee372378266be3b854d6f05dfdfe Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:16:37 +0300 Subject: [PATCH 42/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 7332e685e7..340b4a303f 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -218,10 +218,10 @@ If there are merge conflicts at this step, note that you could publish stable be Specifically, these two servers sometimes restart for the patch but don't actually get it due to "funny network reasons". If this happens, any Maintainer can run ```!updateserver servername``` on Discord to restart them again. -### 6. Announce that the release is out and works on it are finished +### 6. Announce that the release is out and all work on it is finished -Notify maintainers that all works related to release are finished. +Notify maintainers that all work related to the release is finished. -``` @Maintainers Relase '' has completed, it's out on the CDN. If you notice any critical problems - please share them and make sure to prioritize hotfixes or reverts over other kinds of work. ``` +``` @Maintainers Release '' has been completed; it's out on the CDN. If you notice any critical problems, please share them and make sure to prioritize hotfixes or reverts over other kinds of work. ``` -'Release captain' should orchestrate works on any urgent fixes / reverts that might surface once the new version is available to players. Pay extra attention to Admin and Downstream (#space-wizards-enclave Discord channel) feedback. \ No newline at end of file +'Release captain' should orchestrate work on any urgent fixes/reverts that might surface once the new version is available to players. Pay extra attention to Admin and Downstream (#space-wizards-enclave Discord channel) feedback. \ No newline at end of file From e57ff77bb197013c26fac2e28d32e34623552a85 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:17:21 +0300 Subject: [PATCH 43/45] Update src/en/wizden-staff/release-procedure.md Yes it was supposed to be considerations :( sorry Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index 340b4a303f..bc64a4c5a9 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -87,7 +87,7 @@ Two such objections are required for a PR to go **instantly** to a revert vote ( #### In Absentia -These comments also serve as the best way for people who can't make it to the meeting to engage with the revert process in a fair way. If you can't show up but have a concern, leave a BLOCKER note along with your concern/reason/considtions, the meeting will not remove tags just because you are not there to argue for them. (Although if no one else seconds it before or during the meeting, then it will still not go to a vote) +These comments also serve as the best way for people who can't make it to the meeting to engage with the revert process in a fair way. If you can't show up but have a concern, leave a BLOCKER note along with your concern/reason/considerations; the meeting will not remove tags just because you are not there to argue for them. (Although if no one else seconds it before or during the meeting, then it will still not go to a vote) ## Week 4 Saturday 20:00 - Maintainer Meeting From cadfbfc9779ca3cc3a685b4151cd8d13def1c50e Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:21:19 +0300 Subject: [PATCH 44/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index bc64a4c5a9..e202e3be69 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -201,20 +201,20 @@ To do it manually, go to [github's web GUI](https://github.com/space-wizards/spa ![runpublish.png](../assets/images/wizden-staff/runpublish.png) -Make sure that publish workflow finishes green, and check changelog discord channel to make sure new updates are published. +Make sure that the publish workflow finishes green, and check the changelog Discord channel to make sure new updates are published. -// TODO - need to add steps that will create GitHub release record for new release, ideally without any additional manual actions +// TODO - need to add steps that will create a GitHub release record for the new release, ideally without any additional manual actions ### 4. If there were any hotfixes on Staging that weren't already merged back, merge Stable into Master. -This needs to be done via PR on github (because the master branch is protected from pushing). +This needs to be done via a PR on GitHub (because the master branch is protected from pushing). You can merge this PR by yourself immediately, but **DO NOT SQUASH IT**. -If there are merge conflicts at this step, note that you could publish stable before you get bogged down fixing the conflict for master so meanwhile the publish tests can run. +If there are merge conflicts at this step, note that you could publish stable before you get bogged down fixing the conflict for master, so the publish tests can run meanwhile. -### 5. Monitor if Salamander actually gets the new release after their next restart +### 5. Monitor whether Salamander actually gets the new release after their next restart Specifically, these two servers sometimes restart for the patch but don't actually get it due to "funny network reasons". If this happens, any Maintainer can run ```!updateserver servername``` on Discord to restart them again. From 9645cfeb41a58352e3f70cfed05eec2fe8285d95 Mon Sep 17 00:00:00 2001 From: Fildrance Date: Mon, 21 Sep 2026 13:22:09 +0300 Subject: [PATCH 45/45] Update src/en/wizden-staff/release-procedure.md RemFexxel fixing my typos Co-authored-by: Rem --- src/en/wizden-staff/release-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/release-procedure.md b/src/en/wizden-staff/release-procedure.md index e202e3be69..f7cf3899e6 100644 --- a/src/en/wizden-staff/release-procedure.md +++ b/src/en/wizden-staff/release-procedure.md @@ -107,7 +107,7 @@ If at least two Maintainers have chosen to block a PR, there will be a vote afte Agree now on **who** will start all the votes ('Release captain' should do it), so the votes don't get forgotten and to force the future vote-maker to double-check whether sufficient details about the votes have been noted down. (It sucks trying to figure out missing details by yourself after the fact) ### Hotfix votes -Optionally, some SIMPLE/straightforward change to the PR may be suggested. Such as tweaking numbers to something **specific** not just "it should do less damage", removing some specific, concrete part, or fixing a well-defined bug/issue. It should be discussed **who** will/might write this fix, not just hope that someone will start writing it afterwards. It does not need to be set in stone or a volunteer from the meeting, but we should have some idea at least. Final deadline for fix should be chosen right away, and actions upon not reaching results on said deadline. +Optionally, some SIMPLE/straightforward changes to the PR may be suggested. Such as tweaking numbers to something **specific**, not just "it should do less damage", removing some specific, concrete part, or fixing a well-defined bug/issue. It should be discussed **who** will/might write this fix, not just hope that someone will start writing it afterward. It does not need to be set in stone or a volunteer from the meeting, but we should have some idea at least. The final deadline for the fix should be chosen right away, and actions should be planned if results are not reached by that deadline. Since unlike a revert, a hotfix can't be finished in moments, we have to consider the possibility that there will be a schedule slip. As such, for hotfixing to be considered an option, we will specify an acceptable delay. **If we are unwilling to risk such a delay for the feature, then we should simply vote for a revert instead**, and fix it by the next release. Recommended default delay is 24 hours after the original expected Release. (Note that the time chosen is the maximum, we might finish sooner. But we should be willing to accept the full length of the delay. Record the delay's 'End time' in the meeting notes.