CONTRIBUTING.md

Contributing to this repo

First, thank you for your interest in contributing to this project! Before you pick up your first issue and start changing code, please:

1. Review all documentation for the module you're interested in.
2. Look through the issues for this repo for relevant discussions.
3. If you have questions about an issue, post a comment in the issue.
4. If you want to submit changes that aren't covered by an issue, file a new one with your proposal, outlining what problem you found/feature you want to implement, and how you intend to implement a solution.

For best results, before submitting a PR, make sure:

1. It has met all acceptance criteria for the issue.
2. It addresses only the one issue and does not make other, irrelevant changes.
3. Your code conforms to our coding style guide.
4. If you like, check out current PRs to see how others do it.

Special Note: If editing README.md, please conform to the standard readme specification.

Before a PR can be merged to master, it must:

1. Pass continuous integration.
2. Be approved by at least two maintainers

Conventions and Style

Imports

We use the following import ordering.

import (
        [stdlib packages, alpha-sorted]
        <single, empty line>
        [external packages]
        <single, empty line>
        [chain-validaion packages]
)

Where a package name does not match its directory name, an explicit alias is expected (goimports will add this for you).

Example:

package chain

import (
	"bytes"
	"encoding/base32"
	"fmt"
	"math"
	"math/rand"
	"strconv"
	"testing"
	"time"

	ffi "github.com/filecoin-project/filecoin-ffi"
	"github.com/multiformats/go-varint"
	"github.com/stretchr/testify/assert"
	"github.com/stretchr/testify/require"
	"github.com/filecoin-project/go-crypto"

	"github.com/filecoin-project/chain-validation"
)

Comments

Comments are a communication to other developers (including your future self) to help them understand and maintain code. Good comments describe the intent of the code, without repeating the procedures directly.

• A TODO: comment describes a change that is desired but could not be immediately implemented. It must include a reference to a GitHub issue outlining whatever prevents the thing being done now (which could just be a matter of priority).
• A NOTE: comment indicates an aside, some background info, or ideas for future improvement, rather than the intent of the current code. It's often fine to document such ideas alongside the code rather than an issue (at the loss of a space for discussion).
• FIXME, HACK, XXX and similar tags indicating that some code is to be avoided in favour of TODO, NOTE or some straight prose.