Our GitHub repository is wonderful in many ways. To keep it wonderful, committers should follow a few simple guidelines.
Code in the openmrs-core ''master'' branch should always build but does not always have to run smoothly.
The code in the ''other branches'' in openmrs-core does not have to compile or run. It is all up to the branch creator/maintainer(s).
The code in openmrs-module-* repos does not have to compile or run. It is all up to the module source creator/maintainer(s).
The code in openmrs-contrib-* repos does not have to compile or run. It is all up to the specific contributor(s).
/dev/4 and /dev/5 developers can push fixes to openmrs-core or merge pull requests. The associated ticket should be marked as "Committed Code" so as to be in the "Code Review (post commit)" state.
All others cannot push to openmrs-core, but are encouraged to open pull requests instead.
Any major feature additions or code overhauls should be submitted to a branch or fork. Forking and branching is quick and easy: don't be afraid of it.
All new features should be developed in a fork or branch. This allows the developer to adhere to the policy of committing early and often much more easily than if the feature were developed directly on openmrs-core.
All developers are expected to watch source code that is committed (e.g., via the "watch" feature shown on the openmrs-core repo) and give the one who is committing feedback. The committing developer must be open to suggestions and constructive criticism.
When a feature has been fully developed and tested, it can be merged back into openmrs-core by a /dev/4 or /dev/5. Merging "permission" should be acquired from the other full-access developers prior to the merge (see Git Branching and Merging Techniques).
To request that your module repository be migrated to the OpenMRS organization in GitHub, please ensure that it meets the above criteria, then:
Post to OpenMRS Talk > Repo Management and include:
/cc @username1, @username2, ..." to the end of your post.
Each repository should contain a README.md in the root folder. The
.md extension for a README refers to markdown syntax.
Your README should contain at least two sections: description and installation. For example:
This section outlines the different scenarios and sections in which commits occur. Find the one that best matches yours and follow that.
Commits to openmrs-core
where "Fixing feature XXX" is a descriptive sentence about the error/function being corrected and TRUNK-123 is the jira ticket id.
Adding functionality X
Where 123 is the ticket the patch came from.
Be sure to include the module's id and the username of the intended user