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, achieved through partnerships with cloud providers, compression to reduce storage costs and bandwidth, and accessibility technologies that broaden who can use the data;
  • facilities to encourage reproducible practices and publications through data standards such as NWB and BIDS;
  • a platform that is not merely an endpoint to dump data, but rather 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 project-wide Code of Conduct that applies across all DANDI repositories and instances, regardless of whether a CODE_OF_CONDUCT.md file is present in a given repository.
  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.
  8. Pragmatism: Decisions follow the sociocracy principle of "good enough for now, safe enough to try" — preferring incremental, reversible progress over indefinite deliberation.

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

The responsibilities, expectations, and paths to role described in the subsections below include, but are not limited to, the items listed.

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. - Follow the Conflict of Interest policy. - Avoid bias (e.g., favoring contributions from one's own institution, affiliated collaborators, or preferred technologies over others on non-technical grounds).

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 Administrators

Administrators are scoped by DANDI service. Authoritative per-service membership lives in the corresponding GitHub team and may evolve independently of this document.

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

Service/Repository Administrators
dandi-archive & dandi-infrastructure @satra, @yarikoptic, @waxlamp, @mvandenburgh, @jjnesbitt, @danlamanna, @brianhelba
dandi-cli & dandi-schema @satra, @yarikoptic, @CodyCBakerPhD, @candleindark, @asmacdo
dandi-hub @satra, @yarikoptic, @asmacdo, @kabilar
dandi-docs, dandi-about, helpdesk @satra, @yarikoptic, @kabilar, @bendichter, @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

Requirements include, but are not limited to, the following.

  • 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.
  • Large binary additions are discouraged in code repositories; when unavoidable, the contributor must document the binary's origin and licensing in the pull request description so its provenance can be verified during review.

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]).

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 Release Approach

  • Releases generally follow Semantic Versioning 2.0 for APIs and libraries.
  • Each repository has a release approach that is documented n the table below.
Repository Approach Tagging Publishing
dandi-archive auto creates a release upon merge of a release-labeled pull request v{version} GitHub Release
dandi-cli auto creates a release upon merge of a release-labeled pull request {version} GitHub Release + PyPI
dandi-schema auto creates a release upon merge of a release-labeled pull request {version} GitHub Release + PyPI + dandi/schema release for the JSON schema
dandidav merge of a release-labeled pull request v{version} GitHub Release + https://webdav.dandiarchive.org
dandi-hub, nebari-deployments ad-hoc - https://hub.dandiarchive.org
dandi-docs, dandi-about continuous deployment from master - https://docs.dandiarchive.org, https://about.dandiarchive.org

8.2 Example of the dandi-archive release flow

  • 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.

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.