Quickie guide to making a design doc, and why you should do so

[Generaldonothing]

Alright, you got this crazy good idea... now how do you present it? You create a design document, that's what!

Why you should make a design document: 
1. Allows you to express your ideas in a controlled enviroment
2. Helps you express your ideas to others in a controlled easy to understand way
3. Makes giving feedback to your idea significantly easier

"But what if I just want to PR it and hope for the best?"
Don't do this. Your PR is more than likely going to be closed due to it.
"Oh, it won't be that big of a deal if I just PR it without consulting the dev team-"
Actually it will be, either A. your PR takes forever to approved or B. gets rejected later on. Consult the dev team at the very least, likely with a design doc.
If you have this idea in your head "It's better to ask to be forgiven than request approval" now is the time to lose it. It is a massive PITA for pretty much *everyone* to deal with, people who actually want to do something similar will be discouraged to, dev team will need to look over the PR and more than likely say "No, this is bad, talk to us about this next time".
Oh and for fucks sake test your PR, a TM is not a suitable time to be testing your PR either, test it beforehand thoroughly. 

Ok, general PR stuff out of the way, let's get in to the actually design doc related stuff.

Alright, let's assume that you have an idea and that you're going to contact the dev team. You should be sending them a design document.
Now, what to put in that document?
1. All changes your attempting to make should be in that document
2. Reasons why you're making those changes
3. Why those changes are better than the current system in place
4. Why this new system is more fun than the older system
5. Why the older system was bad
6. Coding required for the newer system
If you cannot answer one of these, don't procceed with the change. 

1. All changes your attempting to make should be in that document
I cannot stress this enough, if you are making a change say that you are making it. !SURPRISE FUN! is god awful, trying to bundle something with another change to make it more likely to get merged is *awful* and should be avoided at all costs. 
Example: You want to change an ability the wizard has, you need write down all changes that will be made
Wizard fireball
Cooldown increased from 6 second -> 10 seconds
Damage increased from 45 ->60
Knockdown increased from 4 seconds ->6 seconds
This is good, you have identified what you're changing and you've stated exactly what it is being changed in a legible format.
 

2, 3, 5.  Reasons why you're making those changes
In this example, this will both cover 2 and 5.
Explaining why you are changing these specifics is good, getting your point across for people to judge is the point of a design doc after all. These often all are in the same kind of section. Changes without any merit behind them will be rejected.
Example: 
5 +3 . Currently the fireball spell is used primarly as an almost hitscan projectile to spam down choak points every few seconds, the gameplay this encourages is boring (This isn't a very good reason, but it's an example). We are altering this to become a nuke the wizard can throw, and it serves the role of a high burst damage option in a long range setting which will allow for further counterplay.
2. The total cooldown is being increased so that the wizard needs to play more carefully with their fireball spell. The total damage is being increased along with the knockdown to allow the wizard to follow up with different abilities easier.

4. Why the new system is more fun than the older one
Explaining why it's more fun is important, as the core of balancing is making the majority of players have their "fun level" be maximized. Balancing fun in this kind of game is expecially difficult, remember to always consider everyone affected by this, expecially the person on the receiving end. 
Good fun reasoning: We are changing to stamina combat due to it making combat extremely binary. If you are able to stun someone (be it through an RNG weaken or a taser), you win that encounter. Everything that doesn't stun (or does not directly counter a stun) is almost useless due to the power of stuns. Stamina combat is less binary while still giving room for nonlethals to be effective, and discourages the "stun and run" playstyle people find to be frusterating. Both crew and antagonists will have their stuns removed and replaced with stamina based items.
- Applies to everyone
- Actually explains why this change will make things more fun
Bad fun reasoning: We are buffing the garrote as it is currently weaker than many other traitor items. This item should be functional compared to other options, it no longer requires you to be behind people on use, and instantly puts them in a kill grab.
- Only adresses the person using the garrote
- Does not explain why it will be more fun, only that it will be more effective
If a design document does not make something more fun, it will *almost certainly* be rejected.

6. Coding required for the new system
It is a very good idea to learn the systems that the system you want to add interacts with, making a design doc is half the fight, from there you need to actually code it. If you are not sure how to code it yourself, ask for help. Outlining how you plan to implement the system codewise is also a very good idea.

Congrats, you now understand the bare basics of writing a design document. 
Personal note: Heya, I wrote this while sleep deprived and will likely be editing this later. Getting a design doc shut down is fine, although improving it is also a good idea. Plenty of docs will be slammed to the floor, but keep at it.
Mostly wrote this up due to a bunch of people seeming to not want to write documents, which imo is pretty dang weird, and only really makes sense if you don't know how to do so.