Volunteers are encouraged to work on issues currently assigned to "mifosdeveloperqueue" with the label "volunteer". If you are starting work on an issue, assign it to yourself, and let us know you're working on it on the IRC channel or the developer mailing list.

Development Process

Here's a summary of the basic steps to follow when submitting a patch or doing a commit:

1. Make sure your working copy is up to date and follows the Version Control Guide
2. Write the tests for your code (or identify the existing tests that exercise code you will be changing)
3. Write your code
4. Make sure the tests that exercise your code all pass
5. Update your working copy again to get any changes that may have been committed since you started your work (and resolve any conflicts or compilation issues)
6. Run a full Maven build ("mvn clean install" from the top-level directory of your working copy) and verify that the build succeeds (meaning there are no test errors/failures)
7. Ensure your code adheres to our standards and is properly vetted
8. Submit a contributor agreement
9. Create and submit your patch or commit your changes

Modifications done to the Mifos repository for bug fixing / feature enhancements have to be submitted as a patch. This patch should include all the changes done by the developer as part of the bug fixing / feature enhancements.

All code written for Mifos should be accompanied by associated unit tests. If you are writing a new feature, be sure to write unit tests that exercise the new functionality being implemented. If you are fixing a bug, write a unit test that fails because of the bug before you fix the bug. After you fix the bug, your unit test should pass. Include all the unit tests you write as part of your patch.

Prior to submitting a patch or checking in code, you are required confirm step 6 as above mentioned. It takes approximately 30 minutes to 1 hour to run entire build (depending on the hardware you are running on). Only then should you check-in (commit) your code or submit your patch. If you're checking in code to the repository, you can confirm that your check-in didn't break the build by looking at our continuous integration server.

How to generate a patch

• Commit locally, following the Commit Log Guide.
• Use git format-patch
• Make sure your patch applies cleanly.
• More tips from git's SubmittingPatches

How to submit a patch

1. Create an issue in the issue tracker if one does not already exist.
2. Update the issue:
   • Attach the patch file to the issue
   • Add the label, "Patch", once it has been attached. Assign the issue to mifosdeveloperqueue. This adds the patch to the patch queue. The "patch" label is removed if a patch is not ready for review or was rejected.
   • Watch the issue (click the envelope icon to the right of "Watchers")
   • Provide a link to relevant mailing list discussion(s) within the issue comments
   • When the patch has been accepted, the issue will be resolved and assigned back to you (the contributor).

How to apply a patch

Use git am. Give the author credit for their contribution. Using git am will correctly attribute authorship to the patch submitter.

If you manually apply the patch instead, there are several ways to attribute authorship to the contributor, such as

git commit --author="Jon Doe <jdoe@example.com>"

head/master maintainers

Break the build

If you break the build, do it in style!

How to accept a patch

• apply patch build, test, and push the code to sf.net
• resolve the issue "Fixed"
• reassign the issue to the patch submitter
• reply to the [PATCH] post on the mifos-developer mailing list

How to reject a patch

• remove the "patch" label from the issue with the attached patch
• assign the issue back to the patch submitter
• add a descriptive comment about why the patch was rejected, and what the submitter might do to rework the patch