MdFlow

Appearance

Governance of the MdFlow Standard ​

This document specifies how the MdFlow Standard evolves after v1.0.

Roles ​

BDFL ​

A single Benevolent Dictator for Life holds final acceptance authority over all changes to the specification. The current BDFL is Alex. The BDFL role is transferable by public announcement in the MdFlow repository; an outgoing BDFL designates the incoming BDFL.

Maintainers ​

A maintainer team of at least one and no more than seven individuals holds commit rights to the MdFlow specification repository. Maintainers:

  • Review proposed changes.
  • Merge non-controversial patches (typo fixes, clarifications not affecting normative meaning).
  • Triage RFCs.
  • Cannot unilaterally accept normative changes; only the BDFL accepts.

Maintainers are appointed by the BDFL and serve at the BDFL's pleasure.

Contributors ​

Anyone may propose changes via the RFC process below. No formal membership is required.

Change classes ​

  1. Editorial. Typos, wording clarifications, broken links. Any maintainer MAY merge. No RFC required. Must not change normative meaning.
  2. Non-normative. Informative appendix updates, reference- implementation additions, example additions. RFC RECOMMENDED but maintainer discretion permits direct merge.
  3. Normative patch. Corrections to vectors or to prose where vectors disagree. RFC REQUIRED. Published as a patch release (1.0.x).
  4. Normative minor. Additions that do not invalidate prior conformance. RFC REQUIRED. Published as a minor release (1.x.0).
  5. Normative major. Breaking changes. RFC REQUIRED with an explicit migration path. Published as a major release (x.0.0).

RFC process ​

An RFC (Request for Comments) is a GitHub issue in the MdFlow repository prefixed with [RFC]. The author MUST include:

  • Title. Concise statement of the change.
  • Motivation. Why the change is needed.
  • Proposed change. Diff or prose of the normative text.
  • Vectors. Proposed new or amended conformance vectors.
  • Back-compat impact. Which conformance classes are affected and how.
  • Alternatives considered. Briefly.

Timeline ​

  • Discussion window. At least 14 days from filing. No RFC is accepted in under 14 days.
  • Extended discussion. The BDFL or any maintainer MAY extend the window once, by up to 30 days.
  • Final call. When discussion has settled, a maintainer posts a [FINAL CALL] comment. Ten additional days follow.
  • Acceptance or rejection. The BDFL posts an [ACCEPTED] or [REJECTED] comment with a one-paragraph rationale.

Implementation ​

Accepted RFCs are implemented by the author or a maintainer as a pull request against the specification. Merge triggers a draft release; the release is tagged on the following Monday.

Vector maintenance ​

New vectors MUST accompany every normative RFC. Vector removals require a separate RFC. Vector ID changes are NOT permitted within a minor version; an erratum corrects the vector's content but not its ID.

Extension specifications ​

Extensions live in packages/spec/src/extensions/. Each extension has its own governance model, declared in its own document. The core specification imposes two requirements on extensions:

  • An extension MUST NOT claim compliance with the core's top-level safety guarantee (§10.1) if it introduces attributes or content that can produce unsafe DOM.
  • An extension MUST NOT overload a tag name in use by another extension without the other's written consent (filed as an issue).

Code of conduct ​

All participation in the MdFlow specification process — RFC authoring, commenting, review — is governed by the project's Code of Conduct, published separately in the repository. Violations are handled by the BDFL and, if applicable, escalated to the relevant hosting platform.

Transparency ​

All RFC discussion happens on the public GitHub repository. Maintainer- only channels for confidential security reports are permitted; security fixes MUST be published with an RFC retrospective after the embargo ends.