User Tools

Site Tools


Contributing to OpenAg

Welcome! 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! Our greatest strength is our curious, kind, inclusive, and open community.

This page helps guide you through the ways you can follow along with our research, engage with the OpenAg @ MIT Media Lab team, contribute to Food Computer development, and interact with the next generation of digital farmers.

How we work together

Joining or organizing a local group

See the page about Building Food Computers as a team for details about how to find people near you building a Food Computer or organize a new group in your city/country.

Working as part of a group will help you get started more quickly and cost effectively.

Filing Issues

If possible, file issues with with the appropriate Github project. To see a list of GitHub projects, go to our github.

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.

Contributor License Agreements

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 someone on the Core team (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.

Communication and Contribution 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/start.txt · Last modified: 2019/04/04 08:59 by prithvi