Contribution Policy

This section describes the process for contributing to the FIPA-OS Community Development process. This process is currently offered for review by the FIPA-OS community, so discussions are encouraged on the FIPA-OS Developers mailing list.

Definition of terms

• FIPA-OS Community - All individuals with an interest in evolving FIPA-OS for the greater good - generally all users of FIPA-OS.
  
  
• Developers - Individuals who are active on the FIPA-OS Developers List.
  
  
• Senior Developers - Developers who have made contributions to the FIPA-OS codebase indirectly via submissions to the FIPA-OS Management Team or a Principle Developer via the FIPA-OS Contributions List.

  It is recommended that Senior Developers join the FIPA-OS Contributions List in order that they can easily submit new contributions
  
  

• Principle Developers - Senior Developers who have earned the privilege of joining the FIPA-OS SourceForge project (i.e. having CVS write access) through:
  • Production of consistently good contributions, or
  • By developing new functionality within the FIPA-OS codebase
    
    

  This maps directly onto the SourceForge developers which are members of the FIPA-OS project at SourceForge.

  All Principle Developers should join the FIPA-OS Contributions List in order to receive contributions to areas of CVS which they are responsible for, since they are required to undertake integration of code into these areas. It is not necessarily the case that a Principle Developer is responsible for a part of CVS at any given time.
  
  

• FIPA-OS Management Team - The group of people responsible for co-ordination of FIPA-OS development activities and release management. This maps directly onto the SourceForge developers with Admin responsibilities for the project.
  
  
• FIPA-OS Developers List - A general purpose mailing list for discussing all things related to FIPA-OS. A good place for new community members to ask questions, and Developers to discuss design/implementation details.
  
  
• FIPA-OS Contributions List - A mailing list to which all developers can post contributions. Subscribers should expect to receive large emails from this list which might contain contributions. For developers who wish to be able to submit contributions via email, but do not want to receive contributions by email it is recommended that their list subscription options are changed to select the no mail option.
  

Recommended Development Tools

Here are some of the tools we recommend for use when developing FIPA-OS or other Open Source projects using Windows 9x/Me/NT/2000:

• Netbeans IDE - excellent free IDE integrates with JUnit and ANT, requires lots of memory though
• Together - excellent UML modelling package, free version available for non-commercial use
• WinCVS - front-end for the defacto Open Source version management software
• ANT - Cross-platform Java build utility (and much, much more!)
• JUnit - Unit test framework which integrates with ANT
  
• WinMerge - Graphical version of diff with merging capability, which can recursively diff files within directories
• CygWin - Unix tools (and API) for Windows - includes OpenSSH
  

Most of these tools are also available for other platforms - please send details of other useful development tools to the FIPA-OS Management Team

Details of particluar tool-specific projects files in the repository can be found within the src/README-non-source-files.txt file in the appropriate CVS module.

Submission options

There are two mechanisms through which contributions can be made:

1. Submission of code to the FIPA-OS Management Team / Senior Developers via the FIPA-OS Contributions List. This is the default mechanism new developers have to use.

   Submissions to the FIPA-OS Contributions List should either be included as a ZIP'ed or GZIP'ed attachment, or a URL to a location where the submission can be located. In the later case it would be acceptable to cross-post details of the submission to FIPA-OS Developers List.
   
   

2. Direct CVS access. Principle Developers are granted the ability to directly modify the FIPA-OS CVS repository. This ability is subject to meeting the requirements outlined below for making contributions, and can be withdrawn if it is abused.

   Changes made by Principle Developers must be approved by the persons responsible for the part of the CVS repository into which the contributions are being integrated. Details of CVS responsibilities are contained with CVS itself.

   New modules must not be created without the permission of the FIPA-OS Management Team.

It is recommended that all developers join the FIPA-OS CVS Updates mailing list to be kept up-to-date with the latest changes to the FIPA-OS codebase.

Types of contribution

There are two types of contribution which are generally submitted:

1. Incremental bug fixes / enhancements, supplied as modified source code. This is the preferred contribution type, since testing & integration is a minimal task, and the original code is most likely still up-to-date.
   
   
2. Substantial collection of modified / enhanced classes supplied as source code. Testing & integration is non-trivial, especially if the version of FIPA-OS on which the contribution is based is not the most recent, hence confusing the integration process beyond that for Incremental contributions.

How integration is managed

The following table illustrates how submissions are integrated into the main code stream, depending on the type of contribution and the type of developer.

	Incremental contribution	Substantial contribution
Submission to FIPA-OS Management Team / Principle Developer	Dependent upon the nature of the contribution, its quality and relevance to the goals of FIPA-OS in general.
	The contribution will be added to the FIPA-OS CVS repository by a member of the FIPA-OS Management Team or a delegated Principle Developer.	The contribution will be: Posted up on the contributions page of the FIPA-OS website for evaluation and testing by the FIPA-OS community. Added to the FIPA-OS CVS repository by a member of the FIPA-OS Management Team or a delegated Principle Developer once the code has been brought in-line with the latest FIPA-OS codebase and tested. This may be a lengthy process, and is subject to prioritisation. To improve the speed of this process, contributions of this type should attempt to be consistent with the latest version of FIPA-OS. Support by the authors in the integration task will help ensure that the contribution is included in the code stream in a timely manner.
Submission by Principle Developer	Proposed changes/additions to the FIPA-OS codebase should be submitted to the FIPA-OS Developers list so that they can be discussed along with any relevant designs.
	The changes should only be made once explicit permission has been granted by a member of the FIPA-OS Management Team, or a Principle Developer with responsibility for the given source code.	Dependent on the scope of the work, sub-tree(s) of the FIPA-OS codebase may have responsibility assigned to one or more Principle Developers who plan to integrate the contribution. Proposed modifications to code in this sub-tree (either related or unrelated to the original proposed contribution) will need to gain permission from these Principle Developers.

Integration prioritisation

In the likely event that contribution integration must be prioritised, this will be based upon the opinion of the FIPA-OS Community which will be polled using the Sourceforge Survey mechanism or the FIPA-OS Developers mailing list.

The FIPA-OS Management Team reserve the right to reprioritise work in the best interests of FIPA-OS.

Contribution requirements

A number of requirements are made for all contributions:

• Code quality and readability - see coding guidelines.
  
  
• JUnit tests - all new functionality should have a new JUnit test created to enable repeatable testing of that functionality. Regression tests should also be written for any bug-fixes to prevent bugs re-entering the codebase at a later date.
  
  
• Documentation - this is at minimal JavaDocs for classes/methods created. Ideally this will also involve creation/updating of UML models using Together.

NOTE: Not all code within the codebase currently meets these requirements, although the current task list details the required changes to align the code base with these guidelines. Contributions to this effort would be appreciated.

Determining CVS tree responsibility

A simple mechanism for determining which developers are responsible for which sub-tree(s) of the FIPA-OS codebase is in place. At the root of the sub-tree of responsibility, a file README-responsibility.txt should be placed containing the SourceForge user-names of the developers responsible for the contents of that directory and sub-directories.

If any sub-directory contains another README-responsibility.txt file, this effectively overrides the responsibility of the developers defined for its parent directory with respect to itself and its sub-directories.

Responsibility for a particular sub-tree includes the requirement of managing integration of third-party code for that sub-tree.

CVS etiquette & daily builds

As with many other Open Source projects, the FIPA-OS CVS tree will contain work-in-progress code at any one point in time. The advantages of this approach are:

• Interested FIPA-OS developers can help to produce/test/use/extend new functionality as it is being added to the codebase
  
  
• The CVS repository also acts as a backup for development code - in the event of a fatal fault developing on a Principle Developer's computer, the code they were working on is safe in CVS (The FIPA-OS SF CVS repository is regularly backed up by the FIPA-OS Management Team)

This approach has the disadvantage that there is no gaurantee that the latest versions of source files in the codebase will even compile - however to counteract this situation, CVS tags are used to indicate which versions of files are actually working and ready to use versus those which are still in development.

The README-tags.txt file contained in the root of the CVS module details the tags used in CVS.

In order to provide early-access to new functionality for FIPA-OS Developers, an automated build process will be setup to produce regular builds of the latest checked in working code.

Source code licenses / copyright

All source code should by default use the standard FIPA-OS copyright statement which references the emorphia Public License (substituting appropriate ownership information for references to emorphia Limited of course, in the case that the initial developer of the file isn't emorphia). Code which is to be incorporated under any other license must first seek approval of the FIPA-OS Management Team.

Contributors should add their details to the contributors section of the copyright notice to indicate their partial copyright ownership of the file. (A CVS diff should reveal the precise changes made by particular developers).

All licenses referenced by the source code should be located in the docs/licenses of the appropriate CVS module (see FIPA-OS/docs/licenses).