Guidelines for GPSTk Submissions (Submission Etiquette)

------ PLEASE MAKE NOTE, from this point on, all guidelines will be based on submissions to the future GPSTk Git Developer repository, once the ARL Git Server is set-up.------

The first questions to address are: Does this belong in the GPSTk?" and "Is this a useful GPSTk application?". There are several factors that should be considered when answering these questions, which are:
  1. compatibility with the LGPL (see LicensingAndCopyrightFAQ),
  2. compatibility with the contents and direction of the library (see GPSTkMission),
  3. appropriate implementation language,
  4. ability to publicly release the work, and
  5. for GPSTk Library submissions, lack of dependencies on components other than the GPSTk Library and Standard C++.

The GPSTk Library is primarily a toolkit and the focus is usually on components, that is, individual classes that can be reused in other applications. However, the toolkit also contains the GPSTk Applications. Both new library classes and applications are welcome additions. In some cases, the applications are examples that can also serve as useful starting points for other applications. In other cases, (e.g. timeconvert and navdmp) the programs are of general use in-and-of themselves. Submitted applications should be accompanied by a readme file that documents any dependencies on material beyond the GPSTk or any platform assumptions.

Possible submissions can be divided into three categories:

  • Changes that introduce new functionality – Changes in this category establish new functionality without changing existing interfaces or behavior.
  • Corrections to existing functionality – Changes that correct the behavior of existing functionality. For example, correcting improper handling of a boundary condition or correcting a numerical error in a formulation.
  • Changes to existing functionality – This includes changes in the public interfaces of existing GPSTk modules or changes to the algorithms that will result in significantly altered results.

In general, expansions to functionality and corrections to functionality are encouraged while changes in existing functionality are to be avoided. In cases where changes to functionality appear necessary to meet the goals of a project, the developers are encouraged to first search for ways to cast the changes as expansions in functionality. For example, (1.) adding an additional calling signature to an existing class interface, or (2.) adding a new subclass that implements a different algorithm for an existing computations and thereby allowing the existing and the new methods to co-exist. In cases where changes in functionality appear highly desirable, such changes should only be undertaken after consultation with the GPSTk CoreTeam and development of a consensus among knowledgeable users that the change is truly warranted.

Another important consideration in considering candidate submissions is export control. All material submitted to the repository is available to anyone with an Internet connection anywhere in the world. The GPSTk project is hosted on SourceForge and an ARL Git Server (in the future), and these servers are located in the United States. Each person or organization submitting material to the GPSTk project is responsible for determining whether the material is subject to export control under the Export Administration Regulations (EAR) or any other U.S. government regulations. For more information see http://www.bis.doc.gov/policiesandregulations/index.htm.

Discussion

 
Topic revision: r3 - 05 Sep 2013, BryanParsons
 

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback