Skip to content

Latest commit

 

History

History
76 lines (42 loc) · 3.94 KB

CONTRIBUTING.md

File metadata and controls

76 lines (42 loc) · 3.94 KB
Raw

Contributing

Wow, we really appreciate that you even looked at this section! We are trying to make the worlds best atomic building blocks for financial services that accelerate innovation in banking and we need your help!

You only have a fresh set of eyes once! The easiest way to contribute is to give feedback on the documentation that you are reading right now. This can be as simple as sending a message to our Google Group with your feedback or updating the markdown in this documentation and issuing a pull request.

Stability is the hallmark of any good software. If you find an edge case that isn't handled please open an GitHub issue with the example data so that we can make our software more robust for everyone. We also welcome pull requests if you want to get your hands dirty.

Have a use case that we don't handle; or handle well! Start the discussion on our Google Group or open a GitHub Issue. We want to make the project meet the needs of the community and keeps you using our code.

Please review our Code of Conduct to ensure you agree with the values of this project.

We use GitHub to manage reviews of pull requests.

  • If you have a trivial fix or improvement, go ahead and create a pull request, addressing (with @...) one or more of the maintainers (see AUTHORS.md) in the description of the pull request.

  • If you plan to do something more involved, first propose your ideas in a Github issue. This will avoid unnecessary work and surely give you and us a good deal of inspiration.

  • Relevant coding style guidelines are the Go Code Review Comments and the Formatting and style section of Peter Bourgon's Go: Best Practices for Production Environments.

  • When in doubt follow the Go Proverbs

  • Checkout this Overview of Go Tooling by Alex Edwards

Getting the code

We recommend using additional git remote's for pushing/pulling code. Go cares about where the ach project lives relative to GOPATH.

To pull our source code run:

$ go get github.com/moov-io/wire

Then, add your (or another user's) fork.

$ cd $GOPATH/src/github.com/moov-io/wire

$ git remote add $user git@github.com:$user/wire.git

$ git fetch $user

Now, feel free to branch and push (git push $user $branch) to your remote and send us Pull Requests!

Pull Requests

A good quality PR will have the following characteristics:

  • It will be a complete piece of work that adds value in some way.
  • It will have a title that reflects the work within, and a summary that helps to understand the context of the change.
  • There will be well written commit messages, with well crafted commits that tell the story of the development of this work.
  • Ideally it will be small and easy to understand. Single commit PRs are usually easy to submit, review, and merge.
  • The code contained within will meet the best practices set by the team wherever possible.
  • The code is able to be merged.
  • A PR does not end at submission though. A code change is not made until it is merged and used in production.

A good PR should be able to flow through a peer review system easily and quickly.

Our Build pipeline utilizes Travis-CI to enforce many tools that you should add to your editor before issuing a pull request. Learn more about these tools on our Go Report card

In order for the code to be merged with a Pull requests we require a test file that covers the logic of the type. Refer to the Go blog post on code coverage metrics.

References

Format Specification