User Tools

Site Tools



We're glad you're here. There are lots of ways you can contribute to the OpenAg Initiative, including building a Food Computer, filing issues, writing documentation, and writing code. OpenAg is an open source project and we welcome contributions from anyone!

Filing Issues

If possible, file issues with with the appropriate Github project. To see a list of GitHub projects, go to Food Computer 2.0. If you don't know where to file the issue, file it here.

New to Github issues? Here's a video guide.


We welcome contributions from anyone! OpenAg software is licensed under GPL 3.0 and contributions must be released under the same license as the parent codebase.

New to Git and Github? Check out these video tutorials.

Pull request checklist

We welcome contribution from everyone. Here are the guidelines if you want to contribute:

  1. Contributions should be made in the form of GitHub pull requests. (Video: how to make a pull request)
  2. Each pull request will be reviewed by a core contributor (someone with permission to land patches) and either landed in the main tree (master) or given feedback for changes that would be required.
  3. All contributions should follow this format, even those from core contributors.

Some helpful guidelines:

  • Branch from the master branch before making changes. If it doesn't merge cleanly with master you may be asked to rebase your changes. (Video: how to make a branch)
  • Commits should be as small as possible, while ensuring that each commit is correct independently (i.e., each commit should compile and pass tests).
  • Tests must pass before a commit is landed. If the commit introduces significant changes, it should include tests and documentation.
  • If your patch is not getting reviewed or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment.
  • If your pull request is large, consider using this RFC template to help describe why you're requesting these changes.

Release management

  1. master must always be deployable.
  2. All changes made through feature branches (pull-request + merge)
  3. No code should land without relevant tests and docs
  4. All code should pass tests and be reviewed by a core team member before being merged into master.
  5. Releases should be tagged. Versioning should be done with semver.
  6. Dependency version numbers should always be locked in.

In general, we folllow this


Documentation can be found on the Wiki. Your contributions are welcome! You are free to edit and improve this wiki, as well as create links to pages you wish existed.

Translations are also welcome! If you want to contribute to translating doc see Translation page.

Communication and resources

  • OpenAg contributors hang out in the OpenAg forum. Anyone can join, and you can ask questions, share ideas and chat with other friendly folks.
  • development has tools and resources for setting up a development environment.
  • The Food Computer 2 wiki page has lots of other resources.


  • We are nice.
  • We are inclusive.
  • Everything is a tradeoff. There is often more than one right answer.
  • We take an iterative approach to engineering and design. The smaller the iteration loop, the faster and cheaper we can learn what works.
  • We try to be pragmatic.
contributing.txt · Last modified: 2017/04/19 22:31 by gordonb