[GenABEL-dev] Improving the process of contributing to GenABEL

[L.C. Karssen]

Dear list,

In the past few months we have seen several packages being proposed on
this list, which is a great thing! However, we also observed that
finding people willing to do package reviews was difficult. Obviously,
we would like to improve this.

Yurii and I have discussed this recently and we came up with the
following ideas:

1) Require from every author of a package that is accepted into the
GenABEL suite to review at least two packages. [NOTE in case we want two
reviewers for each package we should require four packages to be reviewed]

2) In order to create a visible record of package review activities the
reviews for the accepted packages could be posted online and given a DOI
(e.g. via zenodo.org). This means that reviews can also add "Technical
review for the GenABEL project" to their CVs.

3) Instate a contributor/maintainer agreement similar to the one from
Bioconductor [1]. In this agreement we can not only incorporate point
1), but also the fact that we expect authors to maintain their package
and provide user support on the forum.

To start the discussion, what do you think about the following text:
-------------------------------------------------------
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 (http://forum.genabel.org)
- 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 [3] (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. [2])
- 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 GenABEL R-forge SVN

-------------------------------------------------------


Looking forward to your opinions,

Lennart & Yurii.


[1] http://bioconductor.org/developers/package-guidelines/#responsibilities
[2] http://www.genabel.org/packages/PredictABEL
[3] https://svn.r-project.org/R/trunk/share/licenses/license.db

-- 
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
Utrecht
The Netherlands

lennart at karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.r-forge.r-project.org/pipermail/genabel-devel/attachments/20151006/9dff5f1e/attachment.sig>