Our intent with the standards is to define technical standards. From wikipedia:
A technical standard is an established norm or requirement in
regard to technical systems. It is usually a formal document that
establishes uniform engineering or technical criteria, methods,
processes and practices.
Our expectation is that we will all follow the standards. If we find that a standard is not useful or has become an obstacle; we change the standard. The emphasis on defining standards is to really be careful, recommending the basic standards we need at gilt to be productive without being prescriptive about details that actually don't improve cross team collaboration.
When we talk about standards, we are talking about collaboration with other teams as well as 3rd parties. From this point of view, our standards are (deliberately) very basic requirements, mostly influenced by our combined experiences of working with 3rd parties. Things that make our lives easier as 'consumers' of 3rd party APIs are things we now like to do ourselves for our internal APIs as well. Gilt standards are requirements for work at Gilt.
We also highlight suggestions or recommendations; and they are just that - you can diverge. We recommend something because we have good experiences with it, we intend to support it and it gets the job done. That said, if you think you can do better - that's perfectly fine, all it means is your team might be on its own and will need to support the choice.
Our intention here is to provide guidance without imposing too much. We trust you and your team to have good judgement. You can treat RECOMMENDATIONS as standards, if you wish, the difference here is that you can diverge if there's a good reason.
Changes to standards need to get architecture board's approval