How to contribute to GRASS GIS

Contributions to GRASS are most welcome. There are a number of ways that you can contribute to help make GRASS a better GIS system. Perhaps the most important way to contribute is to write high-quality code for solving old and new problems, and to make your code freely available for others to use. But not everybody is able to program. Still you can help!

Power users

Documentation: If you see manual pages or other documents which are outdated, grammatically incorrect, too short, lacking examples, etc. please don't hesitate to send revised text segments (preferably in HTML) to one of the developers or the related mailing list. Please also contribute to the wiki, improving documentation, providing examples... The best method for submitting changes is via a patch to the trac system (see below).

GRASS Usage: Subscribe to the ​mailing list and answer questions where you have gained some knowledge (and everybody knows something!).

Code developers

For inspiration, we have a wish-list of projects and feature requests. Just pick a task from the list. It may be a good idea to send a small posting to the ​GRASS developers mailing list to announce your activities (maybe someone will join you!). Please read how to write source code. We appreciate if you can fix ​bugs etc.

The Trac ticket system is the best way to submit your code contributions if you don't have write access to SVN, and (even for those with write access) the preferred way to submit more radical changes for general review. See for example trac ticket #33.

• Submit your code and documentation patches ​here.
• ​How to create a patch - they should be generated versus the latest development SVN (trunk).

Code quality: Check your code according to GRASS "BestPractise" guide list.

What else: see ​development collection (to be moved here)

Procedure for gaining GRASS-SVN write access

To enhance code quality and security, a procedure has been established to control and grant GRASS-SVN write access. In general, write access must be requested and is not automatically assigned. Any code submission must be compliant with the GRASS submission rules.

Write access to the Main GRASS-SVN repository

The typical process for new developers to gain full write access to the Main GRASS SVN repository is that for some mentorship period they send patches to the grass-dev mailing list (or the trac system) for existing old timer developers to review and commit. Full SVN access generally happens when the mentor has seen enough patches that they trust the person's code (committing it unchanged) and eventually get bored reviewing & rubber stamping all their patches. It is assumed during this period that a track record of trust will be established via participation on the grass-dev mailing list. At some point the mentor nominates the new developer on the PSC mailing list for full write access, and a vote happens.

• In general, the ​GRASS Project Steering Committee is responsible for granting SVN write access to contributors (as defined in RFC1).
  • The new developer must read and abide by the document Legal aspects of code contributions (RFC2).
  • An email must be sent to the ​GRASS-PSC mailing list by the new developer stating that RFC2 was read and accepted. This requires ​subscription to the PSC mailing list. After a period of evaluation, SVN write access may be granted and is set up in the OSGeo authentication system (see below).

Write access to the GRASS-Addons-SVN repository

Write access to the ​Addons SVN repository is much less rigorous than to the core source code repository. It is in effect an incubation area, both for new code and new developers. Write access does not require the full vote of the GRASS-PSC, just the support of one mentor and adherence to our RFC2 document, which guarantees that the code is license-compatible with the rest of GRASS. As opposed to write access to the Main SVN repository, write access to the Addons repository is typically initiated by the new contributor. Overall:

• We invite and encourage users who write GRASS add-on code to host it in our grass-addons SVN. We do so because:
  • Community building: It gets people involved and educated - contributing to the main GRASS code uses the exact same website, software, and commands. Thus the trip from contributor to full developer requires a minimum of training.
  • Archival: After some years it is common that people move on, then private websites fade away and the code is lost. The code will be widely backed up and if the main source code ever moves, all the addons will move with it in parallel.
  • Guaranteed license: From the start all code there is licensed under the GPL (or compatible), so all can use the content there without worry, and mature modules may be promoted into the main GRASS code as needed.
  • Caretaking: In years to come others may easily contribute bug fixes and upgrades if a flaw is found or the GRASS API changes.
  • Infrastructure: Ability to take advantage of the svn history and trac system integration, including bug tracker. (these are really quite good things)
• ​GRASS developers with write access can grant SVN write access to contributors (you may contact an active developer, see grass-dev mailing list archive). The selected developer is a sort of "sponsor/mentor" for the requester. Procedure:
  • The requester needs to obtain an "osgeo_id" at ​http://www.osgeo.org/osgeo_userid - if s/he already have an "osgeo_id" but forgot it, it can be searched at ​http://www.osgeo.org/cgi-bin/ldap_web_search.py
  • The requester has to read and abide by the document Legal aspects of code contributions (RFC2).
  • The request should be sent to a GRASS developer or the GRASS-PSC chair, stating that RFC2 was read and accepted (locate a mentor). The request then has to be sent to the GRASS-PSC ​mailing list, stating that RFC2 was read and accepted. As only subscribers are allowed to post to OSGeo mailing lists, this requires ​subscription to the PSC mailing list for that time. For fast service you should provide your OSGeo ID in this email. (see below)
  • After a period of evaluation, SVN write access may be granted and is set up in the OSGeo authentication system (see below).
  • New commands stored in the GRASS-Addons-SVN repository should be also added as link to the ​Wiki list of tools and placed in the appropriate directory hierarchy.

Setting up the new SVN write access after acceptance

Once SVN access is granted, the requester's "osgeo_id" will be enabled. The GRASS-PSC chair (currently Markus Neteler) and other developers will add this "osgeo_id" to the list of enabled accounts in the OSGeo LDAP authentication system (​here for GRASS-SVN and ​here for GRASS-Addons-SVN; requires authentication).

Important: Contributions have to follow the Submitting code rules.

Then what?

Get the source code and Happy hacking :) The requester should subscribe to the ​grass-commit mailing list which distributes GRASS-SVN commit differences for real-time code review.

Coding standards and code style

Check your code against the rules defined in the document Submitting. This ensures a smooth integration into the standard GRASS code base and avoids portability problems.