GNU Health/Contributing

Contributors Wanted!

GNU Health is a FLOSS project, you are very welcome to contribute to it. There are several ways to do so, most of which not requiring you to know how to code!

Translating the Software

Providing GNU Health in a user's native language is a big part of the success. You can help by improving existing translations, or creating a new translation in your own language. Translating GNU Health is easy, it does not require technical knowledge, and is all done via a web interface. Have a look at the Localization page for more details on the process.

Writing and Translating the Documentation

The GNU Health documentation on Wikibooks (which you are reading right now) is not complete, and it needs adjustments or additions with every GNU Health upgrade.

And if you don't want to write documentation, you can still contribute by translating it into your language to make it easier for health professionals to work with GNU Health.

Reporting Bugs

Unfortunately almost any software contains bugs. While we are actively working on fixing them so you don't have to struggle, please do report any bug or anomaly that you encounter.

Reporting a bug does not take much time. It is done via Savannah.

Tip: For faster resolution, please include a description of the steps you performed to get to the bug, and if possible include screenshots of the issue. But be careful: Don't include patient information in the screenshots or your description!

Coding

GNU Health is mostly a set of Tryton modules, the programming language used is Python. The code is hosted on Savannah and versioned under Mercurial.

Obtaining Your Copy of the Code

You can get your copy of the latest code by doing an anonymous checkout:

hg clone http://hg.savannah.gnu.org/hgweb/health/

You can also browse the code online.

Coding style

The coding style should follow the Tryton guidelines or else Python best practices.

Customizing and Creating Your Own Modules

Chances are that if you are installing GNU Health for your center, you will be customizing it to meet your specific needs. Reports, access control rules and views are just some of the objects that are normally customized. The main concept is to not edit the standard code or modules, since it will be overwritten in the next update and most probably will end up in a broken system.

The recommended steps to customize GNU Health to your center are:

1. Create your module: It's recommended that you use the following naming convention for your local modules: z_health_<modulename>. For example, if your project is called catalina, your local module name would be z_health_catalina. This way makes is easy to detect and differentiate your modules from the base code. You can also easily make backup of them following the pattern.
2. Inherit the objects.
3. Modify or create new models.

If you create a new custom field, you should also use the z_<fieldname> naming convention. This avoids collision with future field names of the official releases. We will not use any module, class, or model name starting with z_.

The "local" modules directory

There is a directory called local under ~/gnuhealth/tryton/server/modules. Please put your local modules that contain the customizations for your project under this directory. When using this approach, it makes sure that the update procedure does not overwrite your packages.

Also, sometimes you might want to include another existing package from Tryton or the community. This local modules directory is the place to place them.

Please note that can only support those packages that are included on each GNU Health HMIS distribution.

Submitting Patches

Regular contributors have write access to the code repository. However, if you're just starting out, we want to make sure that your changes get reviewed. The way to do this is to open a bug describing the issue you've fixed or the feature you've added, and to attach a patch to that bug report. One of the developers will review your patch and commit it to the main development branch if approved.