Jump to content

Arrow768

Head Admins / Devs
  • Posts

    1,664
  • Joined

  • Last visited

Everything posted by Arrow768

  1. Seconding the vote for dismissal. We already have issues with backseat command in the form of off-duty crew. Adding the role would just formalise that.
  2. I will close this within 48 hours unless there are any further concerns that have not been addressed or questions about the resolution.
  3. Alright, to bring this to a resolution. The lore masters have been required to establish a procedure for warnings so it is clear in the future what is and is not a warning. This has already happened. (Currently in the form of a internal topic; The lore procedure page on the wiki will be updated soonish) The whitelist strip is being maintained. I concur with the synth team and caelphon that the skirt-incident has portrayed behaviour that we do not want. You may use the relay to resolve events that have been interrupted by the whitelist strip. This has to happen in a timely manner. The established server rules on the relay have to be respected. The re-application period of 2 months is being removed. The lore team procedures currently only require a wait time for whitelist applications that have been denied (and not removals). Given that Lancer did not specify a wait time in the whitelist strip, I do not see the need to apply one now. This means that you could reapply instantly. The synth team will have to make a reasonable effort to work with you and establish requirements that you should fulfill before re-applying. You should contact lancer regarding this after this complaint has been resolved.
  4. Sorry, it took me a while to get back to that complaint. I had to handle some obligations outside of SS13. In the meanwhile I have checked the relevant logs to establish a timeline of the events. (Times: UTC+1) 2022-07-09 12:29.13: Character CSSU 32 Created & First Played 2022-07-15 12:29.13: Character CSSU 32 Last Played 2022-07-17 21:06:38: Character CSSU 33 Created & First Played 2022-08-02 07:34:27: "Skirt-Incident" 2022-08-10 20:05:59: Character CSSU 32 Deleted 2022-08-13 10:28:42: Removal of the whitelist 2022-08-13: Informed about the whitelist removal via discord by Lancer 2022-08-13: Staff Complaint against Lancer opened 2022-08-14: Staff Complaint against Lancer resolved 2022-08-15: Staff Complaint against Lancer and Caelphon opened Regarding your list of questions. 1. What took the SLT so long to tell me that the issue was a sex-bot cliché, and why did you have to tell me? They have told you that the sexual nature of your behaviour was unacceptable. (In the discord messages immediately following the whitelist strip) You have received sufficient information by them to avoid this behaviour in the future. I only provided some historical context why there is a strong stance against sexualized behaviour (from ipc players), that is not strictly necessary. 2. Why didn't the SLT inform me that they thought I was playing into this cliché and give me a chance to explain myself? They have determined that the incident in the screenshot is behaviour unbecoming of a IPC whitelist holder and decided to remove the whitelist as a result. The lore teams can remove whitelists on the first offense if they deem a incident severe enough. 3. What took the SLT so long since the incident, almost two weeks ago now, to bring it up? Was it reported afterwards? According to the timeline I have established, it took 11 days to look into that. In my opinion this is not a major issue, as it can take some time to properly investigate a incident, discuss it with the rest of the team and come to a decision. If the whitelist removal would have happened months after the incident, I would concur with you that this took too long, but in this case I think the timeframe is reasonable. 4. Just who reported this? Why did they wait this long, or why did the team wait this long? We never inform the person on the end of any administrative action who has ahelped them, as this can easily lead to harassment of the reporter. The same thing applies to lore complaints. If the lore team is supplied with information of unwanted behaviour, they investigate it and if needed apply corrective actions. But they never inform the person on the receiving end of corrective actions who reported it to them.
  5. Given that a pr for the exit functionality exists and two votes for the general access exist I am moving this to the archive.
  6. I would appreciate it, if you keep your replies concise and to the point. Having to comb through essays is not conductive to a efficient resolution of this staff complaint. Regarding your intentions. The matter of intention vs effect has already been explained by caelphon (and to some extend by myself). While your intention might not have been to engage in behavior unbecoming of a IPC whitelist holder, the effect of your actions was that you did. Regarding the unwillingness to discuss this issue via DM. When you choose to open the staff complaint you choose to try and resolve this matter on the forum in the form of a staff complaint. I have personally made the experience that if you communicate with someone that has a (staff-)complaint open, there is a possibility that they will (un-)intentionally misinterpret anything you tell them via DM and then try to "use" that on the (staff) complaint. For the people handling the complaint verifying any "they said via DM" claims makes it more difficult to resolve the (staff-)complaint. This is why I personally refuse to communicate with anyone that has a staff complaint open regarding the matter of that staff complaint via DM. It is also why I fully understand (and support) the decision of the relevant staff members to not communicate with you via DM until the relevant complaints are resolved. Regarding the ooc aspect. It would not have mattered if you had been noted/warned/banned for the incident in the screenshot. The lore team does not have to, is not expected to (and in most cases cant due to a lack of access) take warnings/bans into account when deciding if they should remove a whitelist or not. Getting a warning/ban for this incident would not have made a difference. I am still in the process of establishing a timeline and checking some logs. Once I have done that I should have answers to the list of questions/mistakes you have mentioned above.
  7. 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.
  8. 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.
  9. 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.
  10. Complaint closed without further action as requested by the OP
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. Binned as there is already a feedback topic up regarding the PR in question.
  19. 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.
  20. 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.
×
×
  • Create New...