This document is intended to serve as a pre-submit checklist for patch contributors and a pre-commit checklist for committers. Contributions following these guidelines have a much better chance of being accepted into Mifos.
If you know a patch is not excellent, reject it (see next section on how to do this). If you're not sure, ask for help on IRC and/or the mifos-developer or mifos-users mailing lists.
If the patch doesn't apply cleanly but is very small, manually apply it if you can do so quickly/easily.
Initially, code should be scanned for more obvious mistakes. All unit, integration and acceptance tests pass without errors or failures. All code adheres to our standards
The following ensure readability and ease of merging.
Unit tests are...
Test
, like ViewSettingsTest
All files use licensing information as specified at Mifos Licensing.
Proper grammar, spelling, and punctuation is used.
Omit your own name. Ex: "this file created/mainted by me, Adam Monsen". Once the code is checked in, we all own it, any one of us may maintain it! Credit for contributors should appear in the AUTHORS file only.
This type of anonymity will:
When delving deeper into examining a patch, consider that more complex Mifos idioms are followed and look for deeper logic issues.
All method names and logic is self-explanatory or has Javadoc and/or comments.
Efficient, sensible, and prolific code reuse is found.
Generics are used whenever possible to parameterize containers.
Pages and forms are accessible/usable only by appropriate users/roles.
Date-specific and timezone-specific code is not introduced.
Configuration files should be found using ConfigurationLocator. Code touched which uses another method to locate configuration files should be refactored to use ConfigurationLocator.