Skip to content

DANDI Project Governance

Version: 1.0
Effective Date: YYYY-MM-DD
Status: Draft

1. Purpose

This document defines the governance structure, roles, responsibilities, and decision‑making processes for the DANDI Project. It applies uniformly to all current and future repositories and services, including:

Sites:

Code git repositories:

Data git/git-annex repositories:

2. Mission

DANDI (Distributed Archives for Neurophysiology Data Integration) enables FAIR (Findable, Accessible, Interoperable, Reusable) publishing, preservation, discovery, and computational reuse of neurophysiology data. DANDI provides:

  • a cloud-based platform to store, process, and disseminate data. You can use DANDI to collaborate and publish datasets.
  • open access to data to enable secondary uses of data outside the intent of the study;
  • optimized data storage and access through partnerships, compression and accessibility technologies;
  • facilities to encourage reproducible practices and publications through data standards such as NWB and BIDS;
  • a platform that is not just an endpoint to dump data, but intended to be a living repository that enables collaboration within and across labs.

3. Core Principles

  1. Openness & Transparency: Designs, discussions, and decisions are public by default.
  2. FAIR & Reproducibility: Data and code follow standards and their evolution remain open, traceable, and citable.
  3. Sustainability: Architectural and process decisions consider long-term maintainability.
  4. Inclusivity & Respect: Guided by a Code of Conduct.
  5. Stewardship: Authority derives from consistent, high‑quality contribution.
  6. Accountability: Roles carry explicit responsibilities.
  7. Security & Privacy: Responsible handling of sensitive data and credentials.

4. Project Structure

The DANDI Project codebase includes the components listed in the table below:

Domain Primary Repos
Archive dandi-archive, dandi-infrastructure
Client dandi-cli, dandidav
Metadata dandi-schema, schema
JupyterHub dandi-hub, nebari, nebari-deployments, nebari-docker-images
Documentation & Support dandi-docs, dandi-about, helpdesk

Multiple deployments of this codebase operate as separate instances, each serving distinct research communities and datasets. The DANDI Archive instance is available at https://dandiarchive.org/, and the EMBER-DANDI Archive instance is available at https://dandi.emberarchive.org/. This document governs over the DANDI Project codebase unless otherwise specified.

Contributing code to DANDI repositories does not grant rights or access to the separate instances. Similarly, using any DANDI instance (e.g. the DANDI Archive or EMBER-DANDI Archive service) does not require contributing to the codebase.

5. Roles & Responsibilities

5.1 Contributors

Anyone submitting issues, pull requests, documentation, or feedback.

Responsibilities: - Follow Code of Conduct and contribution guidelines. - Strive to provide sufficient context and steps to reproduce. - Where applicable, write tests and documentation for code changes.

5.2 Reviewers

Contributors granted reviewer status for designated repositories.

Responsibilities: - Perform timely, constructive reviews. - Enforce style, testing, and security practices. - Identify architectural and performance impacts.

Path to role: - Consistent high‑quality reviews. - Sponsored by at least one Maintainer.

5.3 Maintainers

Individuals with merge rights for designated repositories.

Responsibilities: - Merge approval. - Release planning and tagging. - Triage (labels, prioritization, assignment). - Manage vulnerability reports. - Escalate policy or security concerns. - Facilitate cross‑repository alignment. - Onboard and mentor reviewers.

Expectations: - Active presence. - Adhere to conflict of interest and bias avoidance.

Path to role: - Demonstrated sustained contributions and review quality. - Nomination and consensus of existing repository Maintainers.

Maintainers for the respective DANDI repositories: | Repository | Maintainers | | -- | -- | | dandi/dandi-archive | @dandi/archive-maintainers | | dandi/dandi-infrastructure | @dandi/archive-admin | | dandi/dandi-cli | @dandi/dandi-cli-maintainers | | dandi/dandi-schema | @dandi/dandi-schema-maintainers | | dandi/dandi-hub | @dandi/dandi-hub-maintainers | | dandi/nebari-deployments (Private) | @dandi/dandi-hub-maintainers | | dandi/nebari | @dandi/dandi-hub-maintainers | | dandi/dandidav | @dandi/dandi-dav-maintainers | | dandi/dandi-about | @dandi/dandi-docs-maintainers | | dandi/dandi-docs | @dandi/dandi-docs-maintainers | | dandi/example-notebooks | @dandi/dandi-docs-maintainers |

5.4 Project Leadership

  • Current leadership team:

  • Responsibilities:

    • Approve or amend governance document and Code of Conduct.
    • Strategic project oversight.
    • Resolve escalated disputes.
    • Approve major architectural shifts.
    • Oversee risk, sustainability, funding alignment.

5.5 DANDI Archive Administrators

Responsibilities: - Monitor service health and performance. - Manage user accounts and permissions. - Respond to data access requests and issues.

Administrators: - @satra, @yarikoptic, @waxlamp, @mvandenburgh, @jjnesbitt, @danlamanna, @brianhelba, @kabilar, @asmacdo, @bendichter, @candleindark, @CodyCBakerPhD.

6. Decision-Making Model

6.1 Roadmap

  • Project targets are discussed during the biweekly Engineering Core and Scientific Core meetings.
  • Project Leadership provides guidance on prioritization of targets.
  • Public notes of these meetings are available on Google Drive.

6.2 Consensus Process

  1. Open a GitHub issue describing the bug/feature request, context, and possible solutions.
  2. For major architectural changes, create a design document and submit as a PR for discussion and refinement. For reference, see previous design documents.
  3. Collect feedback during a 7-day review period.
  4. Summarize consensus in the GitHub issue and resolve all suggestions in the design document.
  5. Implement via pull request(s) referencing the proposed design.

6.3 Conflict of Interest

  • Participants should disclose direct commercial interest in a technology choice.
  • Conflicted member recuses themselves from final decision phase.

7. Pull Request Workflow

7.1 Pull Request Requirements

  • Link the associated issue.
  • Add a clear description (problem, approach, alternatives considered).
  • Major architectural changes require a design document.
  • Add or update tests.
  • Update documentation.
  • Ensure CI passes.
  • Large pull requests should be split unless justified.
  • No introduction of unreviewed secrets or credentials.
  • Verified provenance for large binary additions (discouraged in code repos).

7.2 Merge Policy

  • All pull requests require:
    • All comments must be resolved or addressed.
    • If a comment cannot be resolved, the Project Leadership would be enlisted to decide on the path forward.
    • Approval by at least 1 listed Maintainer for that repository.
    • 24-hour waiting period (unless addressing a critical issue or trivial issue [e.g. typos]).
  • See section below regarding updates to the Governance document.

7.3 Draft vs Ready for Review

  • Open as a Draft for early feedback.
  • Convert to “Ready” only when tests and documentation are updated.

7.4 Reverts

  • Any Maintainer may revert a merged pull request causing regression, security issue, or service degradation, with immediate notice in original pull request thread.
  • All changes (including reverts) must be submitted through a pull request, and a new release must be made if the prior change was already released.
  • Follow-up issue required to track remediation.

8. Releases

8.1 Versioning

8.2 Release Steps

  • For dandi-archive, once a pull request is merged the changes are deployed to the sandbox environment (https://sandbox.dandiarchive.org) for review and testing prior to release.
  • New releases are created with a GitHub Actions workflow built around auto.
  • When a pull request is merged that has the "release" label, auto:
    • Updates the changelog based on the pull requests since the last release and commits the results.
    • Tags the new commit with the next version number.
    • Creates a GitHub release for the tag.
  • For dandi-cli, upon release a new version is published to PyPI.

9. Security

9.1 Reporting

9.2 Handling

  • Initial assessment within 5 business days.
  • Coordinate and address issue within 30 days.
  • User advisory via email when appropriate.

9.3 Hardening Practices

  • Mandatory dependency scanning.
  • Principle of least privilege enforced for service accounts.

10. Documentation

11. Communication

Communication channels include:

  • GitHub Issues and Discussions for user support and team discussions.
  • https://github.com/dandi/helpdesk for generic support requests and questions.
  • individual repositories for targeted discussions.
  • Slack for user support and team discussions.
  • Email (info@dandiarchive.org, help@dandiarchive.org) for user support.
  • Email announcements for critical notifications to users.
  • GitHub Releases for release announcements.
  • Email newsletter to highlight major changes.

12. Community

13. Amendments to Project Governance

Process

  1. Proposal pull request.
  2. Minimum of a 30-day public comment.
  3. Approval by Project Leadership.

  4. Update version and effective data in Governance document header.

  5. Urgent amendments may use an accelerated 7-day window with rationale documented.

  6. The document becomes active upon Project Leadership approval and publication in the DANDI Docs.

14. Sunset Policy

If a component becomes unmaintained: - Create a plan with guidance from the Project Leadership. - Update documentation to reflect deprecation including migration guidance. - Mark repository with ARCHIVED notice.

15. Licenses

  • Licenses (for code, artwork, documentation) are declared per repository.
  • Licenses must be DFSG and OSI compliant.