Arrow768

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)

Sounds reasonable

The primary goal of the ghost spawned visitor is to prevent security from valid-hunting everyone who is not on the crew manifest by providing a “harmless” canon role that is just missing their paperwork. That enabled other antags to use the “paperwork issue” excuse.

We have 2,5 places where "official" lore is represented: The wiki The forum news section (To some extend the game itself) Due to the (fast moving) nature of discord conversations, discord is absolutely unsuitable as a authoritative source on lore. Therefore the wiki and the forum are always the leading system and the authority in case of any "lore conflicts". Lore writers have the capability and procedures to update the wiki / forum news database and are expected to do so. They can clarify minor things on discord, but they key facts are expected to be on the wiki / forum. And again, in case of any conflict, the wiki / forum are the authoritative source not what any lore writer said via a discord message. People have the capability to make up their own lore to some extend as long as it is believable and does not conflict with existing lore. This applies both to things that happen in the game and on the discord.

I am against a strip of command whitelists that is not covered by our existing rules. The main argument for a strip is that command players who have not played in a year will not familiarize them with the changed mechanics, rules and lore. I do not believe that this warrants a strip as all of them have already shown the capability to write a backstroy that is in line with the lore and familiarize themselves with existing mechanics. (They had to learn those from somewhere aswell) It it my believe that the majority of command players will familiarize themselves with the changed aspects of the game before they play a command role. Those that do not, can be dealt with administrative actions. A accelerated whitelist process (where former whitelistees only have to do the trial) is imho not contributing to resolve this issue, as anything that should get a trial denied should also result in a whitelist strip. Instead I suggest to enforce the existing rules and strip the whitelists of those that have not linked their forum account to their byond account (as required by the existing whitelist rules).

I do not remember things like that in the recent history. That said, if something like that happens it is a very quick way to a perma ban

And I have moved it back since I misread the initial post and the suggestion is not to change the procedure, but to just update the Template-Post in the IR Forum

I do have to clarify something here. If you lie on your IR to get another person in trouble and it is discovered through logs that you have lied, that becomes a OOC matter. Other than that CCIA can only issue IC actions. I have moved this policy suggestion to the archive as it is already implemented and nothing new is suggested.