These guidelines are a community resource. They are meant to help guide and inform you through your development process and ensure the highest quality results in your smart contract system and your end product.
The Guidelines are constantly evolving with expert feedback. All suggestions made here are managed by expert members of our community, who have experience with the best practices and common pitfalls of secure smart contract development. Their wisdom is meant to help you on your journey
The Guidelines are meant to aid you in formulating your own software engineering process by giving a complete picture of all the different concerns and expectations in your software projects. Each section of the process has several articles about different topics you should understand during that step of the process. It covers the entire development cycle from planning to production support.
The Guidelines often do not tell you exactly how something should be done, but give you an understanding of what each concept is, why you should do it, who are the major parties involved, and some suggestions on how you can incorporate into your project. There are often multiple suggestions on how to do this, typically because the scale of your project and development team will dictate exactly how much structure you will need to be successful.
We encourage feedback. This is just getting started and we want to be sure we are meeting peoples needs. At a minimum, please hit one of the happy/sad faces.
For a more detailed response, please report an issue on our GitHub.
For the moment, if you wish to contribute, please submit an issue as above. We will add a more formal contribution section with a style guide, etc in the near future.