Add a better Contributing guideline

[gaearon]

We should explain:

• Constraints (e.g. no flags, no configuration)
• Strategies (find good defaults, good heuristics can make)
• Actively find ways to improve DX (e.g. remove noise, implement things you didn’t see in other tools but wish were there)
• Try to make the least controversial choices (would that work for 95% of users? would beginners understand this?)
• Coordinate on an issue in case somebody else is already working on the PR you want
• If you submit a PR please provide a test plan (how did you verify it works?)
• Release guidelines (how to run the script, update changelog etc)

[ghost]

@gaearon Would it be reasonable to assume we want to include this content into a CONTRIBUTING.md? Or would we want to go with the Wiki page route?

[lacker]

For "Try to make the least controversial choices" - I think we need to go a bit farther, and say, if the community is split between N different tools, then we won't just pick the least controversial, the tool itself should be agnostic between them. Like installing redux by default would be less controversial than installing mobx by default but that doesn't mean we should do it.

[gaearon]

Would it be reasonable to assume we want to include this content into a CONTRIBUTING.md?

Yes.

if the community is split between N different tools, then we won't just pick the least controversial, the tool itself should be agnostic between them

Agree.

Like installing redux by default would be less controversial than installing mobx by default but that doesn't mean we should do it.

Yes. Also worth noting that we are only currently interested in solving build problem, not runtime dependencies. We leave you with React and let you be (for now).