1 Bioconductor Package Submissions

1.1 Introduction

To submit a package to Bioconductor the package should:

• Address areas of high-throughput genomic analysis, e.g., sequencing, expression and other microarrays, flow cytometry, mass spectrometry, image analysis; see biocViews.
• Interoperate with other Bioconductor packages by re-using common data structures (see Common Bioconductor Methods and Classes) and existing infrastructure (e.g., rtracklayer::import() for input of common genomic files).
• Adopt software best practices that enable reproducible research and use, such as full documentation and vignettes (including fully evaluated code) as well as commitment to long-term user support through the Bioconductor support site.
• Not exist on CRAN. A package can only be submitted to one or the other.
• Comply with Package Guidelines.
• Your package cannot depend on any package (or version of a package) that is not (yet) available on CRAN or Bioconductor. The package should work with whatever current version of the package is publicly available.

1.2 Types of Packages

Bioconductor packages are broadly defined by four main package types: Software, Experiment Data, Annotation and Workflow.

• Software Packages. Most packages contributed by users are software packages. Software packages provide implementation of algorithms (e.g. statistical analysis), access to resources (e.g. biomaRt, or NCBI) or visualizations (e.g. volcano plots, pathways plots). Instructions for creating Software packages can be found here: Package guidelines.

• Annotation packages are database-like packages that provide information linking identifiers (e.g., Entrez gene names or Affymetrix probe ids) to other information (e.g., chromosomal location, Gene Ontology category). It is also encouraged to utilize AnnotationHub for storage and access to large raw data files and their conversion to standard R formats. Instructions for adding data to AnnotationHub and designing a annotation package to use AnnotationHub can be found here: Create A Hub Package.

• Experiment data packages provide data sets that are used, often by software packages, to illustrate particular analyses. These packages contain curated data from an experiment, teaching course or publication and in most cases contain a single data set. It is also encouraged to utilize ExperimentHub for storage and access to larger data files. ExperimentHub is also particularly useful for hosting collections of related data sets. Instructions for adding data to ExperimentHub and designing an experiment data package to use ExperimentHub can be found here: Create A Hub Package.

• Workflow packages contain vignettes that describe a bioinformatics workflow that involves multiple Bioconductor packages. These vignettes are usually more extensive than the vignettes that accompany software packages. These packages do not need man/ or R/ directories nor a data/ directory as ideally workflows make use of existing data in a Bioconductor package. See development section on Workflows for more details.

See Package Guidelines for details on package format and syntax.

1.3 Package Naming Policy

Package naming:

1. Ownership of package name. Bioconductor follows CRAN’s policy in requiring that contributors give the right to use the package name to Bioconductor at time of submission, so that the Bioconductor team can orphan the package and allow another maintainer to take it over in the event that the package contributor discontinues package maintenance. See Bioconductor’s package end-of-life policy for more details.

2. Uniqueness of package name. Packages should be named in a way that does not conflict (irrespective of case) with any current or past Bioconductor package, nor any current or past CRAN package.

See Package naming guidelines for more guidelines.

1.4 Author / Maintainer Expectations

Acceptance of packages into Bioconductor brings with it ongoing package maintenance responsibilities. Package authors are expected to:

• Follow Bioconductor guidelines

  These include standard guidelines, version numbering, coding style, code performance requirements, memory usage, using existing data classes, and the other requirements described below.

• Follow the release cycle of Bioconductor

  There are two releases each year, around April and October. The release schedule will indicate the timetables and deadlines for each release. A release cycle typically produces two versions of packages, ‘devel’ and ‘release’. It is important to be familiar with these branch concepts. Once your package has been accepted, it will initially be in the ‘devel’ branch. The current devel branch becomes the next release. Most users are expected to use the release branch, so they will not immediately have access to your package until the next release. Bug fixes can be fixed in both branches, while new features should only be added to the ‘devel’ branch.

• Maintain the package using version control

  Realize that Bioconductor, unlike CRAN, maintains all package source code under git version control. This means that you make changes to your package using git. If your package is accepted, you will receive instructions with typical git operations (see the after acceptance section). Package maintenance through software release cycles, including prompt updates to software and documentation, is needed due to possible underlying changes in R and/or other package dependencies.

• Check Build Reports and Fix Issues Promptly

  Bioconductor has weekly to daily build reports for all package types. It is the maintainers responsibility to check the build reports and respond to any ERROR/Warning/Notes produced by the install, build, or check process of a package. The maintainer will receive automatic build notifications when the package starts to fail on linux from BBS-noreply@bioconductor.org; maintainers should check that emails from this email address can be delivered.

• Subscribe to the bioc-devel mailing list

  The Bioconductor team communicates with developers through this list. It is also a good channel to communicate changes to other developers. Addressing Bioconductor team requests in a timely manner guarantees that your package remains available through Bioconductor.

• Register on and use the support site

  The support site is the official support channel for users. Users and even developers may ask questions regarding your package on this platform. Be sure to include all the packages that you maintain in the “Watched Tags” section of your support site profile. This will notify you of any questions posted regarding your package(s). It is important to promptly respond to bug reports and questions either on the Bioconductor support site post or directly to developers. Some maintainers prefer to indicate a BugReports: field in their package’s DESCRIPTION file. This field indicates a particular web page for submitting bug reports and questions.

• Ensure the maintainer email in the DESCRIPTION stays accurate and reachable. The maintainer email in the DESCRIPTION is the definitive contact Bioconductor will use. It is important to keep this email up-to-date to ensure we can contact you if your package is failing or to notify you of any important upcoming impactful events. If the email is not reachable your package would be in jeopardy of removal.

1.5 Submission

• Read and follow the full Contributor Guidelines section.

• Submit by opening a new issue in the Bioconductor BiocContributions repository, following the guidelines of the README.md file. Assuming that your package is in a GitHub Repository and under the default branch, add the link to your repository to the issue you are opening. You cannot specify any alternative branches; the default branch is utilized. The default branch must contain only package code. Any files or directories for other applications (Github Actions, devtools, etc) should be in a different branch.

• Note: The submitter of the package should also be the listed maintainer so we may verify BiocCredentials. Additional push access to other contributors may be granted on request.

1.6 Experiment Data Packages

Experimental data packages contain data specific to a particular analysis or experiment. They often accompany a software package for use in the examples and vignettes and in general are not updated regularly. If you need a general subset of data for workflows or examples first check the AnnotationHub resource for available files (e.g., BAM, FASTA, BigWig, etc.) or ExperimentHub for available processed example data set already included in Bioconductor. If no current files or data sets are appropriate consider an associated Experiment Data Package that utilizes ExperimentHub.

If you have an associated data package for your software package, please do NOT create a separate issue in the our tracker repository for that. Instead, please add the data package repository to the same issue as the software package. The process for doing this is documented here. Generally the data package should be submitted first.

The HubPub package is helpful for creating a template for a hub package. The vignette Create A Hub Package provides full details.

1.7 Annotation Packages

Annotation packages contain lightly or non-curated data from a public source and are updated with each Bioconductor release (every 6 months). They are a source of general annotation for one or many organisms and are not specific to a particular experiment. When possible, they should support the select() interface from AnnotationDbi.

Annotation packages should NOT be posted to the tracker repository. Instead send an email to packages@bioconductor.org with a description of the proposed annotation package and further instructions of where to send the package will be provided. Whenever possible Annotation Packages should use the AnnotationHub for managing files.

The HubPub package is helpful for creating a template for a hub package. The vignette Create A Hub Package provides full details.

1.8 Workflow Packages

Workflow packages contain vignettes that describe a bioinformatics workflow that involves multiple Bioconductor packages. These vignettes are usually more extensive than the vignettes that accompany software packages. These packages do not need man/ or R/ directories nor a data/ directory as ideally workflows make use of existing data in a Bioconductor package. See development section on Workflows for more details

1.9 Review Process

Please see Submitters Guide On What To Expect or if preferred a Slide Deck

Please be mindful that reviewers are volunteers and package reviews are not the only responsibility of Bioconductor team members. We like to see the review process progress by updates from the submitter or by comments from the reviewer within 2-3 weeks. The entire review process typically takes between 2 and 6 weeks. If there is no response after 3 to 4 weeks, package reviewers may close the issue until further updates, changes, and/or commentary are received.

1.10 Following Acceptance

Following acceptance of a package:

• Packages accepted on the tracker repository are added to the ‘devel’ branch of the Bioconductor GIT repository, with the current version number of the accepted package.
• Packages are then built by the Bioconductor nightly build process. On-demand builds of accepted packages do not occur. Please see the build reports for how often the different package types are built. The changes pushed to a ‘devel’ version of a package can take up to 24-28 hours to appear. See build timings. If the build is successful, the package has its own ‘landing page’ created, and the package is made available to users of the ‘devel’ branch of Bioconductor via BiocManager::install().
• Changes to their package (if any), should be done to version in the Bioconductor git server.
• Developers should bump the z portion of their version number every time they commit changes to their package, following the Version numbering guidelines. If developers don’t bump the version, the changes made to their package do not propagate to the Bioconductor web site and package repository.
• Developers should make sure the maintainer email in the DESCRIPTION stays accurate and reachable.

1.11 Additional Support

We are eager to enhance the quality and interoperability of Bioconductor software and will provide additional support when requested by package developers. Example areas of assistance include use of appropriate S4 structures, specific guidance on efficient implementation, guidance on code structure, and critical assessment of package documentation and structure. Use the bioc-devel mailing list or email maintainer@bioconductor.org to obtain additional support.

• Support Email: maintainer@bioconductor.org