Governance

Q+ Language is an open-source project maintained by 如东星瀚科技有限公司 (Rudong Xinghan Technology Co., Ltd.), brand 星瀚 / Xinghan. This document explains how decisions are made, who owns the project, and how releases and versioning work. It is a release-preparation document: it does not announce a published release, and v1.21.0-dev remains a release candidate (NOT PUBLISHED).

1. Ownership and scope

Maintainer: 如东星瀚科技有限公司 (the "Maintainer") holds final decision authority over the project, its name, licensing, repository hosting, releases, and brand.
Maintainers: trusted contributors responsible for review, merging, tests, documentation, security triage, and release engineering within delegated areas. The current role list is in MAINTAINERS.md.
Scope: this repository is the language only — compiler (qboot), bytecode VM (bqvm), standard library, examples, tests, specification, tooling, editor components, and documentation. The 另一产品线 kernel and OS services are a separate closed-source product line and are not part of this repository. OS SDK work in this repository is an external prototype (docs/OS_SDK_DESIGN.md); it is not a supported release runtime.

2. Decision model

Lazy consensus. Most changes proceed by pull request with at least one maintainer approval and green CI. Silence is not approval; explicit review is required for merges.
Issue first for large changes. Language semantics changes, new standard-library modules, compilation-strategy changes, release-process changes, and new public interfaces require an issue/design discussion before implementation. Significant decisions are recorded in the ADR-style documents under docs/ (for example docs/OS_SDK_DESIGN.md, docs/MACROS.md, docs/CONCURRENCY.md, docs/ASYNC_PHASE2.md).
Maintainer escalation. If maintainers disagree or a change affects compatibility, security, or release scope, the decision escalates to the Maintainer.
Maintainer decisions. The Maintainer decides: publication approval, licence and copyright, repository/org naming, release tagging/upload, Marketplace or registry actions, commercial support, and anything that creates a public commitment.
Security decisions follow SECURITY.md; do not discuss active vulnerabilities in public issues before coordination.
Conduct decisions follow CODE_OF_CONDUCT.md.

3. Roles

Role	Responsibilities	Assignment
Maintainer	Final authority; legal/licensing/brand; release authorization	如东星瀚科技有限公司 (placeholder, see `MAINTAINERS.md`)
Release manager	Candidate freeze, gates, pack assembly, release notes	Maintainer appointed by the Maintainer for a release cycle
Maintainer	Review, merge, tests, docs, area ownership	See `MAINTAINERS.md`
Reviewer / contributor	Pull requests, reviews, issue triage	Any contributor in good standing
Security responder	Private vulnerability intake and coordination	Maintainers appointed by the Maintainer

Maintainers are added/removed by Maintainer decision after maintainer consultation. All maintainers are expected to follow the Code of Conduct and the DCO sign-off requirement in CONTRIBUTING.en.md.

4. Release and version policy

Language versions use a development-line format (MAJOR.MINOR.PATCH-dev) plus a separate specification version (v4.x). The specification is the normative reference for language behavior.
Release candidates: development lines are candidates only. A candidate is NOT PUBLISHED until the Maintainer explicitly authorizes publication and the release runbook in RELEASING.md is completed.
Version labels are not marketing claims. 1.21.0-dev, v4.34, and similar labels describe the development line and specification snapshot; they do not mean a public release exists.
Historical packages are immutable. Once frozen, a candidate package is never repacked or modified. The v1.1 release candidate is deprecated (AOT large-i64 silent-miscompile defect, fixed in later lines); v1.2 is the compatibility baseline; 1.3, 1.4.0, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7 and 1.4.8 are candidates, NOT PUBLISHED.
Specification changes require a corresponding history/version update in docs/qplus_language_spec.md and tests/regression fixtures for new behavior.
Deprecation policy: a feature is deprecated by documentation first, then by a loud diagnostic/compile error in a later development line; silent behavior changes are avoided. The current known non-claims and boundaries are listed in ROADMAP.md and the release checklist.

5. Contribution, licensing, and conduct

Contributions are accepted under the Apache License 2.0 and require a Developer Certificate of Origin (DCO) sign-off (git commit -s). See CONTRIBUTING.en.md.
No contributor licence agreement (CLA) is currently required.
Community participation is covered by CODE_OF_CONDUCT.md.
Security issues must be reported privately per SECURITY.md.
Questions about governance or this document: open a GitHub issue/discussion, or contact the Maintainer through the channel listed in SUPPORT.md.

6. Changes to this document

Changes to this governance document require maintainer review and Maintainer approval, and must be recorded in the pull request description. This document does not override the Apache License 2.0 or any applicable law.