Skip to content

Contributing

Looking to contribute to Gibbon? Awesome, you're in the right place. Gibbon is a work of volunteer labour, built with love and passion by people just like you.

You can contribute your time and expertise many ways. For example, you might:

A huge thank you 💜 to our growing team of volunteer developers and translators for their ongoing work to make Gibbon better for all of us.

How to report a bug

Before submitting a bug, please do the following:

  1. Make sure you’re on the latest version, your problem may have been solved already!
  2. Perform basic troubleshooting steps and note the steps required to reproduce the bug.
  3. Check the bug/issue tracker and planning board to make sure it’s not a known issue.

Submit the bug by creating an issue and follow the template provided for what to put in your bug report.

❗ If you find a security vulnerability, do NOT open an issue. Please email support@gibbonedu.org instead.

How to suggest a feature

To request new features, please use the Feature Requests category in our support forums. You can find more info about planned features and upcoming releases on the Gibbon Development Road Map.

How to help translate

Thanks to some amazing volunteers, Gibbon is available in several different languages. If you would like to help translate Gibbon, please email support@gibbonedu.org. Your help would be most appreciated!

How to submit a pull request

The Gibbon philosophy is to perform small, easily tested changes to an ongoing development branch. An ideal pull request adds one feature or fixes one bug at a time. If you're unsure where to begin with GitHub feel free to reach out on the Support forum or check out these great guides: makeapullrequest.com and opensource.guide

  1. Fork the GibbonEdu/core repository on GitHub and clone a copy on your local machine.
  2. Write some code and push your changes to your repo using the command line or your favourite Git GUI.
  3. Create a new pull request and fill in the template provided to tell us about your change.
  4. Be sure you're submitting your pull request to the development branch (and not master).
  5. Submissions should have a changelog entry noting what was added, changed or fixed.

Thanks for reading!

Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they'll reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.

Caught a mistake or want to improve the documentation? You are welcome to contribute! Look for the edit link on each page.