Not a complete list but a few I’ve made note of:

• Familiarize yourself with this list of commonly proposed ideas.
• Swift language changes should provide a highly focused tweak with limited impact and measurable benefits.
• The baseline is not whether something is “nice to have”
• Fix real problems, not theoretical ones.
• A proposal should introduce a single distinct change. If a proposal introduces multiple changes, it should be separate proposals.
• Try to break things before 3.0 and not after.
• If a feature doesn’t yet exist, show how it provides additional and non-trivial utility. (Xiaodi Wu)
• If a feature should be removed, show how is harmful to the language or contrary to the direction in which Swift is evolving. (Xiaodi Wu)
• Emphasize safety, speed, and expression.
• Swift is an opinionated language.

Chris Lattner:

We intentionally want Swift to have a common “center of gravity” and be an “opinionated” language, rather than fall to the “design by committee” approach that leads to a watered-down design.  This means that decisions are really all shades of gray and cannot be specified or predicted by algorithm.  We aim to be as transparent as possible, and explain the rationale for decisions when they come out.

That said, I and many other people on the team are highly  motivated and effected by clear descriptions of problems being solved, and why current approaches are wrong.  Particularly moving are things written by people who are clearly familiar with Swift as it stands, and who speak to why a change will make Swift better.  

Someone saying “I saw thing X in language Y, so we should transplant it to Swift” – with no further justification – is not very motivating, because Swift is much different than any other language Y, and so the tradeoffs that make it compelling in Y may not translate over to make it compelling in Swift.