Draft: Docs/governance

.github/RFC_TEMPLATE.md

@@ -0,0 +1,109 @@
+# RFC Template
+
+- **Status**: Idea | Draft | Accepted | Rejected | Revision Requested
+- **Author(s)**: <name / handle>
+- **Champion**:
+- **Created**:
+- **Last Updated**:
+- **Related**:
+
+---
+
+## 1) Summary (2–5 sentences)
+
+What is being proposed and why? Keep this understandable to non-specialists.
+
+---
+
+## 2) Problem & Motivation
+
+- What problem are we solving?
+- Who is affected?
+
+---
+
+## 3) Goals & Non-Goals
+
+### Goals
+
+What outcomes should this RFC achieve?
+
+- …
+- …
+
+### Non-Goals
+
+What is explicitly out of scope for this RFC?
+
+- …
+- …
+
+---
+
+## 4) Proposed Approach (High-level)
+
+Describe the proposed approach at a level suitable for review:
+
+- Key idea(s)
+- Expected behavior changes (if any)
+- Any public API changes (if any)
+
+---
+
+## 5) Trade-offs & Alternatives
+
+### Trade-offs
+
+What are the downsides or costs of the proposed approach?
+
+### Alternatives
+
+What alternative approaches were considered, and why were they not chosen?
+
+---
+
+## 6) Impact
+
+### Compatibility
+
+Are there breaking changes? Is migration required?
+
+### Performance
+
+Any expected performance impact?
+
+### Security / Privacy
+
+Any security or privacy implications?
+
+### Maintenance
+
+Expected long-term maintenance cost or complexity.
+
+---
+
+## 7) Open Questions
+
+- …
+- …
+
+---
+
+## (Optional) Implementation Notes
+
+Only include if it helps reviewers:
+
+- rollout/migration sketch
+- testing strategy
+- rough milestones
+
+---
+
+## Decision (TSC)
+
+Filled in by the TSC when decided.
+
+- **Decision**: Accepted | Rejected | Revision Requested
+- **Rationale**:
+- **Date**:
+- **Recorded by**:

BUGS.md

@@ -0,0 +1,151 @@
+# Bug Reporting & Triage
+
+This document explains how bugs are reported, triaged, and resolved in the project.
+
+The goal is to:
+
+- Make it easy for users to report issues
+- Ensure bugs are handled consistently and transparently
+- Keep technical decision-making with maintainers while enabling support from Product and the community
+
+---
+
+## What Is a Bug?
+
+A bug is behavior that:
+
+- Is incorrect or broken compared to documented or intended behavior
+- Regresses previously working functionality
+- Causes crashes, data loss, or security issues
+
+Requests for new features or behavior changes are NOT bugs and should be raised as ideas or proposals instead.
+
+---
+
+## Reporting a Bug
+
+Anyone may report a bug.
+
+Please open a GitHub Issue and select 'Bug Report'. The template provided will require:
+
+- A clear description of the problem
+- Steps to reproduce (if possible)
+- Expected vs actual behavior
+- Environment details (browser, OS, version, framework, etc.)
+
+If you are unsure whether something is a bug, opening an issue is still fine — maintainers will help triage it.
+
+---
+
+## Bug Triage
+
+Bug triage is the process of classifying and prioritizing reported bugs.
+
+### Responsibility
+
+- **Maintainers** are responsible for technical triage and classification
+- **Product** may facilitate triage sessions, provide user-impact context, and help with communication
+- **Contributors** may assist by reproducing issues or providing additional context
+
+---
+
+### Classification
+
+Maintainers classify bugs based on technical severity.
+
+Severity reflects technical correctness and safety impact, not business priority or operational uptime.
+
+Severity levels:
+
+- **P0 – Critical**: *Unsafe or invalid to use as-is.* Crashes, data loss, security issues, or violations of documented invariants. Users cannot safely rely on the library.
+- **P1 – High**: *Safe but seriously impaired.* Core functionality is broken or severely degraded. The library can still be used with limitations or workarounds.
+- **P2 – Medium**: *Correct but inconvenient.* Partial breakage or confusing behavior with reasonable workarounds available.
+- **P3 – Low**: *Annoying but non-blocking.* Minor issues or cosmetic bugs that do not affect correctness or core functionality.
+
+---
+
+## Bug Lifecycle
+
+Bugs typically move through the following stages. Not all bugs go through every stage, and the process may vary depending on severity and complexity.
+
+1. **Reported**
+
+    A bug is reported as a GitHub Issue by a user or contributor.
+
+2. **Triaged**
+
+    Maintainers review the issue to confirm it is a bug, request additional information if needed, and classify severity.
+
+3. **Investigated**
+
+    The issue is analyzed further. This may include reproducing the bug, identifying root causes, and discussing possible fixes or trade-offs.
+
+4. **Resolved**
+
+    A fix is implemented and reviewed via a pull request, or a decision is made not to change behavior (for example, if the behavior is working as intended).
+
+5. **Closed**
+
+    The issue is closed once resolved, deemed invalid, or no longer actionable. Closure should include a brief explanation whenever possible.
+
+
+High-severity bugs (P0/P1) may skip stages or be addressed immediately.
+
+---
+
+## Fixing Bugs
+
+- Bugs are fixed through the normal pull request process
+- Anyone may submit a fix
+- Maintainers review and approve fixes
+
+High-severity bugs may be addressed immediately, regardless of roadmap priorities.
+
+---
+
+## Prioritization
+
+While maintainers determine technical severity, Product may:
+
+- Help prioritize bugs relative to other work
+- Balance bug fixing with feature development
+- Communicate expectations to users and stakeholders
+
+Bug prioritization does not override maintainer judgment on severity or correctness.
+
+---
+
+## When a Bug Becomes an RFC
+
+If fixing a bug:
+
+- Requires changing core behavior
+- Introduces breaking changes
+- Sets new long-term precedent
+
+Then the fix may require an RFC.
+
+See [RFC_PROCESS.md](/RFC_PROCESS.md) and [How Work Flows](/HOW_WORK_FLOWS.md) for guidance.
+
+---
+
+## Stale or Invalid Bugs
+
+Issues may be closed if:
+
+- The issue cannot be reproduced
+- Required information is missing and no response is received
+- The behavior is working as intended
+
+
+> Closure should include a brief explanation.
+
+
+---
+
+## Guiding Principles
+
+- Bugs are treated seriously and respectfully
+- Technical correctness comes before speed
+- Transparency is preferred over silence
+- When in doubt, discuss openly

CODE_OF_CONDUCT.md

@@ -0,0 +1,47 @@
+# Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to make participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others’ private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies within all project spaces, and it also applies when an individual is representing the project or its community in public spaces. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [team@blocknotejs.org](mailto:team@blocknotejs.org).
+
+All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the **Contributor Covenant**, version 1.4, available at: https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+For answers to common questions about this code of conduct, see: https://www.contributor-covenant.org/faq