HPCRAN Rules

General

1. HPCRAN is for stable releases of "publication quality" packages.
2. You must have a GitHub account that has been manually approved by the HPCRAN administrator to upload packages to HPCRAN. If you are interested in publishing packages on hpcran, please contact the administrator.
3. You must login with your GitHub account and authenticate the OAuth app.
• The app reads your username and all emails, including private ones.
• None of your email information is stored long term. It is only used for authentication.
• None of your information is shared with any other party.
4. At least one verified email address on your GitHub account must match the maintainer email in package submission.
5. Packages should generally be HPC-related in some way. Non-HPC packages might be better suited for distribution on the CRAN or Bioconductor.

Packages

1. You do not have to ask permission to upload a package once your account is approved. Simply upload it.
2. Uploads should be sources packages that have been built with R CMD build, and as such should be valid .tar.gz source files.
3. Packages should be no more than 10MB in size. I hope to increase this limit eventually, but right now storage is at a premium.
4. You can set tags for your package with the HPCRAN field in your package DESCRIPTION.
• Multiple tags (comma separated) can be used for a single package.
• Tags have a 10 character limit. Tags longer than 10 characters will be ignored.
• Please try to use tags accurately. For example, don't use gpu if your code doesn't use GPUs.
• Don't use unprofessional language in the tags.
5. Packages are not automatically checked with R CMD check, as the usual CRAN checks may be too stringent for some HPC packages. That said, please run R CMD check on your package before submitting, and try to satisfy as many CRAN check requirements as you can, as most of them are good.
6. Consider including a README or README.md file that includes installation instructions for your package. This file will be rendered and linked on your package page.

Updates

1. The updated package version must be greater than the previously published version.
2. Your verified GitHub email address must match the maintainer email address in the previously published package.
3. The maintainer email address in the package update must match the maintainer email address in the previously published version of the package.
4. If you need to change your maintainer email address on your package(s), please contact the administrator.

Legal

1. Packages should be licensed under an OSI approved open source license.
2. Packages should not violate anyone's intellectual property rights.
3. Code and documentation should respect copyrights and trademarks.
• This means, among other things, adding copyright and trademark symbols, as appropriate.
• For example, if you wish to refer to a certain GPU manufacturer's programming API, the correct way would be NVIDIA© CUDA™.
• I know that this is dumb, but I don't want either of us to be sued.
4. Packages should not do anything malicious or anti-social.
• Viruses, forkbombs, trojans, and the like are all completely unacceptable.
• Packages should not collect any data transmitted to a third party without consent from the user.
• Calling something that kills the R process (e.g. assert(), exit(), etc) are fine so long as it is clearly documented.
• Modifying the global environment is discouraged, but acceptable.

Enforcement