Doc meant to establish how we will treat adding new roundstart species, as well as their requirements. A bit too long to summerize properly.
For some bonus info, here is a discussion that we’ve had about species previously
Heres to hoping i set this up correctly
In general I think the doc is really well-written and mostly what I had in mind as well.
I commented on GitHub with a list of things from my own notes I would like to see added before merging, including some definitions, technical requirements for making a species PR, and a list of examples with good and bad traits for reference (some from previously declined species).
Yeah personally I also see no issues past what I have already listed in my review. My main issue is the fact we should not list species by name in the doc itself as designs can change and be improved upon, or allow any species to bypass those requirements.
If those parts are addressed I think the doc will be alright.
Vulps only a week away 
I think the doc is very well written.
Only issue I see is with the requirement for
It must not be able to be selected round-start by new players.
We have guidebook entries for species, instead of outright blocking the more complex species, simply open the guidebook for that species when selecting it for new players.
I agree with Simyon, it should be available with a proper warning. Ideally - species selector UI like something in Baldur’s Gate 3, where you have all the info about currently selected option right in the same screen.
Since the discussion has stalled, I will be opening a vote for the design document sometime later today or tomorrow.
Just gotta figure out how to open a vote since these are public :^)
Can you not make a vote and restrict the roles that can vote?
Edit: yes
Yeah I was told how to do it in staff channels
The poll is now open in the initial post!
I hope I didn’t mess it up
I added one more change request about the topic of accessibility to be added to the doc, because that is something that contributors often got wrong in past proposals, for example forced colorblindness, extra bright flash effects etc.
And I would like the other (still open) review comments to be addressed before merging, but those are relatively minor.
Otherwise it’s a great doc. Amazing work @FairlySadPanda 
I have several major concerns with this document that i’d like to see revised before merging.
Rule 2: New Features and Tech Improvements
A species must represent an opportunity for evolving the Space Station 14 design space or codebase. This can involve either a completely new feature or a significant remix of an existing feature, representing the opportunity for code improvement, or exploration of a design idea that has not been done before.
I don’t think this is a logical requirement for new species to be added. I would argue that none of our species, even ones that had strong mechanical features when they were added (dionae, vox, 4-handed arachnids) meaningfully evolved the codebase in any way. While features that technically develop the codebase are appreciated, this seems like an unsuitable requirement to attach to a species document.
It is not neccessary to fine-tune balance at point of proposal. “This species is better in cold climates and moves slowly in warm ones” is preferable to “this species takes 20% less cold damage and moves 20% slower when in environments above its own core temperature”.
It is actively discouraged to “bolt-on” upsides and downsides that distract from the core theme and identity of the species, especially at time of proposal. A species’ design is far more important, and far harder to fix, than its mechanics.
I would rather this general section be reworded to better reflect common issues with species balancing. A large amount of balance pains come from species additions that, while thematic and arguably serve to reinforce the concept of a species, end up doing so through a myriad of small balance tweaks. I think it would be better to focus this section on adding a hand-picked selection of noticeable modifications rather than simply focusing on a core identity.
A species must not be intentionally designed in a way that makes them specifically good or bad at one particular job on the space station. For example, a short, bearded humanoid species fond of drink and industry should not be, by design, better at being a miner or salvager than any other member of the crew. An ability they have that is useful in those roles should also be useful in other roles.
This section of the document is criminally vague. The following section carves out that ‘emergent’ proficiency at a job is permissible, so what is this intended to block? Many jobs are defined not by entirely unique mechanics, but by an increased proximity to one particular mechanic.
For example, immunity to barotrauma is a broadly useful trait for any character to have, but it most directly serves salvagers and engineers, who by far have the most direct interactions which require being in space suits.
Overall, I would prefer to see this more fleshed out rather than just tacked under a general section about balance. Balance is one of the most hot-topic issues with species design as a whole and has a lot of nuances regarding it.
Speciesism is banned on Wizard’s Den in its entirety. As such, species must not directly encourage the “othering” of those that play those species - for example, causing health problems in those around them, or being incapable of socializing or interacting healthily with the rest of the crew.
This is another section that I think is poorly defined. The examples given are too vague to actually understand what the intent is: I’m not sure what a species that is ‘incapable of socializing’ would even look like. To some extent, the existence of largely alien species exists to allow players to feel innately separated from others (this is in large part the fantasy of Vox), while I don’t think there should be species that exist solely to be the target of speciesism (or feature that dynamic as a large part of their identity), this section as written unnecessarily limits the design space of species as a whole.
If a species is significantly challenging to play as, compared to normal round-start species, the following rules apply:
- It must not be able to be selected round-start by new players.
- It must not be able to be picked if a random species is chosen.
- It should not be added to the potential species drawn from for antagonists such as Nuclear Operatives.
In general, I think these are mostly symptomatic of our underwhelming character creator. I think instead of innately barring these actions (which would be very annoying to players from other servers who are experienced with the game), we should do the following:
Rule 8: Circumvention of Intentional Game Design
Species must not circumvent a significant portion of gameplay.
An example of circumventing gameplay would be an implementation of a robot species that allowed players to completely ignore the Medical department via self-repair with tools. Or, due to experiencing no equivalent to hunger or thirst, ever needing to visit the chef or bartender.
I agree with this section though I think it’s inherently a bit limiting. Robotic species are quite popular, and a core component of that identity is not needing traditional food or drink. Even if they have a power drain mechanic which mimics these, it would still invalidate the need for the chef or bartender.
Perhaps this would be more logically bisected into two different types of gameplay: hard mechanics like medical systems, atmospherics, spacing, etc. that must not be circumvented, and soft mechanics like food/drink, flashes, etc. that may be circumvented if given an alternative that mirrors them. For example, a plant species may not experience normal hunger, but they should still be able to eat food and should additionally require receiving nutrition of some kind from an alternative source.
Consultation should be taken from players before deployment of significant re-designs or changes in concept to a round-start species are merged to stable. This may involve seeking feedback from players on the test server about the changes, making players aware of the changes via the Discord, and so on.
[ . . . ]
Outright removal of a species that has been deployed outside of an event (such as April Fool’s) or a test-merge to Vulture must be agreed to by a maintainer vote, after consultation with the Wizard’s Den player community. Alternative remediating steps should be considered first, and full deletion should be considered a last resort.
Policy changes should not be included in this document, especially ones as poorly-defined as these. There’s little outline given for what consultation, feedback, notifying, or remediation would look like.
This entire section as a whole has little actual purpose: is it supposed to outline policy or instruct what species design modifications should look like? As it stands, I don’t see why it should be included here at all. This section would be better served by outlining best practices for overhauling, such as amending design documents.
I already left my feedback on Github, and I mostly feel strongest about not putting policy stuff in the document. The rest reads fine.
I think it kind of has to be vague. Any feature is going to have some sort of benefit for one job or another, and there will always be strictly speaking a “best” species for any given job. But what we don’t want is a “meta” species, such that any specific species is either locked out of or trivializes a noticeable part of a role. And where that line is drawn is kinda fuzzy and depends on the job/mechanic.
I’m not saying it couldn’t be written better, but I think it’s gonna be hard to not have it be sort of a greyzone.