Kyet

Lately, lots of things have been competing for my time. I need to focus on the most important stuff, the stuff that will make the biggest difference to my life in the long term. Things like my career, relationships, etc. I have a lot of big goals, and I need serious focus to achieve them. So, I'm stepping down as a head on Paradise. To free up some time, and mental energy, for working towards my goals. I might stick around for a bit as a regular game admin. We'll see. In the meantime, I wish you all the best, and remember: never let videogames stand between you and your dreams.

Thank you for posting this.

I don't think this is a good idea. For one, it seems like it is just gonna get used to harass borg players. For another, the best use for it (giving a borg player a medal) is weird, because... borgs are technically property, not crew, so it would be weird to give them a medal. I'm quite sympathetic to the idea that borgs *should be* crew, but right now I don't think they are, which would make giving them medals weird.

Yes, I'm against it. Snow really makes zero sense indoors, especially indoors on a space station. While in theory you can create it with a machine, why would you? In practice it'd just make getting around onerous, not to mention issues with temperature, visibility, etc. Also, having it year round would make the xmas period less special.

There's a fax machine in a room on the left, which connects to Syndie HQ. Please think carefully before using it.

On green, its considered powergaming, and not okay. On red (ie: with a known threat) its permissible. Drones should probably not do it regardless of code level. They should focus on repairs. Drones installing new cameras comes across as ghosts just trying to make the antags fail.

I don't object to the addition of a labeling system, but I am also very skeptical it would help. How exactly would it make life easier for the maints/heads, bearing in mind that heads cannot label PRs? You'd need a convincing answer for that. Intuitively, I agree with you. In practice though, you're not taking into account (and historically, I have failed to take into account) that: maints can get an enormous amount of harassment over even normal PRs, and this is even worse for PRs they object to. AA just did an announcement within the last few days complaining that he got 14 DMs in the space of a few *hours*. Imagine dealing with dozens of DMs per day, every day, about PRs. In practice, you would quickly get super tired of this and it would make you re-think your willingness to publicly state objections to things if you thought it might lead to yet another hour of being deluged in DMs. maints are volunteers, and there's a limit to the amount of free time they can afford to spend doing free work for paradise without it hurting their real lives. While it may sometimes be frustrating for PR authors, ultimately the more time they spend arguing with authors over why their PR does not deserve to be merged, the less time they have for actually merging other things, and the worse the PR backlog gets. Sure, in theory simply stating their objection won't become a long argument, but in practice it often does. there are some extremely toxic people on github who will raise UNHOLY HELL about even trivial, terrible quality PRs being rejected. Such people are incredibly energy-draining to deal with. The maints having to spend time on those people is demoralizing. I've been told this week that the reason I get away with having a "always explain my objection reasons on the PR" policy, and don't get harassed as a result, is that people fear me. Unsurprisingly, I mostly disagree. For one I don't think most PR authors fear me. For another, I think that by stating my objection reasons publicly, I have demonstrated I am quite willing to defend my position, and that makes people less willing to challenge me over it. There are also other factors, such as the fact I think maints get a lot more harassment over PRs in general than heads do. Another possible factor is personality differences. Essentially most of the maints and some of the heads dislike coming into conflict with other people, and really don't enjoy having to argue. Deep down, they want agreement. In comparison, not only am I totally comfortable with disagreement, I even enjoy arguing at times (I spent a fair amount of time in college debate clubs, arguing for fun). I'm also used to operating in environments where consensus is impossible, yet decisions have to be made, so you have to accept some pretty sharp argument (and the fact some will leave unhappy) as the price of admission. All combined, this means that most of the maints/heads are a lot less willing to explain their objection reasons than I am. And to a large degree this is understandable. While I'd certainly *prefer* they explained all their objection reasons in public like I do (it hasn't always been easy, but I do believe it gets easier the more you do it).... in practice that just may not be doable for them, and certainly not without asking them to go against their instincts, natural way of doing things, etc. And while it might obviously be fairer for PR authors if all objections were accompanied by a reason... in practice if I had to choose between the other heads/maints always giving an explanation for their actions... and y'know... actually getting the work done... obviously I'd prefer they actually get the work done. So I guess what I'm trying to say is... we can't force the other heads/maints to always explain their objections. And even if we could, the time that would require might be counter-productive. What we can do is reduce the cost they perceive for doing so, largely by making sure that people aren't allowed to harass maints over their objections. Which we are doing. Via the new guidelines on github. So yeah, I sympathize with your point of view. Still, instead of looking at it from an "is this fair to me as a PR author?" angle, I would encourage you to instead look at it from an "given the limited time/energy/morale/etc of the maints/heads, when is it worth, or not worth, explaining an objection?" angle. Because while sometimes it clearly is in the best interests of the project for it to happen... other times... its just sapping maintainer/head morale for no benefit.

S34N: ~59% of all PRs have a head approval. There's ~21% another of PRs that are either pure fixes or refactors that either way already don't require head approval. Thus, the chances of head approval being the thing holding up any given PR is less than 20%. Approximately 63% of head-issued approvals for PRs are issued by me. Removing the requirement for heads to approve feature PRs is not an option. That would just put even more of the work onto the maints. As is, we serve as a sort of filter that stops maints wasting time with things that obviously won't work for design reasons. The requirement for our approval lets us reject those so we prevent them wasting maints' time. We also buffer some of the toxicity from players, so they don't have to deal with it. Ideally we would appoint new maints, but its almost impossible to find candidates for the position of maintainer that are acceptable enough to all the existing heads/maints that they can actually be added. I went on somewhat of a crusade during my two years as head+host trying to get more maints appointed, and even then I was only able to get one extra maint (AA) in the end. Politically, getting a maint appointed requires an extreme level of agreement among not just the heads but also all the existing maintainers. It is an incredibly difficult process. I've always been keen on the idea of junior maints but frankly with all that has been going on in my real life lately I quite simply don't have the energy for such a difficult task right now. Stokes52 In general, getting a feature PR merged usually requires (A) one head approval (B) one maint approval and (C) no heads or maints objecting. When I post a review of a PR that has a green check mark / marked as approved, I am saying that I am voting for that PR in my capacity as a head. Now it requires only (B) and (C) to be merged. I use my reviews to make my votes public. I have tried to encourage other heads/maints to adopt this system too, but most of them don't want to, partly as they dislike dealing with backlash on github. They don't like having to explain why they object to PRs, because they don't want to deal with PR authors messaging them "what do you mean, my code is terrible" or "what do you mean, you don't need another X in the game". When I post a non-approving review with the word "objection" in it, I indicate that I am voting against the PR. A head or maint voting against a PR doesn't automatically kill it, but it does make it MUCH harder for it to pass. Generally it can only pass at that point if another head votes for it regardless, a maint votes for it too, and a discussion is held among the heads/maints which ends with the resolution that it will still be merged despite the objection of at least one head or maint. As for progress indicators, you should probably assume that if it has a head's review/comment explaining that they like the PR, then its waiting for maint approval. If it doesn't, it is still waiting for head approval.

Good writeup. More generally, good job with the setup. Hopefully readers walk away from this with a better understanding of what being host is like.

May 15 Kyet has stepped down from the position of Server Host. He remains a Head of Staff. AffectedArc07 has taken on the position of Server Host, in addition to remaining a Maintainer.

April 10: Vargh has retired from Game Admin April 22 Drakeven has gone on leave as a Game Admin May 5 SpacemanSpark has retired from Game Admin May 7 Pineapple Salad has passed their Trial Admin period and been promoted to full Game Admin May 9 eler00 has retired from Game Admin

The code that handles our forum/Discord integration has been updated. The main change is that the code now uses the latest Discord API. This is important, because Discord is going to turn off the old API, so had we not updated, our Discord integration would have abruptly stopped working sooner or later when Discord did that. Other then that, the update is mostly just bug fixes. Don't expect any obvious difference. If you do notice anything odd, though, let me know.

My real life has become so busy, that I can no longer afford the time to host Paradise. So, over the next month, I will be stepping down, and our resident Java expert@AffectedArc07will become the new host. This means: All-new servers (with higher specs!) will be built. My hope is that the new AA-rated servers will have better performance. Our backend will be replaced. I expect the new backend to be better, and provide better tools. The number of coffee-related jokes in our Discord will increase at least 20%. For the next few weeks, my focus will be on ensuring a smooth transition. That means providing all the necessary documentation, training, etc. Before you know it, though, AA will be running the entire backend of Paradise. Probably with a Barista supporting him. Hosting is a fair chunk of work, so please be nice to him, and patient with him if he says he is busy. To answer the inevitable questions: Exactly when is the switchover happening? => When AA is ready. Don't rush him. He's rebuilding every server we have, using brand new technology. It is important to take our time and get it right. The road towards switching may be long, taking a few weeks, but it arcs towards progress. Will my ping to the server be affected? => No. The new server will be in the same datacenter, with the same great connection, as the old server. Is AA staying as a maint, as well as being host? => Yes. He's doing both now. He might even do the billing paperwork for the servers himself. You could say 07 has earned his license to bill. Is Kyet staying as a head? => Yes. You can't goat rid of me that easily. I'll be around, at least until the transition is complete. After that, it depends on how busy my RL gets.

The vision I outlined on the PR. Basically it lets newbies practice mechanics in peace, without having any significant impact on the round. Also, the official name for it is Syndicate Space Base (SSB). While I did make that up... its also what I called it in the code, so if you invent another name for it it'll get confusing. There are many issues with moving syndi jail there: Someone with a tracking implant could be abducted, allowing a whole army of sec to use the teleporter to teleport to their location and invade the base. Prisoners could be killed, maimed, etc, which was not intended by @Mochito happen when syndi contractors were added. If the base was destroyed, there'd be nothing stopping 'captured' prisoners from escaping instantly. Even worse if the base is spaced.... captured prisoners would be returned dead. If we went this road (and I'm skeptical of it, frankly) then we'd have to only allow researchers to TALK to the prisoners.... and relay whatever info they give to other traitors over comms in exchange for a reduced 'abduction' timer.

Take our current vox population. Now give them an excuse to drink everything in the bar. Improvement?

Here is what I propose granting: Mentor: - autopatrol, patrol (we should not need to double-check the edits of mentors, and they can check others' edits, giving both of these out more widely would make the unpatrolled edits list special page much more useful) - rollback (any editor can already revert someone else's changes, this permission makes it a bit easier) - suppressredirect (players can already move pages, this just lets them do so without a redirect - useful in a few cases but not something most editors need) Admin: - delete, delete-redirect, deleterevision, deletedhistory, deletedtext, browsearchive (all these permissions are about removing stuff or seeing removed stuff, so maybe admin-only, but since deleted stuff can be viewed with the "undelete" permission its less "delete" and more "hide for most people". Even then we basically never use these - the best argument for "delete" is "lets us delete old/outdated files" like old images of which there are over 200 on the slated for removal list) - block, hideuser (this is basically banning, but only for the wiki, and given how the wiki requires forum auth, we should probably keep this admin-only, I don't see us ever needing it, its really just an emergency-use-only button) - mergehistory, suppressionlog, viewsuppressed (this covers "private logs", so perhaps admin only) Nobody: - unwatched pages (useless, its a list of basically every page/file, its not helpful)

March 15: TheSardele has retired from their position as Game Admin

Getting roundstart random disabilities would suck. Especially if you're in an important crew position. Even more so if you can't just fix them with mutadone. It would be extremely annoying. No thanks.

Personally, I would prefer it if it was simply never allowed to unwrench pipes to counter ventcrawling antags. For exactly this reason - from the antag's perspective its often uncounterable gameplay. Their options become "stay in the room and eventually get swarmed and killed" or "attempt to run through the pipe anyway and pop out right next to someone who is prepared to shoot/axe you". That said, I made this change anyway because the other two heads wanted it. Its one of the cases where I implemented something I don't personally like because of its popularity with the rest of the staff.

Voted in favor.

I am fine with having a dedicated staff member whose job it is to oversee the wiki. I am also fine with giving expanded permissions to: - Mentors (e.g: patrol, autopatrol, maybe rollback?) - Wiki Contributors (unsure what I'd give them) - Some sort of new not-an-admin-but-has-curator-permissions-on-the-wiki role (maybe delete pages, probably not bigdelete/blockuser)

Feb 15: pineapplesalad has joined the team as a Trial Admin Feb 24: The following Game Admins have retired: Saxis tullybburnalot Twinmold Dadman234 / Da Dman234 Tayi / Tayswift Brandon / BrandonSacawv

For what it is worth, I am rarely in the Bridge as Captain, and yet I rarely get killed. I do, however: Max my suit sensors at roundstart, and then re-max them after any kidnap attempt Drag the blueshield around with me if I am going anywhere except brig and he's available. If he's not available... wait for him to be available, or get a sec officer as an escort, or go alone but be more cautious. Give the blueshield the pinpointer too so they can locate me via the disk I always carry Avoid acting like security, this includes chasing threats who attack you too far - instead just set them to arrest and let sec pick them up Avoid entering maint unless its a shortcut to a non-maint room you're running to (e.g. hop office maint tunnel shortcut to mechanic) Call for backup earlier than you think you need it If attacked, scream for help + location on radio Avoid standing in any dangerous area Avoid letting anyone chase or follow you - if they seem to keep following you, mark them Move very fast, such that if someone loses sight of you for 3 seconds, they will never catch up Get pre-scanned Use the door remote.

Some items (e.g: Mirror Shield) are very strong. Maybe too strong. Not sure if this is the best way to deal with that, but it does have other benefits as well (like encouraging them to go after their sac target earlier, instead of just before summoning). So, maybe. Personally the thing that really gets me is the fact that even ERT are quite limited in dealing with mirror shield cultists, especially if they also have other high power cult items.

I would support a PR which removes glowshrooms' ability to self-replicate. I might even support nerfing them even more then that, such as by just preventing you from planting them anywhere except hydroponics trays.