The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
At Decentraland, we put a lot of effort into improving both the Software itself and the Software Process. The pillars of the Software Process are the standards we define to organize our work. This document describes contribution and style guides about how to write those standards.
The preferred type of contribution is a Github's pull request. Pull request to the master branch from your own fork or from a local branch if you have permissions (the branch will be deleted on merge).
We opened a channel to propose technical specifciations. Those MAY affect the product itself or the roadmap itself. To contribute with a technical specification you shall follow the guidelines of the proposals repository.
Issues are other very appreciated kind of contributions.
For opinions or open discussion feel free to join the chat.
The following are the Style rules that Decentraland's standard documents must follow.
Every Standard document MUST have a title related with the filename.
The filename MUST be enough to understand what content can be expected.
The filename MUST not contain spaces, hyphens should be used instead.
The filename MUST only contain lowercase alphanumeric characters or hyphen.
Every Standard document MUST contain right after the title a line specifying the document status:
**Document Status**: *Draft*. The possible status are:
- Draft. Work in progress.
- Standard. An Standard a specification or set of guidelines that, after extensive consensus-building, has received the endorsement of the Decentraland team.
The line should end with two white spaces to provoke a line break without starting a new paragraph. This will be useful for the next topic, the Maintainer.
Every Standard document MUST contain right after the document status a line specifying the document maintainer.
The maintainer should be specified with an address specification following the RFC2822 standard.
The angle-addr should be wrapped in a link link in the MAILTO format described in RFC3696.
**Maintainer**: Agustin Mendez <[[email protected]](mailto:[email protected])>.The maintainer has the responsibility of coordinating issues, pull requests and any other kind of feedback, plus to maintain the standard itself, by applying proactively changes to maintain it updated. In order to maintain coherence in the big picture, the maintainer should be someone participating in the architectural coordination process.
Every Standard document MUST follow the RFC 2119 and SHOULD contain a section following this style:
## Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).Every Standard document MUST have as fist section an introductory section following this style:
## Introduction
At Decentraland, we put a lot of effort into improving both the Software itself and the
Software Process. The pillars of the Software Process are the standards we define to organize our work.
This document describes style guides about how to write those standards.Documents that have a relationship with other documents SHOULD include a section following this template:
## Related Documents
To understand better the behavior of non fungible tokens refer to [ERC821](https://github.com/decentraland/erc821) documentation.Every document that contains external content must follow the content with a link to the references section labeled with the related reference:
### Avoid installing unnecessary packages
In order to reduce complexity, dependencies, file sizes, and build times, you
should avoid installing extra or unnecessary packages just because they might be
*nice to have*. For example, you don’t need to include a text editor in a
database image. [[1](#references)]Standard documents MAY recommend further reading. If that is the case the following template should be followed:
## Further reading
- Johnson, Mark (February 1997). [Building a Better ReadMe](http://www.ingentaconnect.com/content/stc/tc/1997/00000044/00000001/art00004). Technical Communication. Society for Technical Communication.
- Preston-Werner, Tom (23 Aug 2010). [Readme Driven Development](http://tom.preston-werner.com/2010/08/23/readme-driven-development.html). Tom Preston-Werner's personal blog.
- Streb, Claire (12 Sep 2015). [All Hail the README File!](http://clairenstreb.blogspot.com/2015/09/all-hail-readme-file.html). Claire N Streb - Expert Remote Senior Software Engineer's personal blog.Every document containing external references must contain a References section following the style of the template below:
## References
- [1](https://msdn.microsoft.com/en-us/library/ee658098.aspx) - Microsoft, What is Software Architecture?.