Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
590 lines (408 loc) · 33 KB

CONTRIBUTING.md

File metadata and controls

590 lines (408 loc) · 33 KB
Raw

Contributing to the WILDS WDL Library

Thank you for your interest in contributing to the WILDS WDL Library! This document provides guidelines for contributing modules, pipelines, and improvements to our centralized collection of bioinformatics WDL infrastructure.

Table of Contents

Getting Started

Before contributing code changes, please:

  1. Fork the repository to your GitHub account

  2. Set up your development environment with the required tools:

  3. Make code changes and push them to your fork

  4. Submit a pull request (PR) to merge your contributions into the main branch of the original repo

    • The title of your PR should briefly describe the change.
    • If your contribution resolves an issue, the body of your PR should contain Fixes #issue-number

Repository Structure

The WILDS WDL Library follows a two-tier architecture:

  • Modules: Collection of tasks that use a given tool
  • Pipelines: Analysis workflows that import and combine module tasks (ranging from basic examples to production-ready pipelines)
wilds-wdl-library/
├── modules/
│   └── ww-toolname/
│       ├── ww-toolname.wdl
│       └── README.md
├── pipelines/
│   └── ww-pipeline-name/
│       ├── ww-pipeline-name.wdl
│       ├── inputs.json
│       └── README.md
└── .github/
    └── workflows/     # CI/CD automation

Types of Contributions

1. Bug Reports and Issues

  • Use the GitHub Issues page
  • Provide detailed information about the problem
  • Include error messages, info about input files, and steps to reproduce
  • Tag issues appropriately (bug, enhancement, question, etc.)

2. Documentation Improvements

  • Fix typos, improve clarity, or add missing information
  • Enhance README files with better examples

3. Module Contributions

  • Focus on one high-utility bioinformatics tool
  • Follow standardized module structure
  • Include comprehensive testing and validation

4. Pipeline Contributions

  • Combine existing modules into analysis workflows
  • Range from basic educational examples (2-3 modules) to advanced production pipelines (10+ modules)
  • Document complexity level in the README
  • Provide educational and/or production value for the community

Module Development Guidelines

See our ww-template module as an example

The module folder must contain:

  1. ww-toolname.wdl - Main WDL file containing task definitions for the tool
  2. At least one of testrun.wdl or testrun_hpc.wdl - Test workflow demonstrating module functionality (see "Test workflow files" below)
  3. README.md - Comprehensive documentation

The module folder may optionally contain:

  • Custom scripts (e.g., .R, .py, .sh) - If your task requires a custom script that isn't part of the container image, place it directly in the module directory alongside the WDL files. The script can be fetched at runtime using curl or wget in the task's command block.

Test workflow files (testrun.wdl and/or testrun_hpc.wdl):

Most modules ship with a single testrun.wdl that exercises the workflow on a tiny, biologically minimal input — fast enough to run on a GitHub Actions runner. CI/CD always uses testrun.wdl, and the monthly HPC test run falls back to it when no HPC-specific file is provided.

For modules where CI execution is impractical (GPU-only tools, license-gated tools that require module load on HPC, or workflows that need a much larger, more realistic input to be meaningful), you may add a testrun_hpc.wdl:

Files present CI runs HPC runs
testrun.wdl only testrun.wdl testrun.wdl
both files testrun.wdl testrun_hpc.wdl
testrun_hpc.wdl only (skipped — HPC-only module) testrun_hpc.wdl
neither not allowed — discovery will fail same

ww-esmfold is the canonical HPC-only example; pair it with testrun_hpc.wdl when adding similar GPU/licensed tools.

Your main WDL file (ww-toolname.wdl) must include:

  • Version declaration: Use WDL version 1.0 (default). Use version 1.2 only when a feature unavailable in 1.0 is required (e.g., the Directory type); document the reason in the module README. Note that WDL 1.2 modules are not tested with Cromwell.
  • Task definitions: Individual tasks with proper resource requirements
  • Metadata documentation: Describe properties of tasks (e.g. inputs, outputs) using meta and parameter_meta blocks
  • Ontology metadata: Include the following metadata tags in each task's meta block to describe the task and its File parameters with EDAM ontology terms (using underscores instead of spaces):
    • topic: Comma-separated EDAM topic terms describing the bioinformatics topic and data type(s) the task handles. For example, a DNA variant caller for SNPs would be "genomics,dna_polymorphism". Use "any" for tasks that are very non-specific (e.g. downloading data from AWS).
    • operation: An EDAM operation term describing what the task does (e.g. "variant_calling"). Use "any" for tasks that are extremely non-specific.
    • species: Comma-separated list of species terms. Choose from: human (human data), eukaryote (non-human eukaryote data), prokaryote (prokaryote data), virus (viral data). Include all that apply. For example, a task that works on both human and mouse data would be "human,eukaryote".
    • File inputs/outputs: Describe File-type parameters (not strings, integers, booleans, etc.) using the format <param_name>:<EDAM data type>:<EDAM format type>. Use "none" if a category has no files. For important but niche formats not in EDAM, you may use the file extension (e.g. sig, csi). Separate multiple formats per parameter with | (e.g. "input_aln:nucleic_acid_sequence_alignment:bam|sam|cram"). Use these metadata tags to describe file inputs/outputs:
      • Sample or run-specific data (e.g. target region BED file, sample FASTQ): input_sample_required, input_sample_optional
      • Reference data (e.g. allele frequencies, reference genome)input_reference_required, input_reference_optional
      • Output files (e.g. sample BAM, reference genome index)output_sample, output_reference
      • Common <file extension> = <EDAM format> mappings: txt = textual_format; rds = binary_format; zip = the format of the file before the .zip (e.g. .txt.zip should be textual_format); gz = the format of the file before the .gz (e.g. .tar.gz should be tar_format)

Your test workflow file (testrun.wdl or testrun_hpc.wdl) must include:

  • Version declaration: Use WDL version 1.0 (default), or match version 1.2 if the module under test uses it
  • Module imports: Import the module being tested and the ww-testdata module using relative paths (e.g. "./ww-toolname.wdl" for the own module and "../ww-testdata/ww-testdata.wdl" for test data)
  • Sample struct definition: Define a struct for organizing sample inputs if needed
  • Test workflow: A toolname_example workflow that demonstrates all tasks (must follow the naming convention {module}_example where {module} is the tool name, e.g., star_example for ww-star)
  • Auto-downloading of test data: Use the ww-testdata module to automatically provision test data
  • Validation task (optional): Consider including a validation task to verify output correctness

Note: testrun.wdl files use relative path imports (unlike the pipeline source WDL files, which use GitHub raw URLs for end-user convenience). Relative imports ensure that CI/CD and local test runs always exercise the local version of the WDL under development, rather than fetching a stale copy from a remote branch.

Parameter preferences:

  • Use descriptive parameter names
  • Include optional parameters with sensible defaults
  • Support both single samples and batch processing where applicable
  • GPU tasks should expose a Boolean gpu_enabled input and use gpu: gpu_enabled in the runtime block

Docker image preferences:

  • Use images from the WILDS Docker Library when available
  • If creating new images, follow WILDS container standards and consider contributing to the WILDS Docker Library.
  • Specify exact image versions (avoid latest tags)
  • Declare the image as an overridable input parameter with a pinned default: String docker_image = "getwilds/tool:version" in the task input block, referenced via docker: docker_image in the runtime block
  • Document image dependencies in the README

Module manifest (module.json):

Every module and pipeline in this library ships a module.json manifest, an early adoption of the proposed WDL v1.4 module manifest spec. We're adding these ahead of that spec being finalized, so the library is ready as WDL module-management tooling (like Sprocket's symbolic module imports) matures; the spec itself is still an unmerged draft and its field definitions may still change. For the schema itself (field definitions, dependency selectors, versioning rules) see the spec's modules/SPEC.md and module.schema.json. Since the spec is still unmerged and changing, treat that upstream source as ground truth over any summary written here or elsewhere in this repo.

WILDS-specific conventions on top of the spec:

  • Add a module.json for every new module and pipeline. No executor consumes it at runtime yet, but please add one anyway to keep the library consistent. Use an existing module's module.json as a template.
  • CI validates structure, not content: make lint_module_json (see .github/scripts/validate_module_json.py) checks any module.json it finds against the spec's required fields and shapes.
  • This repo's own license is always "MIT". Per-tool licenses in tools[] must use current SPDX identifiers; the parser rejects deprecated forms (e.g. GPL-3.0-only, not GPL-3.0).
  • For a tool with a nonstandard license, use an SPDX LicenseRef- placeholder (e.g. "LicenseRef-VarScan-NonCommercial") and flag it for reviewer attention in your PR description, since there is no real SPDX identifier for these.
  • See pipelines/ww-bwa-gatk/module.json for the reference pattern for declaring module dependencies in a pipeline's manifest.

Module signature (module.sig):

Every module and pipeline with a module.json also carries a module.sig, an Ed25519 signature over the module's deterministic content hash, produced by sprocket dev module sign. This lets a consumer verify that a module's files (WDL, README, scripts, everything except module.json's own module.sig/module-lock.json) haven't been tampered with since WILDS published them.

These signatures aren't usable yet. sprocket dev module sign/sprocket dev module verify are not in any released Sprocket version; we're adding module.sig files now, ahead of that tooling shipping, so the library is ready once it does. There's nothing to check or verify against these signatures today.

A few things to know:

  • You don't need to sign anything yourself. CI re-signs any module or pipeline whose directory content changed in a push to main (see .github/workflows/sign-modules.yml and .github/scripts/sign_modules.py) and commits the updated module.sig automatically. Don't hand-edit module.sig files or worry about them in your PR.
  • CI pushes those updated module.sig files using a GitHub App token, not the default GITHUB_TOKEN, since branch protection on main requires a PR and only the App is permitted to bypass that for this automated commit.
  • Any change to a module's directory invalidates its old signature, not just WDL edits: a README tweak, a fixed typo, a new test fixture, anything under modules/ww-toolname/ or pipelines/ww-pipeline-name/ changes the content hash CI signs.
  • Ed25519 signatures are deterministic: signing the same content with the same key always produces the same signature bytes. If module.sig changes with no apparent change to the module's content, the key used to sign it changed instead (e.g. after rotating the signing key).
  • The signing key is a standard Ed25519 SSH key (the kind ssh-keygen -t ed25519 produces), in OpenSSH format. sprocket dev module sign and sprocket dev module verify are not yet in a released Sprocket version; see the pinned commit in .github/workflows/sign-modules.yml for what CI currently installs.

Pipeline Development Guidelines

Pipelines should:

  • Combine existing modules from the library
  • Demonstrate realistic analysis workflows
  • Serve as educational templates and/or production-ready analyses
  • Use publicly available test data
  • Document their complexity level (Basic, Intermediate, or Advanced)

Complexity Levels:

Level Modules Typical Runtime Description
Basic 2-3 < 30 minutes Simple integrations ideal for learning
Intermediate 4-6 1-4 hours Multi-step analyses for common use cases
Advanced 10+ > 4 hours Comprehensive production pipelines

Prefer Existing Modules

  • Pipelines should primarily combine existing modules - prefer using existing modules over creating new task definitions. If you need new functionality, consider contributing it as a module first. Tasks defined within pipelines are acceptable only when the logic is truly specific to that single pipeline and would not be reusable elsewhere (e.g., reorganizing that pipeline's particular outputs).

Pipeline inputs.json

Each pipeline should include an inputs.json file that serves as an example for users. This file demonstrates the expected input structure and helps users understand what values they need to provide when running the pipeline. Your inputs.json should:

  • Use dummy/placeholder paths for file inputs (e.g., "/path/to/your/sample.fastq.gz")
  • Include common or recommended values for non-file parameters
  • Document all required inputs with realistic example values
  • Use the pipeline's README to provide descriptions and guidance for each input parameter

Note: GitHub Action tests use the ww-testdata module to automatically download test data, so your inputs.json does not need to reference actual test files for CI purposes.

Platform-Specific Configuration Files (Optional)

You may include folders containing configuration files for execution on cloud platforms (e.g., Cirro, Terra):

  • Location: Place platform configs in a subdirectory within the pipeline (e.g., pipelines/ww-example/.cirro/)
  • Naming: Use dotfile directory names (e.g., .cirro/, .terra/)
  • Documentation: Briefly describe how to use the configurations in the pipeline's README and include links to platform documentation

Platform configurations are entirely optional and should not be required to run the pipeline with standard WDL executors (Cromwell, miniWDL, Sprocket).

Cirro Configurations

If you'd like to make your new pipeline Cirro-compatible:

  1. Ensure you have Cirro permissions to add custom pipelines
  2. Create a new branch, add the .cirro folder
  3. Look at our existing pipelines and the Cirro documentation to get started
  4. In Cirro, add a custom pipeline that points to this GitHub repo and your branch
  5. Upload some test data to Cirro and test run your pipeline
  6. If all looks good, submit a pull request, then update the branch in Cirro to main once merged

Pipelines with .cirro/ directories are automatically validated in our CI. The validation checks that all required files are present (preprocess.py, process-form.json, process-input.json, process-output.json, process-compute.config), JSON files are valid, and preprocess.py has no syntax errors. You can run this locally with make lint_cirro.

Some tips for Cirro integration:

  • Your WDL must be able to handle AWS S3 URIs
  • Your WDL must not use ftp for file transfer (http is ok)
  • Your WDL must not use a Docker image that is based on Alpine Linux

If you need help or want to make your pipeline available to all Cirro users, reach out to us at wilds@fredhutch.org

Testing Requirements

Local Tests

Make sure you have these installed:

Option 1: Manual Testing

Test your WDL manually by navigating to the module directory:

cd modules/ww-toolname

# Linting with miniwdl (check both main module and test workflow)
miniwdl check ww-toolname.wdl
miniwdl check testrun.wdl

# Linting with sprocket (ignoring things we don't care about)
sprocket lint \
  -e TodoComment \
  -e ContainerUri \
  -e TrailingComma \
  -e CommentWhitespace \
  -e UnusedInput \
  ww-toolname.wdl

sprocket lint \
  -e TodoComment \
  -e ContainerUri \
  -e TrailingComma \
  -e CommentWhitespace \
  -e UnusedInput \
  testrun.wdl

# Test running (use testrun.wdl for execution tests)
sprocket run testrun.wdl
miniwdl run testrun.wdl

Option 2: Automated Testing with Makefile (Recommended)

Use our automated Makefile from the repository root for easier testing:

# Test a specific module or pipeline (replace ww-toolname with your module/pipeline name)
make lint NAME=ww-toolname          # Run all linting checks
make lint_sprocket NAME=ww-toolname # Run only sprocket linting
make lint_miniwdl NAME=ww-toolname  # Run only miniwdl linting
make run_sprocket NAME=ww-toolname  # Run sprocket with proper entrypoint
make run_miniwdl NAME=ww-toolname   # Run miniwdl

# Test all modules and pipelines
make lint    # Lint everything
make run     # Run everything with both sprocket and miniwdl

# Scope by tier with TYPE=modules or TYPE=pipelines
make run_sprocket TYPE=modules

# By default, the run targets use testrun.wdl (TARGET=ci). To exercise
# the HPC variant locally instead — useful on a system with GPUs and the
# right module environment — pass TARGET=hpc; the run will prefer
# testrun_hpc.wdl when present and fall back to testrun.wdl otherwise:
make run_sprocket NAME=ww-toolname TARGET=hpc

The Makefile automatically handles:

  • Proper entrypoint naming for sprocket ({module}_example)
  • Module discovery and validation
  • Dependency checking (sprocket, uv, etc.)
  • Consistent test execution across all modules

Test Data

  • Use the ww-testdata module for standardized test datasets
  • If you need additional test datasets, modify the ww-testdata module also
  • Include small, representative test files in your examples

Automated Tests

All contributions must pass our automated testing pipeline which executes on a PR via GitHub Actions:

  • Multi-executor validation: Tests with Cromwell, miniWDL, and Sprocket. version 1.2 items skip Cromwell (no WDL 1.2 support).
  • Container verification: All Docker images must be accessible and functional
  • Syntax validation: WDL syntax and structure validation
  • Integration testing: Cross-module compatibility testing
  • Cirro validation: Validates .cirro/ configurations for pipelines that include them

CI-Excluded Modules

Some modules require more memory than GitHub Actions runners provide (~16 GB) and are excluded from CI test runs. These modules are listed in the CI_EXCLUDED_ITEMS dictionary in .github/scripts/discover_wdls.py. Linting still runs for these modules in CI, and their test workflows are validated on the Fred Hutch high performance computing (HPC) cluster on a monthly basis (see below).

Currently excluded:

  • ww-esmfold: Requires ~24 GB to load the 3B-parameter ESM-2 model

If your module exceeds GitHub Actions resource limits, add it to CI_EXCLUDED_ITEMS and document the exclusion in your module's README. Be sure to verify that the test workflow runs successfully on an HPC or local machine with sufficient resources.

HPC Monthly Test Runs

Contributors should be aware that to supplement GitHub Actions CI (which has resource limits), we run the full test suite monthly on the Fred Hutch HPC using a SLURM batch script. This ensures that CI-excluded modules are still regularly validated, and that all modules/pipelines work under HPC execution conditions (Slurm + Apptainer).

The infrastructure consists of two scripts:

To run it:

export GITHUB_ISSUE_NUMBER=<tracking_issue_number>
export WORK_DIR=/hpc/temp/your-username/wilds-testrun
sbatch /path/to/hpc-testrun.sbatch

You can also run the test suite manually on the HPC without the SLURM script. Pass TARGET=hpc so each module/pipeline runs its testrun_hpc.wdl when present (with testrun.wdl as the fallback):

make run_sprocket TARGET=hpc SPROCKET_CONFIG=/path/to/your/sprocket-slurm-config.toml

Documentation Website

The WILDS WDL Library includes an automatically-generated documentation website that provides comprehensive technical documentation for all modules and pipelines. Understanding how this documentation works is important for contributors.

How Documentation is Generated

The documentation website is built using Sprocket and automatically deployed to GitHub Pages. The documentation is generated from:

  • README files: Each module and pipeline directory contains a README.md that becomes the documentation homepage for that component
  • WDL files: Task descriptions, inputs, outputs, and metadata are automatically extracted from WDL files
  • Main README: The repository's root README.md serves as the documentation site homepage

Automatic Deployment

Documentation is automatically built and deployed when changes are merged to the main branch:

  1. The build-docs.yml GitHub Actions workflow triggers on push to main
  2. The workflow runs the make_preambles.py script to prepare WDL files
  3. Sprocket generates static HTML documentation
  4. The postprocess_docs.py script applies final formatting
  5. Documentation is deployed to GitHub Pages at the repository's documentation URL

Important: You don't need to build or commit documentation files - they are generated automatically in CI/CD.

Previewing Documentation Locally

Before submitting a PR, you can preview how your changes will appear on the documentation website using the provided Makefile targets:

Build and Preview Documentation

# Build documentation locally (mirrors the CI/CD process)
make docs-preview

# Serve the documentation on http://localhost:8000
make docs-serve

# Or do both in one command
make docs

The docs-preview target will:

  • Check for uncommitted changes and warn you (docs are built from your last commit)
  • Safely stash any uncommitted work
  • Run the same build process as the GitHub Actions workflow
  • Generate documentation in the docs/ directory
  • Restore your uncommitted changes when finished
  • Clean up all temporary build files

Note: The docs/ directory is gitignored and should never be committed to the repository.

What Gets Built

When you run make docs-preview, the build process:

  1. Prepends each module's README to its WDL file for better documentation context
  2. Converts GitHub import URLs to relative paths for local navigation
  3. Generates comprehensive HTML documentation for all tasks, workflows, and components
  4. Applies custom styling and post-processing

Documentation Best Practices

When contributing, ensure your documentation is clear and complete:

  • README files: Write clear, user-focused descriptions of what your module/pipeline does
  • Task metadata: Use meta blocks to document task purpose, authors, and other high-level information
  • Parameter metadata: Use parameter_meta blocks to describe all inputs and outputs
  • Examples: Include usage examples in README files
  • Preview locally: Always run make docs-preview before submitting a PR to verify how your documentation will appear

Troubleshooting Documentation Builds

If you encounter issues with local documentation builds:

  • Ensure you have the required dependencies installed (sprocket, uv, python 3.13)
  • Check that you're running the command from the repository root
  • Review error messages - they often indicate issues with WDL syntax or README formatting

For questions about documentation, please contact wilds@fredhutch.org.

Citation and Attribution

The repository includes a CITATION.cff file that provides structured citation metadata for the WILDS WDL Library. This file follows the Citation File Format standard and is used by GitHub, Zenodo, and other platforms to generate proper citations.

When to Update CITATION.cff

If you are a new contributor making a significant contribution (e.g., a new module or pipeline), add yourself to the authors: list in CITATION.cff:

authors:
  - family-names: LastName
    given-names: FirstName
    affiliation: "Fred Hutch Cancer Center"
    orcid: "https://orcid.org/0000-0000-0000-0000"  # optional but encouraged

Keep the ORCID in full URL format (https://orcid.org/...) in CITATION.cff — this differs from .dockstore.yml which uses just the numeric ID.

Keeping Author Info Consistent

Author information appears in several places across the repo. When adding or updating author details, make sure the following are consistent:

  • CITATION.cff — the canonical source for contributor names, affiliations, and ORCIDs
  • .dockstore.yml — author entries for each module/pipeline (see Dockstore Registration)
  • WDL meta blocks — author and email fields in task/workflow metadata

Dockstore Registration

All modules and pipelines in this library are published on Dockstore, a platform for sharing and discovering bioinformatics workflows. When you contribute a new module or pipeline, you must add a corresponding entry to the .dockstore.yml file in the repository root.

Adding a Module Entry

Modules are registered under the tools: section. Use an existing entry as a template:

tools:
  - name: ww-toolname
    subclass: WDL
    primaryDescriptorPath: /modules/ww-toolname/ww-toolname.wdl
    readMePath: /modules/ww-toolname/README.md
    authors:
      - name: Your Name
        email: your.email@fredhutch.org
        role: Your Role
        affiliation: Fred Hutch Cancer Center
        orcid: 0000-0000-0000-0000  # optional but encouraged
    description: "Brief description of what this module does"
    topic: relevant-topic
    enableAutoDois: true
    filters:
      branches:
        - main
      tags:
        - relevant-tag-1
        - relevant-tag-2

Adding a Pipeline Entry

Pipelines are registered under the workflows: section with the same structure, but with paths pointing to the pipelines/ directory. If you have an inputs.json, include it in testParameterFiles.

Author Information

  • List all authors who contributed tasks to the module or steps to the pipeline
  • Include orcid if available (use the numeric ID only, e.g., 0009-0002-2052-1084)
  • Keep entries in alphabetical order by module/pipeline name within their section
  • Author details should match the CITATION.cff file where applicable

Pull Request Process

After meeting the requirements above, submit a PR to merge your forked repo into main.

  1. Create descriptive PR title:

    • Examples: Add BWA alignment module, Add RNA-seq analysis pipeline

  2. Fill out PR template: Provide detailed information about your contribution

  3. Link related issues: Reference any GitHub issues your PR addresses

  4. Request reviews: Tag Emma Bishop (@emjbishop) or Taylor Firman (@tefirman)

AI-Assisted Development

We occasionally use large language models (primarily Claude) to assist with prototyping modules and pipelines, and contributors are welcome to do the same. However, all AI-generated code must go through the same testing, linting, and human review process as any other contribution. Please ensure you review and understand any AI-generated code before submitting it in a PR.

To make AI assistance more consistent with project conventions, the repository ships an AGENTS.md project-context file (following the vendor-neutral agents.md convention) and a set of reusable task recipes under .agents/skills/:

  • add-testdata — add a test-data download task to ww-testdata
  • create-module — scaffold a new ww-toolname module
  • create-pipeline — assemble existing modules into a new pipeline
  • lint-module — run linting and fix issues
  • pr-description — draft a PR description from the current branch
  • run-tests — run testrun.wdl via Sprocket or miniwdl

Tools that follow the AGENTS.md convention (OpenCode, Claude Code, and others) discover these files automatically. Use of these tools is optional — they are provided as a convenience and do not replace the testing and review requirements above.

Review Criteria

Your PR will be evaluated on:

  • Functionality: Does it work as intended?
  • Testing: Are tests comprehensive and passing?
  • Documentation: Is documentation clear and complete?
  • Standards compliance: Does it follow WILDS conventions?
  • Code quality: Is the WDL code well-structured and readable?
  • Uniqueness: Does it avoid duplicating existing functionality in the library?

Help for new contributors

New contributors are welcome! If you're new to WDL or bioinformatics workflows:

  • Review our WDL 101 course materials
  • Check out existing modules for examples
  • Don't hesitate to ask questions in issues or via email. If you have a uw.edu or fredhutch.org email you can also ask questions in our fh-data slack workspace
  • Consider starting with documentation contributions

For more questions you can contact the Fred Hutch Office of the Chief Data Officer (OCDO) at wilds@fredhutch.org

Code of Conduct

By participating in this project, you agree to abide by our code of conduct:

  • Be respectful: Treat all community members with respect and kindness
  • Be collaborative: Work together constructively and help others learn
  • Be inclusive: Welcome contributors from all backgrounds and experience levels
  • Be patient: Remember that everyone is learning and growing

Reporting Issues

If you experience or witness unacceptable behavior, please report it to wilds@fredhutch.org.

License

By contributing to this project, you agree that your contributions will be licensed under the MIT License. See the LICENSE file for details.

Thank you for contributing to WILDS! Your contributions help advance reproducible bioinformatics research for the entire community.