User Tools

Site Tools


contributing:start

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!

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 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.

Contributing

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 someone on the Committers 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 https://gist.github.com/17twenty/6733076

Documentation

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.

Philosophy

  • 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: 2017/05/19 18:15 by gordonb