Skip to content

Latest commit

 

History

History
76 lines (59 loc) · 3.42 KB

CONTRIBUTING.md

File metadata and controls

76 lines (59 loc) · 3.42 KB
Raw

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. You have adequate test coverage (this should be indicated by CI results anyway).
  5. 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

Testing

  • All new code should be accompanied by unit tests. Prefer focused unit tests to integration tests for thorough validation of behaviour. Existing code is not necessarily a good model, here.
  • Integration tests should test integration, not comprehensive functionality
  • Tests should be placed in a separate package named $PACKAGE_test. For example, a test of the chain package should live in a package named chain_test. In limited situations, exceptions may be made for some "white box" tests placed in the same package as the code it tests.

Conventions and Style

Imports

We use the following import ordering.

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

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

Example:

package address_test

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

	"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/go-address"
)

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.