You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
### Recommended Workflow: Fork and Pull Request Model
14
+
The systemPipe project provides a suite of R/Bioconductor packages for designing, building and running end-to-end analysis workflows on local machines and HPC systems, while generating at the same time publication quality analysis reports.
15
15
16
-
This is the most common and robust method for community contributions.
16
+
This site serves mainly as a landing page providing a high-level overview of each package and links to the corresponding pages on Bioconductor. Detailed usage instructions are provided in the vignetted of each package on Bioconductor.
17
+
18
+
### Core Packages
19
+
20
+
*__systemPipeR: Workflow Management System (WMS)__ <br/>
21
+
[_systemPipeR_](https://bioconductor.org/packages/release/bioc/html/systemPipeR.html) is the core workflow management package, enabling users to define, organize, and run workflows that combine R functions with external command-line software([H Backman and Girke 2016](https://link.springer.com/article/10.1186/s12859-016-1241-0)). A scientific reporting system is integral part of the package.
22
+
23
+
*__systemPipeRdata: Workflow Templates__ <br/>
24
+
[_systemPipeRdata_](https://www.bioconductor.org/packages/release/data/experiment/html/systemPipeRdata.html) offers a set of pre-configured workflow templates and associated resources that simplify the setup of common analysis pipelines.
[_systemPipeShiny_](https://bioconductor.org/packages/release/bioc/html/systemPipeShiny.html) provides a Shiny-based graphical interface for executing selected workflows and accessing a collection of interactive visualizations.
28
+
29
+
30
+
## Workflow
31
+
32
+
### Templates
33
+
34
+
Preconfigured workflow templates are provided by the [_systemPipeRdata_](https://www.bioconductor.org/packages/release/data/experiment/html/systemPipeRdata.html) package. The provided templates are compatible with the systemPipeR WMS (H Backman and Girke 2016). Support for running external software is provided by a command-line interface (CLI) that adopts the Common Workflow Language (CWL). How to use systemPipeR is explained in its main vignette. The workflow templates provided by systemPipeRdata come equipped with sample data and the necessary parameter files required to run a selected workflow. This setup simplifies the learning process of using systemPipeR, facilitates testing of workflows, and serves as a foundation for designing new workflows.
35
+
36
+
### Contributions
37
+
38
+
For contributing workflows, we recommend the following fork and pull request approach.
17
39
18
40
1. Create a "Template" Repository: Within your organization, create a public repository that serves as a template or a starting point for submissions. It should contain contribution guidelines (CONTRIBUTING.md), a code of conduct, license information, and potentially a project structure.
19
41
2. Community Forks the Repository: Users interested in submitting a project will fork this "Template" repository to their personal GitHub account. This creates their own copy where they can work independently.
20
42
3. User Development: The user develops their project within their personal fork.
21
43
4. User Opens a Pull Request: When the user is ready to submit their project, they open a pull request from their personal repository back to the main "Template" repository in your organization. This pull request serves as the formal submission and review mechanism.
22
44
5. Review Process: Organization members review the pull request, provide feedback, request changes, and ensure the submission meets community standards.
23
45
6. Integration into the Organization:
24
-
+ If the goal is to integrate their code into the template project, you merge the pull request.
25
-
+ If the goal is for their entire repository to become a standalone repository within your organization, you would accept the submission via the pull request review process, and then work with the user offline to have them transfer ownership of their repository to the organization.
46
+
+ If the goal is to integrate their code into the template project, you merge the pull request.
47
+
+ If the goal is for their entire repository to become a standalone repository within your organization, you would accept the submission via the pull request review process, and then work with the user offline to have them transfer ownership of their repository to the organization.
0 commit comments