Add governance document for the DANDI Archive Project

docs/terms-policies/governance.md

@@ -0,0 +1,288 @@
+# 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:
+
+- https://dandiarchive.org
+- https://hub.dandiarchive.org
+- https://about.dandiarchive.org
+
+Code git repositories:
+
+- https://github.com/dandi
+
+Data git/git-annex repositories:
+
+- https://github.com/dandisets
+- https://github.com/dandizarrs
+
+## 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](https://github.com/dandi/dandi-archive/blob/master/CODE_OF_CONDUCT.md) 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](https://github.com/dandi/dandi-archive), [dandi-infrastructure](https://github.com/dandi/dandi-infrastructure) |
+| Client | [dandi-cli](https://github.com/dandi/dandi-cli), [dandidav](https://github.com/dandi/dandidav) |
+| Metadata | [dandi-schema](https://github.com/dandi/dandi-schema), [schema](https://github.com/dandi/schema) |
+| JupyterHub | [dandi-hub](https://github.com/dandi/dandi-hub), [nebari](https://github.com/dandi/nebari), [nebari-deployments](https://github.com/dandi/nebari-deployments), [nebari-docker-images](https://github.com/dandi/nebari-docker-images) |
+| Documentation & Support | [dandi-docs](https://github.com/dandi/dandi-docs), [dandi-about](https://github.com/dandi/dandi-about), [helpdesk](https://github.com/dandi/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](https://github.com/dandi/dandi-archive/blob/master/CODE_OF_CONDUCT.md) 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](#63-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](https://github.com/dandi/dandi-archive) | [@dandi/archive-maintainers](https://github.com/orgs/dandi/teams/archive-maintainers) |
+| [dandi/dandi-infrastructure](https://github.com/dandi/dandi-infrastructure) | [@dandi/archive-admin](https://github.com/orgs/dandi/teams/archive-admin) |
+| [dandi/dandi-cli](https://github.com/dandi/dandi-cli) | [@dandi/dandi-cli-maintainers](https://github.com/orgs/dandi/teams/dandi-cli-maintainers) |
+| [dandi/dandi-schema](https://github.com/dandi/dandi-schema) | [@dandi/dandi-schema-maintainers](https://github.com/orgs/dandi/teams/dandi-schema-maintainers) |
+| [dandi/dandi-hub](https://github.com/dandi/dandi-hub) | [@dandi/dandi-hub-maintainers](https://github.com/orgs/dandi/teams/dandi-hub-maintainers) |
+| [dandi/nebari-deployments](https://github.com/dandi/nebari-deployments) (Private) | [@dandi/dandi-hub-maintainers](https://github.com/orgs/dandi/teams/dandi-hub-maintainers) |
+| [dandi/nebari](https://github.com/dandi/nebari) | [@dandi/dandi-hub-maintainers](https://github.com/orgs/dandi/teams/dandi-hub-maintainers) |
+| [dandi/dandidav](https://github.com/dandi/dandidav) | [@dandi/dandi-dav-maintainers](https://github.com/orgs/dandi/teams/dandi-dav-maintainers) |
+| [dandi/dandi-about](https://github.com/dandi/dandi-about) | [@dandi/dandi-docs-maintainers](https://github.com/orgs/dandi/teams/dandi-docs-maintainers) |
+| [dandi/dandi-docs](https://github.com/dandi/dandi-docs) | [@dandi/dandi-docs-maintainers](https://github.com/orgs/dandi/teams/dandi-docs-maintainers) |
+| [dandi/example-notebooks](https://github.com/dandi/example-notebooks) | [@dandi/dandi-docs-maintainers](https://github.com/orgs/dandi/teams/dandi-docs-maintainers) |
+
+### 5.4 Project Leadership
+- Current leadership team:
+    - [Satrajit Ghosh](https://satra.cogitatum.org/) ([@satra](https://github.com/satra))
+    - [Yaroslav O. Halchenko](https://centerforopenneuroscience.org/whoweare) ([@yarikoptic](https://github.com/yarikoptic))
+
+- 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](https://github.com/orgs/dandi/teams) 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](https://drive.google.com/drive/folders/1-jXLpcrh3L650FiZyTFgcs096nZjO2C3).
+
+### 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](https://github.com/dandi/dandi-archive/tree/master/doc).
+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](https://semver.org/spec/v2.0.0.html) for APIs and libraries.
+- Each repository has a release approach that is documented n the table below.
+
+| Repository | Approach | Tagging | Publishing |
+| -- | -- | -- | -- |
+| [dandi-archive](https://github.com/dandi/dandi-archive) | [`auto`](https://github.com/intuit/auto) creates a release upon merge of a `release`-labeled pull request | `v{version}` | [GitHub Release](https://github.com/dandi/dandi-archive/releases) |
+| [dandi-cli](https://github.com/dandi/dandi-cli) | [`auto`](https://github.com/intuit/auto) creates a release upon merge of a `release`-labeled pull request | `{version}` | [GitHub Release](https://github.com/dandi/dandi-cli/releases) + [PyPI](https://pypi.org/project/dandi/) |
+| [dandi-schema](https://github.com/dandi/dandi-schema) | [`auto`](https://github.com/intuit/auto) creates a release upon merge of a `release`-labeled pull request | `{version}` | [GitHub Release](https://github.com/dandi/dandi-schema/releases) + [PyPI](https://pypi.org/project/dandischema/) + [`dandi/schema` release for the JSON schema](https://github.com/dandi/schema/tree/master/releases) |
+| [dandidav](https://github.com/dandi/dandidav) | merge of a `release`-labeled pull request | `v{version}` | [GitHub Release](https://github.com/dandi/dandidav/releases) + https://webdav.dandiarchive.org |
+| [dandi-hub](https://github.com/dandi/dandi-hub), [nebari-deployments](https://github.com/dandi/nebari-deployments) | ad-hoc | - | https://hub.dandiarchive.org |
+| [dandi-docs](https://github.com/dandi/dandi-docs), [dandi-about](https://github.com/dandi/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`](https://github.com/intuit/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
+- Security reports via help@dandiarchive.org.
+- Acknowledge within 48 hours.
+
+### 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
+
+- User and developer documentation is available at https://docs.dandiarchive.org.
+- Design documents for major decisions are available at https://github.com/dandi/dandi-archive/tree/master/doc.
+- DEVELOPMENT.md and CODE_OF_CONDUCT.md are maintained in relevant repositories.
+
+## 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
+
+- Outreach events are hosted in collaboration with the Neurodata Without Borders team and can be found at https://nwb.org/events.
+- Code of Conduct is available at https://github.com/dandi/dandi-archive/blob/master/CODE_OF_CONDUCT.md
+    - Instances of Code of Conduct violation can be reported to community@dandiarchive.org.
+    - Enforcement of Code of Conduct is separate from primary technical decision flow where possible.
+
+## 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.
+
+- Urgent amendments may use an accelerated 7-day window with rationale documented.
+- The document becomes active upon Project Leadership approval and publication in the [DANDI Docs](https://docs.dandiarchive.org/).
+
+## 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](https://www.debian.org/social_contract#guidelines) and [OSI](https://opensource.org/licenses) compliant.

mkdocs.yml

@@ -88,6 +88,7 @@ nav:
   - Terms and Policies:
     - Terms: "terms-policies/terms.md"
     - Policies: "terms-policies/policies.md"
+    - Project Governance: "terms-policies/governance.md"
   - API:
     - DANDI Client: "api/dandi-client.md"
     - REST API: "api/rest-api.md"