Synergy's update process {#server}

Believe it or not, but Synergy's update record hasn't always been great. In fact, the update to 1.8 took almost 4 months. Granted, there was the whole Mojang-ownership + Bukkit DMCA fiasco at that time (and for a bit nobody knew the future of Minecraft servers in general), but truthfully we didn't really know what we were doing at the time either. Since then, we've made some major changes to how we handle new versions of Minecraft, which allows us to perform the fast and (mostly) painless updates that our players have come to love. Here's what our TODO list looks like when we see a new version of Minecraft on the horizon:

  1. Identify plugins that may break with the predicted API changes or break each update anyways.
    1. If one of these plugins appears to be abandoned then fork the source code and make the changes ourselves.
  2. Wait for the new Minecraft version to drop and for the Spigot team to update to it.
  3. Upload the new server version to Synergy's test server, which is a near-identical environment with the same plugins and configurations.
  4. Our plans diverge here depending on the type of Minecraft version it is:
    1. If a plugin is broken then continue to #5.
    2. If everything is working properly:
      1. If the minor version number is greater than 2 (> x.x.2) then skip to #8.
      2. Otherwise, still go to step #5. Why? Because Mojang hasn't been great recently with the first updates after a major revision to the game.
  5. Wait 2 days or so for bugs to be fixed and plugins to be updated.
  6. If plugins still are broken and the fix is relatively small, then fork the source code and make the change ourselves.
  7. Thoroughly test all plugins on the test server (again) to make sure everything is working. If necessary, repeat from #6.
  8. Once everything is looking fine, then Synergy is shut down and a full server backup is made.
  9. Upload the new server jar and updated plugins.
  10. Start Synergy up again and pray that nothing breaks!

If we tested everything properly then there shouldn't be any issues with using the new version and the process should have taken less than a week. It's a fairly straightforward procedure, but the two important things to note are that we start preparing for problematic plugins before the update is even released, and that we take matters into our own hands if a plugin's authors are being too slow to update it.

SynergySuite's update process {#suite}

You may think that our custom plugins are entirely coded by four birds that peck at keys whenever they mistake a floating dust particle as food. Well, you would be wrong because that's not how SynergySuite 2.0 was made. It's how 1.0 was made. Anyways, if you're wondering how the five birds do their job, then here's what goes on behind the scenes for each update we make:

  1. For determining what's going to be in the next update, we refer to the super-duper top-secret roadmap for Synergy's future that outlines our plans for the next dozen updates.
    1. Each update is centered around 1 or 2 major features or a collection of smaller features.
    2. Minor bug fixes and miscellaneous smaller features are also included in each update, but we get to those as soon as we can instead of planning for them to be released in a specific update.
    3. Updates happen an average of every 2 months, though, of course, we fix major bugs as soon as possible rather than waiting until the next update.
    4. Many features that we have planned were suggestions by members of the server, so don't be afraid to share your ideas! If we like your idea, then we'll be sure to add it to the todo list of miscellaneous things or even the main server roadmap!
  2. The code for the last update is forked so that we retain a backup of the old code in case we need to revert to it later.
  3. Our developers implement the features and bug fixes but we would be lying if we said that it wasn't mostly bugs at this stage.
  4. The development version of SynergySuite is uploaded to the test server and is rigorously tested.
  5. Bugs are shaken out of the code and wet wipes are purchased to sanitize the area.
  6. Steps 4 and 5 are repeated as necessary (sometimes dozens of times).
  7. When we can't find anymore bugs to squash, we make a backup of Synergy and upload the new plugins.
  8. A Roundup™*not actually trademarked, please don't contact the government for trademark fraud is made and posted on the subreddit so that everyone can see what has changed.

The promotion process {#promotions}

Think that promotions on Synergy are random? You're probably wrong, though I'm not certain whether or not the other staff roll a die to vote as well. What's that you say? Flipping a coin would be simpler? Well, nobody has ever claimed that our promotion process was efficient. Anyways, once a player has met the minimum criteria for the next rank in line, this is the process the staff team uses to determine the fate of their promotion:

  1. Flip a coin

Just kidding. Here it is:

  1. A staff member takes note of the player under consideration, and writes their name and suggested rank in a vote-tracking Google Doc. (Fun fact: We use a table inserted into a Google Doc to keep track of votes instead of simply using Google Sheets. Stop staring at us like that.)
  2. Staff members vote on the player, choosing the simple Yes/No/Neutral options, or expanding on their opinion with a short 26-page, 51-paragraph paper with illustrations and data tables for further clarity.
  3. If a staff member votes "No" on a promotion, then they explain their concerns about the player and other staff members take it into consideration.
  4. If a player under consideration obtains the minimum number of votes necessary for their next rank then we move on to the next step. Here's the breakdown for the number of votes a player needs for each rank:
    1. Member: 1 vote. Staff members usually promote a player to Member without adding their name to the voting doc and waiting for other input from staff.
    2. Devoted: 2 votes.
    3. Trusted: 3 votes.
    4. Helper: 4 votes.
    5. Admin: 5 votes.
  5. For higher ranks (and occasionally Devoted), a staff member double checks for a last-minute veto from other staff.
  6. The player is promoted when a staff member is online at the same time as them. If we keep missing the player, or if they haven't logged on in a while since the time of their voting, we often promote them when they're offline.
  7. The rest of the staff is notified of the player's promotion (unless it's to Member because then literally a third of the Discord staff chat would be promotion announcements) and the name is removed from the voting document.

Synergy's backup process {#backups}

If there's a list of things that scare the staff team, the third item on that list would be the server crashing. The first would be crashing and losing data (The second item isn't really relevant to the purposes of this document but let's just say that it involves thumbtacks in sandwiches). For trying to prevent against data loss as much as we can, here is our backup process: