+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Please take a moment to review this document to make the contribution +process easy and effective for everyone involved. Following these guidelines +helps to communicate that you respect the maintainers' time in managing and +developing this open-source project. They should reciprocate that +respect in addressing your issue or assessing pull requests.
+The issue tracker is the preferred channel for feature requests and submitting +pull requests. There are some cases where the issue tracker should not be used:
+Sections on attacks and security best practices should include examples and +further reading. Security-related information is bound to change over time, +however. Content-related issues should flag areas that need more explanations +or contain outdated content.
+A well-written issue flagging areas of the Best Practices that need attention +are very beneficial - thank you! Some guidelines for content-related issues:
+Feature requests are welcome. But take a moment to find out whether your idea +fits with the scope and aims of the project. It's up to you to make a solid +case to convince the maintainers of the merits of an additional piece of content. +Please provide as much detail and context as possible. Keep in mind that the +Best Practices do not aim to mirror general security considerations that can +be found in the project's respective documentation. Additional content to the +repository should be original and flag potential pitfalls developers +might encounter when building Smart Contract systems.
+Reasonable pull requests - patches, improvements, new content - are a fantastic help. +They should remain focused in scope and avoid containing unrelated commits. +Please ask first before embarking on any significant pull request (e.g. +adding new content, refactoring example code). Otherwise, you risk spending a +lot of time working on something that the maintainers might not want to merge +into the project. Please adhere to the coding conventions used throughout the +project (indentation, comments, etc.). Adhering to the following this process +is the best way to get your work merged:
+# Clone your fork of the repo into the current directory
+git clone https://github.com/<your-username>/<repo-name>
+# Navigate to the newly cloned directory
+cd <repo-name>
+# Assign the original repo to a remote called "upstream"
+git remote add upstream https://github.com/<upsteam-owner>/<repo-name>
+git checkout <dev-branch>
+git pull upstream <dev-branch>
+git checkout -b <topic-branch-name>
+git pull [--rebase] upstream <dev-branch>
+git push origin <topic-branch-name>
+To maintain a consistent writing style across the documents, a few +considerations need to be taken.
+// INSECURE.Copyright 2016 Smart Contract Best Practices Authors
+Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in +compliance with the License. You may obtain a copy of the License at
+http://www.apache.org/licenses/LICENSE-2.0
+Unless required by applicable law or agreed to in writing, software distributed under the License +is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or +implied. See the License for the specific language governing permissions and limitations under the +License.
+ + + + + + + + + + + + + + + +