Add trailing period based on feedback

Author: kabilar

docs/terms-policies/governance.md

@@ -61,41 +61,41 @@ The DANDI Project codebase includes the components listed in the table below. Mu
 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
+- 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
+- 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
+- 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
+- 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
+- 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
+- Demonstrated sustained contributions and review quality.
+- Nomination and consensus of existing repository Maintainers.
 
 Maintainers for the respective DANDI repositories:
 | Repository | Maintainers |
@@ -118,11 +118,11 @@ Maintainers for the respective DANDI repositories:
     - [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
+    - Approve or amend governance document and Code of Conduct.
+    - Strategic project oversight.
+    - Resolve escalated disputes.
+    - Approve major architectural shifts.
+    - Oversee risk, sustainability, funding alignment.
 
 ## 6. Decision-Making Model
 
@@ -146,108 +146,108 @@ Maintainers for the respective DANDI repositories:
 ## 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)
+- 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)
-- See section below regarding updates to the Governance document
+    - 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).
+- 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
+- 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
+- Follow-up issue required to track remediation.
 
 ## 8. Releases
 
 ### 8.1 Versioning
-- [Semantic Versioning 2.0](https://semver.org/spec/v2.0.0.html) for APIs and libraries
+- [Semantic Versioning 2.0](https://semver.org/spec/v2.0.0.html) for APIs and libraries.
 
 ### 8.2 Release Steps
 - For [dandi-archive](https://github.com/dandi/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`](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
-- For [dandi-cli](https://github.com/dandi/dandi-cli), upon release a new version is published to PyPI
+    - 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](https://github.com/dandi/dandi-cli), upon release a new version is published to PyPI.
 
 ## 9. Security
 
 ### 9.1 Reporting
-- Security reports via [email protected]
-- Acknowledge within 48 hours
+- Security reports via [email protected].
+- 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
+- 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
+- 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
+- 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 ([email protected], [email protected]) for user support
-- Email announcements for critical notifications to users
-- GitHub Releases for release announcements
-- Email newsletter to highlight major changes
+- 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 ([email protected], [email protected]) 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
+- 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  [email protected]
-    - Enforcement of Code of Conduct is separate from primary technical decision flow where possible
+    - Instances of Code of Conduct violation can be reported to  [email protected].
+    - 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
+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
+- 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
+- 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.