Arrow768

It is important to understand, that certain behaviour might not be against our ooc rules, while still violating the expectations put in place for whitelist holders. Your stripper-incident is definitely toeing the line towards being a ooc issue, but it was determined by administration that it will not be pursued as a ooc issue. Even if a specific incident is handled by administration, it does not prohibit a whitelist removal. See the head of staff / AI whitelists where we automatically remove them in case of any ooc punishment. (So even if the mods/admins had decided to apply a warning/ban a whitelist strip would still be "on the table"). For the species whitelists such a removal is under the purview of the relevant lore teams and can be performed if they think that the relevant conduct is in violation of the whitelist. Which is the case for the stripper incident, as it directly portrays behaviour that we do not want in IPCs due to the obvious sex-bot cliché. (This is where it becomes a "quality of the roleplay" issue) We have had issues in the past with synthetic players (IPC and borg) who have skirted the line towards the "sex bot" cliche and therefore have a relatively hard stance when it comes to behavior that skirts the line towards portraying a sex bot. While it might not have been your intention to portray a sex bot, the following screenshot demonstrates that more than one person thought that you were going in that direction. You have also continued the "joke" in LOOC instead of distancing yourself from it. The synthetic lore team has the capability to determine what is and is not acceptable role play for IPCs. They have determined that this incident is unacceptable roleplay for a IPC and sufficient to strip the whitelist without prior warning.

To make sure there are no wrong expectations from the start: Any further staff complaints about this issue will be closed immediately. I will look into it and get back to you once I have gathered some information.

Voting for dismissal. If the memory loss is removed the victims will immediately blab to security which would force the vampire to kill them. That just turns vamp into a changeling re-skin.

Complaint closed without further action as requested by the OP

Personally I do not see the need for a spawn timer in this case. The number of golems is limited by the number of raw materials available. Regarding: "letting other people have a chance at controlling a golem" - From what I saw there were additional golem spawns available that could have been used by anyone present.

Moved to policy suggestions as you want to change a standing policy. We used to have ai/borg laws that were similar to asimov. It resulted in the borgs attacking any non-human antag and generally interfering with the antags (playing bullet sponge, rushing into hostage situations to pull out hostages, attacking changelings, ...) Given all the problems we had with that lawset and law priorities that value the life of the crew above the borg, I am opposed to returning to that lawset / law priorities. I have no interest in returning to a situation where borgs are again allowed (and required by their laws) to rush into situation and try to meddle with the antags. I am voting for dismissal unless you can come up with a lawset that accounts for these issues and explain why it is a better option than the current lawset.

No it is not correct. The different roles/responsibilities will be explained in the upcoming document. Until that’s finished the important takeaway is to contact the maintainers if you have an issue with something on GitHub. (That goes for anyone who interacts with our public repo) Given that no additional points about weezys conduct have been raised (which this staff complaint is about) I will close this staff complaint.

Creating a review that differs from a review that someone else has already given, has nothing to do with "overruling", as it is not dismissing the existing review. It is only a different opinion on the mergeability of a PR (As devs can only dismiss reviews that have been addressed / are no longer relevant). If Matt asked them to clarify and they did not, then Matt (as a maintainer) has the option to dismiss their review. At the end of the day everyone here is a volunteer. If someone does not find the time (or forgets) to update a review, I do not have a major issue with it, as we have a process in place to handle out of date / invalid change requests. I am against imposing a enforced timeframe on reviews or re-reviews, as that will lead to a lowered code quality in the long run (as people will be obligated to "press though" a re-review. We have a process in place to handle out of date / invalid reviews. Use that process. I plan to create a formal document which details the different responsibilities of people that interact with our repository / update the contributor guide to include that. This might take a while depending on my free time. As I have already mentioned I have talked with weezy about his communication on GitHub, but also want to point out again that if there are issues on github to contact the maintainers. Unless there is something that has not been mentioned so far, I consider this issue resolved and will close the complaint within 24h.

I disagree with the notion that the changes requested tag has been used to stone-wall your PR specifically. Even if the changes required tag by weezy would not exist, it would not be merged as it is currently lacking the second approving review. Once the second approving review by a developer has been provided, and the changes required tag is still in place you have the option to inquire with the maintainers about the status of the PR. The maintainers can then decide if they want to dismiss the review requesting changes by weezy (or inquire with weezy to clarify the required changes). There is currently no specified timeframe during which a re-review has to be issued. There is also no requirement that a re-review has to be a approving review. A re-review by a developer can result in them dismissing their old review or requesting further changes. There are mechanisms in place to dismiss stale reviews. (Which has been used in case of PR #13977) In addition I want to point out, that we do not have a "guaranteed merge time". The timeframes we have set up (in this case: 3 days for non-bugfix-prs) are minimum waiting times. With all that said, I do not see how weezy is preventing your PR from being merged (stone-walling), as the conditions for being merged are not achieved at this time if the review by weezy wouldnt exist. (The review by weezy is also not preventing other developers from reviewing your PR). After a larger PR has been merged, we generally prefer if the person who made the initial PR also makes the follow-up tweaks to it. (This preference is also something that caused the creation of the revert policy.) The communication by weezy regarding your PR in question was not ideal as imho the transfer of the changes to the other PR and the reason for it should have been mentioned on the relevant PRs and not just on discord/the forums. However the reason for integrating your PR (wanting to avoid merge conflicts) is a valid reason and had a high change of being successful if the initial review would have been positive. (Especially if coordinated with the maintainers). New additions to the codebase are generally licensed under the AGPL or CC BY-SA. The AGPL / CC BY-SA does not require someone who copies/modifies the code to contact the original author (as long as they comply with the license requirements). I agree that it would have been better to communicate the reason directly on discord, but at the end of the day that would have been a courtesy and is not required. I also want to point out that the mechanism of dismissing stale reviews has worked on your PR (as weezys review has been dismissed and the PR merged after it has received two approving reviews). Generally if you have an issue with the way something on GitHub is handled (no reviews for a long time, stale review, ...) you can contact the maintainers. (The maintainers are basically the mods on our public repositories). This also goes for @RyverStyx With all that said, I will talk with weezy about his communication on GitHub.

I´ll handle that complaint. Regarding "blocking" PRs using requested changes and refusing re-reviews: Any developer can dismiss requested changes if the changes have been addressed. Any maintainer can dismiss requested changes for any reason. Developers / Contributors are not under any obligation to provide a re-review in a specific timeframe. If the previous review has been addressed it can be dismissed (for developers) / ignored (for contributors) Regarding copying content from a existing PR: Please explain what the problem there is.

Voting for dismissal due to the reason stated by @Gem In addition to that I am concerned that renaming it to „memory removal surgery“ indicates to players that this can (and should) be used outside of borgification.

Archived

Binned as there is already a feedback topic up regarding the PR in question.

Afaik Goldman was permanently transferred to Eridani as a result of a Incident Report with the alternative being to fire Goldman. If you want to bring him back to the station ship you would have to appeal the outcome of that IR. Doing so without appealing the IR in question would be considered bypassing a CCIA Action (and a OOC issue). It is certainly possible to appeal the CCIA Action and return Goldman. I do not recommend to do so, as some of Goldmans antics were rather "whacky" and he was primarily "saved" by the fact that a lot of the things he did took place during antag rounds where it was not possible to IR him effectively due to the possible antag involvement.

One of your main arguments is that the ERT are "faceless, heavily armored non-characters where as this is not the case with external ships. This claim is fundamentally flawed, as both the ERT and the external ship currently use the ghost spawner system to spawn in these characters. There is no rule in either case that forbids or requires characters that are more than faceless, heavily armored non-characters. (And with the current mechanics it is not possible to provide the ability to save/load a consistent character for the ghost spawners) If someone wants to play a "faceless, heavily armored non-character", they can also do that via the external ships. And if someone wants to play a character that is more than a "facless, heavily armored non-character" then they can also do that via any of the ERT teams. Another issue with the external ships, when it comes to the ERT, is that it is (currently) not possible to load them in at runtime without major lag spikes/issues. Therefore the "external assistance" is limited to w/e is loaded in at roundstart. Depending on what is loaded in at roundstart that might not actually be any assistance. I do agree that command should explore all other avenues before calling for a ERT (including arming the crew when possible). This is something that should be communicated to the command players and enforced by the mods/mins in the game. With all that said, I am voting for dismissal.

Yeah, I think CSO / Chief Security Officer is better. If we go for cos then we just need a sin (reporter alt title: "special investigative newsreporter") and a tan (bridge crew alt title: "technical advisor: navigation" for a "complete set")

Complaint closed.

If there are no further comments within 48 hours I will close this complaint.

I´ll handle that complaint. I have to agree with @Garnascus, that your behavior is considered validhunting and not something that we want to see from AI whitelisted players. A lot of antags rely on stealth to achieve their objectives. By outing them to security you have (obviously) alerted security that there might be something wrong with that character. After they are out of the cell it is quite likely that security will watch them using their own camera consoles thereby making it much more difficult for the antag to operate unmolested. To address some of the things you mentioned: It doesnt matter too much if you mentioned that conversation on the security channel or directly to the HoS. In either case, security has been alerted to the antagonist. We have specifically updated the laws to reduce the situations where AIs are obligated to report antagonists to security/command. (Note the "gain entry to high security areas", with the "high security areas" being defined in the Station Procedures and other alterations) The question when playing AI often isnt if you see/hear something but what you do with it. Often the preferred solution is to not notice / report on something unless you are specifically asked about it (or required by your laws to report it) Given that watching/listening to people (because you are bored) and immediately reporting them to security in case they do something suspicious (that you are not required to report by your laws) is not something we want to see from AI players I find the warning from @Garnascus to be justified.

I quite like the idea of "unfriendly" 3rd party ships. At the moment we (the maintainers) see them in the position of a "auxiliary" antag. They are not supposed to be "the main attraction" of the round and instead just be a "minor" side thing. We also do not want to see them as a "fixed thing" in every round, as that can quickly remove the novelty from them. With that there are the following restrictions: They should not occur during every round, so they do not quickly become "yet another antag shuttle". Their capabilities need to be restricted, so they do not easily overpower the crew/other antags There must be a certain variety in the sector, so it is ensured that there are not only "antag shuttle away missions" (there also need to be planets and other stuff) The canonity of them is another issue. As we have different ships that might or might not be canon, we need a way for the players to know if the interactions they just had were canon or not. We already have a system for that in place: the antag system. By integrating the (unfriendly) shuttles with that system it is possible to transparently communicate to the players that a certain shuttle / its crew members were antags and the interactions they had were non-canon. This integration allows other players to see who has been an antag at the end of the round. And it also allows the player on the third party ship to know if our antag rules apply to them or if they are bound by our "normal" roleplay standards. Next week I will look into creating a system ("unfriendly shuttle system") that integrates (hostile) third party shuttles with our existing antag/gamemode system and handles the above limitations. So it is possible to create PRs for "unfriendly" shuttles at this time, but they will not be merged until the system for the "unfriendly" shuttles is implemented. The existing PRs will also require some changes to make them compatible with the "unfriendly shuttle system" once it is implemented.

Trial successfully completed. Moving to the Archive.

Moving to the Archive as the Trial Ended and I forgot to archive it then.

I have looked into that. You were told by Alberyk not to use a VPN again after the first unban. And when asked about it, you explicitly denied using a VPN. When looking into the ban I found that you connected with a VPN again. (Contrary to what you have claimed in your post) Since you keep using a VPN, there is nothing I can do to help you. Appeal denied.

Binned as a duplicate.

The long term plan is to restrict the faction selection similar to the char names (You can only change it in the first N days after creating a character) Outside of that admin intervention is needed to change the corporation. This will most likely be implemented a few months after the launch of the NBT. (By then the active players should have moved their chars to the appropriate factions)