This is an overview of the process of contributing to the DHIS2 source code.
This section covers the DHIS2 core, meaning the DHIS2 server backend. You can find the GitHub repository here.
- Discuss: For software features it is recommended to reach out at the DHIS2 developer community forum (found here) and raise a proposal with the development team. Discussing and clarifying questions around the requirements and design is helpful as adjustments are cheaper to make at the beginning of the development process.
- Pull request: The PR title and description should follow the guidelines. The PR should have a description which makes it clear what is being changed and why the change is useful. In particular API changes should be described clearly. Please raise all PRs against the
masterbranch and raise new PRs for back-porting to stable versions as needed. DHIS2 Jira is found here.
- Jira issue: Every PR requires a Jira issue which describes the bug or feature and defines which versions are affected. This is also important to ensure that changes are tested properly- The corresponding Jira issue should be referenced in the PR title in brackets, e.g. like this:
- Code style: The Java code style and formatting for DHIS2 core should follow the guidelines. DHIS2 core uses the Speedy Spotless Maven plugin for automatic code formatting.
- Test: The PR should contain at least one unit test, ideally several, which verify and assert new features or changes to existing behavior.
- Documentation: Relevant documentation should be made if the PR adds new features or changes existing behavior, either to the user interface or API. The documentation GitHub repository can be found here.
- Review: The DHIS2 core developer team regularly monitors available PRs and will do a review of the PR. The PR should be adjusted based on feedback and comments. The PR will be merged to master once approved by two core team members.
- Celebrate: Once merged, the commit will be part of the next applicable DHIS2 release. The development team needs enough time to review and incorporate changes into the development and test cycles. If you want to see your contribution in a specific release, a good rule of thumb is that PRs must be created and raised to the core team at least:
- 2 months in advance for a major release, or
- 1 month in advance for a patch update.