Test major Koha Wiki changes or bug fixes here without fear of breaking the production wiki.
For the current Koha Wiki, visit https://wiki.koha-community.org .Developer handbook
If you are willing to help or learn how to hack Koha, you are at the right place!
The idea here is to collect the pages that are the most relevant to people who want to help develop Koha.
Contact us
To contact the community, join us on the Koha IRC channel or the Mailing lists.
You are new in the Koha community
There are different way to help the Koha community when you are a developer.
If you are not already familiar with the Koha community you should take a look at our Development_workflow to understand the different steps of a patch. The intent behind the workflow is to ensure that the best code is rolled in without breaking existing features.
It's always a good idea to take a look at the Dashboard as a central place to see the current state of development at a glance.
Testing bugs
Then, to understand this workflow you should start by signing off on some patches to get used to it.
Write patches
A quick read to our Coding Guidelines is mandatory to know how we organise our code. No need to read them fully, but you should know how to find this kind of information.
If you are just getting started as a devoloper, take a look at the getting started as a Koha developer to learn what technologies Koha is built on and some resources to learn them.
It's a good idea to take a look at splitter to identify if others are already working in a similar area of the codebase to you and perhaps reach out to collaborate.
When you are ready to commit your work, take a look at the our commit messages rules
All these steps are resumed on the Submit a patch page.
TL;DR;
You just want to code? Ok! We have a step-by-step tutorial to guide you thought these different steps, take a look at the Koha How-to project!
Find bugs to fix
If you're looking for some inspiration of code contributions you could work on, read on!
Low hanging fruit
- Trivial or string change patches needing signoff
- Translations
- Answering questions on the mailing list
- Tidy up the wiki
- Add a cookie, fudge or ice cream recipe
Harder still
- Merging our SIP2 changes back into the upstream OpenNCIP project
- Minor bugs needing patches
- Small patches needing signoff
Even harder
- Normal severity bugs
- Medium patches needing signoff
- Hunt for unused dependencies and remove them
This is just getting silly
- Work on database independence
- Large Patches needing signoff
- Major severity bugs
- Update POD, add missing POD
ZOMG
You are already a Koha developer
If you are already a Koha hacker and you would like to submit big works you might know that time is limited for everybody.
Wanting to have big features integrated upstream may lead to frustration, and for having them in you will need to prepare the ground first.
To start it is important for you to show the community that you have understood our workflow and that you help others before expecting help from others :) Contributing to an open source is:
- receiving help from the community - we will guide you, answer your questions, improve your skills
- helping the community - when you are read you will be able to test patch and contribute to small bug fixes, then later to bigger patches (enhancements, new features)
- receiving help again from the community - to see your patches integrated the community will test and review your patches. When the patches will be pushed, this code will have to be maintained
To make sure the submission will not take too long, there are good practices to follow:
- show us you understood our workflow and coding guidelines by following them
- always ask if you have questions, especially before writing a new big feature. Maybe someone has already started to write it. It will also avoid design issues.
- do not be too long to answer questions or rebase your patches - the reactivity is the key of a good integration. If too much time is spent, rebasing will be harder.
If you are using an old version of Koha with custom developments (fork) and are going to get back to the community version the work you may have to produce can be heavy. You should contact us to explain us the developments you have and want to submit. We will help you to join us :) It is in the interest of both you and us to work together.
- Getting involved | Development workflow | Bug Reporting Guidelines | RFCs | Plugins | Plugin hooks
- Version Control Using Git | git bz | Commit messages | Sign off on patches | QA Test Tools | How to QA | Debugging in VIM
- Coding Guidelines | Koha Objects | Rest Api HowTo | Coding Guidelines - API | Unit Tests | Continuous Integration | Interface patterns | Database updates | Adding a syspref | Bootstrap and LESS
- Debian Packages | Building Debian Packages | Easy Package Building | Commands
- External: Dashboard | Bugzilla | Schema | perldoc | Jenkins