This style guide is a living document that evolves with the Swift language. It is different from others you may see, because the focus is centered on readability for print and the web. We created this style guide to keep the code in our books, tutorials, and starter kits nice and consistent — even though we have many different authors working on the books.
We appreciate and encourage contributions from the community that improve this document and hence the quality of tutorials we produce. This document outlines the process for making contributions to the guide.
Note: You are responsible for adding your name to the list of contributors should you desire.
Uncontroversial, non-additive changes such as misspellings, grammar or compiler errors can be fixed by simply issuing a pull request to master. The maintainer will merge the pull request or, if it is deemed "controversial" request the contributor open an issue so that other members of the community can participate in the discussion.
Authors at RayWenderlich.com are expected to follow all of the rules in this style guide unless special circumstances apply. Because of this, it is important that updates happen at predictable times. Be aware in advance that there may be a significant delay (many months) before a suggestion is ratified on the master branch.
Open an issue on github and describe the change you would like to see or rule that you would like to have added. You can even propose the exact change in github markdown which can be pasted into the guide.
Wait for feedback on the issue. Even if the feedback is negative, don't close the issue too quickly. Often times the discussion itself can be useful and give way to something even better. Style guides are very subjective and it is important to always be respectful. We expect participants to follow the same community guidelines as the Swift project itself outlined at contributor-covenant.org
The maintainer will decide if a change is go or no go. This decision is not necessarily based on the feedback of the community, but will often play a role. If you believe that the maintainer is mistaken, you can appeal the decision by just asking them. At this point the maintainer will poll the RayWenderlich team leads for a final decision with RayWenderlich acting as tie breaker if required. Apologies in advance if your style suggestion isn't accepted. You are always welcome, however, to make your own style guide for your organization or community!
Given the go ahead from the maintainer, create a pull request on the update branch in the repo. There should be one of these. If it is not clear what it is, ask the maintainer. The current update branch is update.
At this point your involvement is complete. The maintainer will merge your PR to the update branch.
The RayWenderlich.com team has a chance to look at the final updated document before it is merged to master. If an objection is raised, as with the appeal process, teams leads will deliberate on the final decision.
Hurray!