Skip to content

docs: enhance CONTRIBUTING.md with improved structure and guidelines #344

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

docs: enhance CONTRIBUTING.md with improved structure and guidelines #344

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
154 changes: 72 additions & 82 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,115 +1,105 @@
# Contributing to the Smart Contract Security Best Practices
# Guide to Contributing to Smart Contract Security Best Practices

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.
Thank you for your interest in improving our project! This document will help you understand the contribution process and make it as effective as possible for all participants.

## Table of Contents

- [Using the Issue Tracker](#using-the-issue-tracker)
- [Content-related Issues](#content-related-issues)
- [Feature Requests](#feature-requests)
- [Pull Requests](#pull-requests)
- [Style Guidelines](#style-guidelines)
- [Review and Acceptance Process](#review-and-acceptance-process)
- [Community and Support](#community-and-support)

## Using the Issue Tracker

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:
The issue tracker is the preferred channel for feature requests and submitting pull requests. However, there are cases where the issue tracker should not be used:

- Please **do not** use the issue tracker for personal support requests to ask
the community for help. There are many Discord and Telegram communities
around Smart Contract development where people will be more than happy to
help.
- Please **do not** derail or troll issues. Keep the discussion on topic and
respect the opinions of others.
- Please **do not** use the issue tracker for personal support requests or questions to the community. There are many Discord and Telegram communities dedicated to smart contract development where people will be happy to help you.
- Please **do not** derail or troll issues. Stay on topic and respect the opinions of others.

## Content-related Issues

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:

1. **Use the GitHub issue search:** Check if the issue has already been
reported. If the issue is already present, use a thumbs-up reaction to
help the developers prioritize.
2. **Check if the issue has been fixed:** Try checking out open pull requests
and development branches. The problem you are looking to flag might already
be fixed.
3. **Isolate the problem:** An excellent content-related issue shouldn't leave
others needing to chase you up for more information. Please try to be as
detailed as possible. If content needs fixing across multiple areas,
please flag one issue for each case.
Sections on attacks and security best practices should include examples and additional reading materials. Security-related information may change over time. Content-related issues should point to areas that need additional explanations or contain outdated content.

Well-written issues that flag areas of Best Practices requiring attention are very helpful - thank you! Here are some guidelines for content-related issues:

1. **Use the GitHub issue search:** Check if the issue has already been reported. If the issue already exists, use a thumbs-up reaction to help developers prioritize.
2. **Check if the issue has been fixed:** Try checking open pull requests and development branches. The problem you want to flag may have already been fixed.
3. **Isolate the problem:** A good content-related issue should not leave others needing to ask you for additional information. Please be as detailed as possible. If content needs fixing across multiple areas, please create a separate issue for each case.

## Feature Requests

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.
Feature requests are welcome. But before proposing, make sure your idea fits with the scope and goals of the project. It's up to _you_ to make a compelling case for the merits of additional content to support the project. Please provide as much detail and context as possible.

Remember that Best Practices does not aim to duplicate general security considerations that can be found in the project's respective documentation. Additional content should be original and point out potential pitfalls that developers may encounter when building smart contract systems.

## Pull Requests

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:

1. [Fork](http://help.github.com/fork-a-repo/) the repo, clone your fork,
and configure the remotes:
Reasonable pull requests - fixes, improvements, new content - are fantastic help. They should be focused in scope and not contain 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.). Following this process is the best way to get your work merged:

1. [Fork](http://help.github.com/fork-a-repo/) the repository, clone your fork, and configure the remotes:
```bash
# Clone your fork of the repo into the current directory
git clone https://github.com/<your-username>/<repo-name>
# Clone your fork of the repository into the current directory
git clone https://github.com/<your-username>/smart-contract-best-practices
# 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>
cd smart-contract-best-practices
# Assign the original repository to a remote called "upstream"
git remote add upstream https://github.com/ConsenSys/smart-contract-best-practices
```
2. If you cloned a while ago, get the latest changes from upstream:
```bash
git checkout <dev-branch>
git pull upstream <dev-branch>
git checkout main
git pull upstream main
```
3. Create a new topic branch (off the main project development branch) to
contain your new content, change, or fix:
3. Create a new topic branch (off the main project development branch) for your new content, change, or fix:
```bash
git checkout -b <topic-branch-name>
```
4. Commit your changes in logical chunks. Please adhere to these [git commit
message guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
or your code is unlikely to be merged into the main project. Use Git's
[interactive rebase](https://help.github.com/articles/interactive-rebase)
feature to tidy up your commits before making them public.
4. Commit your changes in logical chunks. Please adhere to these [git commit message guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), or your code is unlikely to be merged into the main project. Use Git's [interactive rebase](https://help.github.com/articles/interactive-rebase) feature to tidy up your commits before making them public.
5. Locally merge (or rebase) the upstream development branch into your topic branch:
```bash
git pull [--rebase] upstream <dev-branch>
git pull [--rebase] upstream main
```
6. Push your topic branch up to your fork:
```bash
git push origin <topic-branch-name>
```
7. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/)
with a clear title and description.
7. [Open a Pull Request](https://help.github.com/articles/using-pull-requests/) with a clear title and description.

## Style Guidelines

To maintain a consistent writing style across the documents, a few
considerations need to be taken.

1. **Succinctness:** Use precise language and don't assume knowledge beyond
Solidity and Ethereum basics.
2. **Show, don't tell:** Examples speak more than a lengthy exposition.
Provide code examples where relevant and raise issues or best practices
in the code around them.
3. **Give credit:** When further reading is recommended or resources are
available that corroborate security issues, they should contain credit
and link to the original resource.
4. **Label code:** Examples containing code must be labeled as insecure or
secure where relevant. Specifically, in content regarding attacks,
vulnerable code should be preceded by `// INSECURE`.
To maintain a consistent writing style across the documents, a few considerations need to be taken:

1. **Succinctness:** Use precise language and don't assume knowledge beyond Solidity and Ethereum basics.
2. **Show, don't tell:** Examples speak more than a lengthy exposition. Provide code examples where relevant and raise issues or best practices in the code around them.
3. **Give credit:** When further reading is recommended or resources are available that corroborate security issues, they should contain credit and link to the original resource.
4. **Label code:** Examples containing code must be labeled as insecure or secure where relevant. Specifically, in content regarding attacks, vulnerable code should be preceded by `// INSECURE`.
5. **Markdown Formatting:** Use proper Markdown formatting to improve readability:
- Use headings (`#`, `##`, `###`) to structure the document
- Highlight important terms using **bold** or *italic*
- Use code blocks (``` ```) for code examples
- Create lists using `-` or `1.`, `2.`, etc.

## Review and Acceptance Process

After submitting a pull request, your changes will be reviewed by the project maintainers. The process typically includes:

1. **Initial review:** Checking for compliance with style guidelines and general applicability.
2. **Discussion:** Possible discussion of the proposed changes and requests for additional changes.
3. **Acceptance and merging:** After approval, your changes will be merged into the main codebase.

Please be patient during the review process and be prepared to make additional changes upon request.

## Community and Support

If you have questions about the contribution process or need help, you can:

- Join our [Gitter chat](https://gitter.im/ConsenSys/smart-contract-best-practices)
- Ask a question in the relevant GitHub Discussions section
- Follow project updates on [Twitter](https://twitter.com/ConsenSys)

We value your contribution and strive to make the process as smooth and productive as possible!