Arrow768

You should be able to implement quite a few of those things using integrated electronics by coupling it with a signaller. However I also understand the appeal of having them in the uplink.

I would like to note, that our forum rules include these two points:

I have severe concerns that this just ends up like that most of the time:

The thing is, a lot of events don't "add" anything to the round directly. However they contribute to the atmosphere of the game and add a certain amount of unpredictability to the rounds. I would approve of a way that allows engineering to prevent this event, however I do not support the removal.

Seconding the dismissal for the reasons stated above

Seconding the vote for dismissal for the above stated reasons

Sorry, for the time it took to get back to that topic. Ultimately DM knowledge is not the only deciding factor in a developer application. Another important factor is "social compatibility" with the current team and the willingness to learn. Therefore we are willing to accept people who might not have "great" knowledge of DM if they show the willingness to learn and the development team (as a whole) is willing to work with them. In addition we (the headdevs) generally assign projects to people that allow them to learn various aspects of our codebase. That has happened with drago during and after her developer trial and she has shown a good improvement in her DM skills since then. Regarding the reviews: All pull requests (with the exception of bugfixes) require at least two Reviews and have a waiting period of 3 days. This ensures that more than one person reviews a PR and catches potential issues with the code and the reviews. This system applies to both developer and contributor PRs. Once a PR is in "awaiting merge" maintainer is needed to merge a pull request. The only difference between developer and contributor reviews is that at least one approving developer review is required for a PR to reach the "awaiting merge" state. In addition, if you have any concerns with a review given, you can contact the reviewer and/or the maintainers to clear up any questions you might have regarding it / correct it if needed. (One example, where she gave a review which she later amended is not sufficient to warrant a removal from the dev team) After a discussion with the rest of the development team, we do not see sufficient reason to remove her from the development team at this time. I would also like to note a few things: A staff complaint is not exactly appropriate to address concerns you might have about the performance of a staff member. "For complaints against members of the staff team. Disagree with a judgement? Conduct? An action they've done? Post it here." If you have issues with a decision they made or their conduct in their capacity as a developer, then a staff complaint would be appropriate. For other cases it would be better to inform a headev/maintainer We (headdevs) are aware of the difference in skill and activity between the developers. I care very little about the concerns "people you have talked to" have regarding the performance of someone on the development team. If they wish to express those concerns, they can approach a headdev/maintainer. We do not prevent or punish anyone, including developers, from creating PRs that are controversial or not fully thought out. We make use of draft PRs and the WIP flag (although the WIP flag should at some point be abandoned in favor of the draft PRs) In the worst case the PR is closed without being merged and the creator of the PR wasted their time on it. The only thing that would currently get you a repo ban is using github features in bad faith (which only happened 3 times so far, with two bans lifted) Unless there are further comments I´ll close that complaint in 24h

Actually, looking at it closer, the overall design is much less resistant against intruders than the current design. The shield generators are gone from the core entrance The turret is gone from the core entrance (instead the entrance is only partially covered) The walls to the outside are thinner (and can be breached faster) The back entrance to the AI core is way too easy to breach now, as there isnt even an r-wall that need to be breached to get into the core You have a lot of space around the elevator making it much easier to mount a offensive and setup triage/staging areas right down at the AI core. This seems more like a nerf disguised as a buff than a actual improvement.

The window into the bunker is a nogo, as that is a very severe weakspot. Readd the double r-walls to the bunker.

So to sum up the complaint: You don't think Drwago is good enough to be a developer on the staff team? @Kaed

I do not appreciate being quoted out of context. The quote that was posted refers to a alleged claim "that its not possible to speed up the spawn menu by using vuejs because it is using browse()" In addition, I do not see how Lohikar is involved in this.

Voting for dismissal for the reason mentioned above. If something should be done its a reduction of the number of fuel tanks around.

Seconding the vote for dismissal. We are a HRP server, so you should always roleplay the same way, no matter if there is a antag or not.

I disagree with the way the PR is implemented. Imho it is sufficient to just remove it from the secret rotation. If the intent is to fully remove it, then it should be fully removed from the code aswell, as (due to the magic of git) the code can always be looked up in the future.

I disagree with the way the PR is implemented. Imho it is sufficient to just remove it from the secret rotation. If the intent is to fully remove it, then it should be fully removed from the code aswell, as (due to the magic of git) the code can always be looked up in the future.

No, not until the new PR has been merged and live for a while.

Well, half of the people wanted a reevert and the other half want it to be kept, that isnt sufficient for a immediate revert. The difference between those two groups is statistically insignificant (due to our small sample size of 180) The above mentioned PR will be merged once it´s reviewed and then we´ll see how that worked out and if additional changes are needed.

29 People prefer the current system. 51 People prefer the current system with adaptations If we sum that up, we are at 80 people. Those are 44% of the total number of people that voted. 87 People prefer the old system. Those are 48% of the total number of people that voted. The difference between those numbers is just 4%, so the decision if it stays or goes will be made by the headmins/devs. Regarding the last post by @AmoryBlaine : I have no idea what you are asking there.

Which is being implemented, as I already posted.

Because about half the people are in favor of keeping the system (with adaptations)

Well readding is just a question of mapping in the mirrors against. The species itself still exists in the game.

Emergency Maint Access is moved to the command console with that PR: https://github.com/Aurorastation/Aurora.3/pull/7654 This allows a single head of staff to enable emergency maint access.

This has been polled on the server for the last week and that are the results: Querstion: Count - Answer 13 - I do not care. 29 - I prefer the current maint access (Restricted). 51 - I prefer restricted maint access with less restrictions on elevated alert. 87 - I prefer the previous maint access (Semi-Restricted).

The suggestions and ideas section of the forum is for things that development team can implement. Could you please clarify what it is that you want us to implement. If you are seeking a discussion about security procedures then that topic can be moved to general. If you want to suggest a ic or ooc policy change then you should update the op with the policy you want to suggest and we can move that topic to policy suggestions.

Moving to rejected policy due to two dismissal votes.