How You Can Join

The Ignite Realtime project is supported by volunteers and Jive Software.  We are constantly seeking out new developers to help contribute to the Ignite Realtime projects.  Ignite Realtime wants to set a high standard of quality for its developers, and at the same time provide nearly universal access to anyone wishing to contribute. This document describes the guidelines and requirements for contributing source code to the project.

Ownership

All source contributed by members must be explicitly given to the Ignite Realtime project property holders, Jive Software. This is done to maintain a consistent license, and allow the project to change licenses in the future if such a need arises.  A form granting ownership can be found at [...] and must be competed and submitted to Jive Software before any patches will be accepted.

One-time and infrequent contributors

If you only wish to contribute a simple patch, for a bugfix or feature enhancement, and do not wish to have an account created for you in the version control system, you can simply attach the patch file to the forum thread.  A member of the Ignite Realtime community with appropriate access will attach your patch to an issue ticket and after checking it will commit the patch on your behalf.  By submitting patches in this way, you explicitly grant Jive Software ownership of the modifications, and no contributor agreement is necessary.

Becoming a contributing community member

SVN accounts can be requested by community members wishing to contribute to various Ignite Realtime projects, however access requires completing the Mentorship Program first. The Mentorship Program is described at Mentorship Program.

Source Code Organization

Ignite Realtime uses the Subversion source code revision control system, or svn for short.  Links to svn tutorials can be found at the end of this document. All the Ignite Realtime projects are found in the same svn repository to make importing between the projects easy. At the top level you will find each project has its own directory.  Beneath each project directory are the standard "branches", "tags", and "trunk" directories.  The "trunk" directory is for all active development of that particular project, and all new commits should be applied here, unless you have been told otherwise. The "branches" directory is for specific projects that may require interference from the typical development process, and is sometimes used as a staging location for releases.  The "tags" directory is used for official releases only.

Each project has its own organization, and if you plan on adding new files, its best to first discuss these changes with the project Lead Developer first to maintain consistency.

Guidelines

• All svn commits must include a description of the change in the commit log. Often it is sufficient to simply mention the issue number related to the commit and a short description of the change. More complicated changes should explain the change.
• As a general rule, all commits should be applied against an issue number. If you are fixing something not yet reported, it is best practice to get an issue assigned before making changes. Changes that do not pertain to any specific issue number should be discussed with the project Lead Developer first.
• Individual commits should be limited to a single issue, when possible. When multiple issues are inter-related, this may not be possible, but if issues are completely unrelated, please make the commits for the issues separate.
• Coding style should match as close as possible to the existing project.