This section will deal with various ways contributing can happen.

There are several communication channels that can be used to help new users become familiar with Zabbix by answering their questions. They are:

• Zabbix forum;
• IRC channel on the freenode network - #zabbix.

General guidelines for getting help apply.

Help on documentation in this wiki will be appreciated. You can clean up or write new howtos or participate in community documentation.

It is possible to participate in translation of Zabbix interface and documentation. It is actually very much appreciated - native speakers are in the best position to create quality translations.

There are two possible things to translate at this point:

• Frontend;
• Manual

If you want to translate frontend, use the locales section and submit resulting file to Zabbix issue tracker.

If you want to translate the manual, contact Zabbix developers for write access at support@zabbix.com, providing your forum username and language you want to translate manual to.

If you want to help with translation, it's best to coordinate the efforts. The following table lists language maintainers. If there is an existing maintainer, feel free to contact them for advice or to report problems with that particular translation. If there's no maintainer for your language, feel free to add it - and yourself as the maintainer, if you would like to participate.

There often are suggestions from the community on things that could improve translation process. If you have a suggestion that would ease translationg Zabbix, feel free to add it below.

• Introducing string freeze

Many software projects have a specific phase before a release, called string freeze. During this period, it is guaranteed that no user-visible string changes, thus giving translators time and confidence that their efforts would not be in vain. Currently, Zabbix does not have official string freeze policy.

• Using gettext

It might be desirable to use gettext for translatable string management. It has many tools available, including pootle (provides very easy to access translation frontend, as well as statistics), Poedit (multiplatform translation editor) and others.

• Strings not available for translation

Currently many strings in frontend and all in server/agent are not available for translation. That results in suboptimal user experience. Using gettext might help with that somewhat.

There's an experimental service for translators. You can subscribe to a mailing list - whenever English locale will change, an email will be sent with svn diff, so that you can easily see what exactly has changed and whether it warrants your attention.

Email is sent for each branch separately, so a change in both trunk and some branch will result in two emails.

It is planned to assemble QA team that would ensure Zabbix receives quality testing throughout release cycle and after that.

Current external Zabbix testing is spotty at best, and there are few people who follow svn branch or trunk development.

The QA team would be involved in tasks like evaluating reported bugs, organising bugsquash days, setting up test environments and others.

External patches are rarely included in Zabbix. There are many different reasons for this. Hopefully, by changing this both Zabbix developers and community stand to gain. To improve the situation, understanding and agreement of simple rules would be required.

Patches should be easy to merge, and evaluating a patch should not take developer more time than writing the feature from scratch. Also, contributors should waste time on redundant tasks, so coordination is important. Few general guidelines:

• Before starting development, discuss it with Zabbix developers. It might be conflicting with existing direction, it might be already being worked on etc.
• Do not dump large, hackish code changes - they won't be accepted. Make sure changes are split in small, manageable and preferably independent blocks. Keep your code clean (see coding guidelines below).
• Keep in mind that your changes have to work well for all Zabbix users - it is not acceptable to make a change that makes either small or large installations unusable.
• Make sure frontend modifications do not limit browser compatibility - test that yourself and ask other users to help with testing. Currently all frontend functionality is expected to work at least in latest versions of Mozilla Firefox, Microsoft Internet Explorer, Opera and Konqueror.
• Make sure server and frontend modificationsdo not limit server component compatibility (like PHP or DB server compatibility).
• Do not submit patches for server/frontend that rely on proprietary software to function.
• Always work with current trunk. While some smaller change might be appropriate for backporting to the stable branch, submitting patches for trunk will have a bigger chance of getting them accepted, and you might also discover that something is already implemented in trunk.

To be completed

• Use tabs only for indentation with width 8;
• Remove trailing whitespace;
• Use LF line endings;
• All changes must be documented;
• A change may not introduce new hardcoded (untranslatable) strings.

• Use svn mv always to preserve modification history, never delete/add files when moving them;
• When fixing a problem in multiple branches, use svn merge whenever possible;
• Prefix commits with ” - [issue] ”, where issue is Zabbix tracker issue reference like ZBX-1;
• Describe all changed things in the commit message;
• If a bug is fixed in branch, but not in trunk, do not forget to add entry for the trunk changelog.

No matter whether you are interested in coding or testing, and also helping others might need a specific version installed to have a similar environment. For that you will need to familiarise yourself with getting Zabbix source code and compiling it.

With all the information about proper patches absorbed, one would still need to get the source code. See detailed instructions about getting source.

With the source retrieved, proceed on to compiling and installing from source.