For developers

The GenABEL project developer/contributor infrastructure is mostly maintained at R-Forge, although part can now also be found on the Github GenABEL Project page. The infrastructure includes web-pages containing a set of HOWTOs for developers, bug and feature request trackers, version controlled code (Subversion/Git), the genabel-development and genabel-announce mailing lists, etc.

Useful links:

The GenABEL Package Author and Maintainer Responsibilities

Acceptance of packages into the GenABEL suit brings with it ongoing responsibility for package maintenance. These responsibilities include:

  • Subscription to the GenABEL-devel mailing list.
  • Registration on the forum
  • Response to bug reports and questions from users regarding your package, as posted on the GenABEL forum or directly to developers.
  • Package maintenance through software release cycles, including prompt updates to software and documentation necessitated by e.g. underlying changes in R, compiler, libraries etc.
  • If you do not take the opportunity to maintain a web page for your package on www.genabel.org (see below), you should provide a URL of the released package and most up-to-date source code (e.g. link to the CRAN page would be enough for this purpose); this URL will be put on the genabel.org site.
  • The licence that covers you package should be one of the standard open source licences accepted by CRAN (even if you package is not an R package).

You also will be given the opportunity (and we encourage everyone to use it) to:

  • Maintain the package page on the genabel.org site (see e.g. the PredicABEL page)
  • Use GenABEL R-forge for bug tracking (you will need to register on R-forge in order to use this functionality)
  • Keep version control of the source code using the GenABEL SVN repository on R-forge or as part of the GenABEL Project Github page

Rules of the game

The documents provided here are meant to help. We are scared to think of a situation when 'guidelines' and 'rules' prevent people from contributing to the project, and a willing contributor is discouraged by just looking at the pile of 'rules'.

You do not need to read this, unless you want to; this is 'optional reading' -- these having time to read this, please do; not reading is totally fine. We think that if one sticks to 'open source spirit' throughout, one can not make a mistake.