# Contributing
> Open individual participation, comment-cycle steps, RFC 2119 and one-sentence-per-line conventions, and implementation reports from Phase 0 onward.
- Repository: g2tf-org/g2tf-standards
- GitHub: https://github.com/g2tf-org/g2tf-standards
- Human docs: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff
- Complete Markdown: https://grok-wiki.com/public/docs/g2tf-org-g2tf-standards-436ba3f3e0ff/llms-full.txt
## Source Files
- `CONTRIBUTING.md`
- `GOVERNANCE.md`
- `NOTICE.md`
- `README.md`
- `rfcs/README.md`
---
---
title: "Contributing"
description: "Open individual participation, comment-cycle steps, RFC 2119 and one-sentence-per-line conventions, and implementation reports from Phase 0 onward."
---
Participation in `g2tf-org/g2tf-standards` is open to individuals. Organizational affiliation is not required and confers no extra standing. The Grid 2.0 Task Force (G2TF) runs the repo with an IETF-style ethos: start small, stay focused; open participation on individual merit; time-limited milestones; get rough consensus, publish, then run.
Work lands on GitHub Discussions, Issues, and pull requests against `specs/`, `members/`, and `architecture/`. Submitting an issue, discussion post, or PR licenses that contribution under CC BY 4.0 so it can be incorporated into G2TF publications with attribution. Any code that appears in the work is Apache-2.0 (`LICENSE-CODE`).
This page is the contributor operating surface. Channel choice, RFC #1 `errata` Issues, two-editor review, and the decision log are also covered on [Comment, review, and file errata](/comment-and-errata). Roles, licenses, and trademarks live on [Governance and licenses](/governance).
## Ethos
| Rule | What it means in this repo |
|---|---|
| Start small, stay focused | Comment and PR against one living file or one open question; do not rewrite RFC #1 |
| Open participation, individual merit | Anyone may raise, review, or implement; standing comes from the contribution |
| Time-limited milestones | The Task Force sets milestone dates; protocol lines use `YY.N` (current: **26.x**) |
| Rough consensus, publish, then run | Editors judge consensus, merge living-spec text, then implementations report back |
## Where work happens
| Channel | Use it for | Do not use it for |
|---|---|---|
| **GitHub Discussions** | Technical questions, design alternatives, implementation reports | Concrete defects or ready spec text |
| **Issues** | Ambiguities, contradictions, missing normative requirements, RFC #1 errata (`errata` label) | Open design exploration |
| **Pull requests** | Proposed text against `specs/`, `members/`, `architecture/` | Edits to published files under `rfcs/` |
| **G2TF WhatsApp Community** | Cross-organization news and policy debate | Normative spec language |
README routes the same three GitHub surfaces: Discussions for questions and alternatives, PRs for spec text, Issues labeled `errata` for RFC #1.
### Discussion categories
Discussions follow the technical open-question areas from RFC #1:
1. **Commercial terms** — enforcement of flexible capabilities, limits on differential service classes, congestion-solving investment decisions, rate-structure impacts.
2. **Reliability assurance** — coincidental load shedding and system stability, materialization of flexibility commitments at scale, compliance incentives.
3. **Engineering** — headroom sufficiency for coincident swings, cybersecurity / NERC CIP, standardization of transmission-owner input signals.
Living specs already point some open items at these categories (for example G2P security maps PKI, NERC CIP, and replay protection to `Discussion: Engineering`).
## Contribution surfaces
:::files
g2tf-standards/
CONTRIBUTING.md # this process
GOVERNANCE.md # roles, lifecycle, decision log
NOTICE.md # CC BY 4.0 / Apache-2.0 contribution terms
specs/
g2p/spec.md # G2P 26.0-draft
gcap/spec.md # GCAP 26.0-draft
desp/spec.md # DESP 26.0-draft
members/
use.md
buffer.md
source.md
allocator.md
architecture/ # normative unless Status: Informative
rfcs/ # immutable snapshots — file errata, do not PR text
:::
`specs/*` and `members/*` are **Draft — seeking input** with **Editors: TBD**. `architecture/design-principles.md` is `Status: Informative`. G2P §7 explicitly invites PRs for wire format, element state machines, version negotiation, and conformance test vectors.
Files under `rfcs/` are immutable archival publications. RFC #1 (`rfcs/grid-2-rfc-1.pdf`, August 2026) is never edited in place. File an Issue labeled `errata` and resolve the correction in the living specs.
## Comment cycle
Open a Discussion for a question or design alternative, or an Issue for a defect (ambiguity, contradiction, missing MUST/SHOULD, or RFC #1 errata).
Editors summarize positions. When a direction has rough consensus, an editor or the proposer opens a PR with spec text against `specs/`, `members/`, or `architecture/`.
PRs against normative documents require review by **two spec editors**. Normative changes MUST use RFC 2119 keywords and MUST state compatibility impact.
Merged decisions are logged in `GOVERNANCE.md` with a one-paragraph rationale and links to the originating thread. The responsible editor judges rough consensus; there is no vote.
Implementations from Phase 0 shadow mode onward report experience in Discussions. Running code informs the next living-spec revision.
Rough consensus means all objections have been considered and either addressed or explicitly overruled with recorded rationale. Sustained objections stay in the decision log even when overruled.
Current decision-log row:
| Date | Decision | Rationale | Thread |
|---|---|---|---|
| 2026-08 | Publish RFC #1; decompose into living specs | Separate immutable narrative from evolving normative text; give the community focused surfaces for comment | — |
## Writing conventions
Apply these rules to new or substantially revised text.
### Normative vs informative
| Kind | How you recognize it | Keyword rule |
|---|---|---|
| Normative | `specs/`, `members/`, and `architecture/` files **not** marked `Status: Informative` | Use **MUST / MUST NOT / SHOULD / SHOULD NOT / MAY** per RFC 2119 / RFC 8174 |
| Informative | Header carries `Status: Informative` | Avoid RFC 2119 keywords |
Normative files open with the RFC 2119 boilerplate already used in G2P, GCAP, DESP, and the member specs:
```markdown
The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be
interpreted as described in RFC 2119 / RFC 8174.
```
### Status header
Every normative file carries one of:
| Header | Meaning |
|---|---|
| `Status: Draft — seeking input` | Current living-spec default |
| `Status: Proposed` | Rough consensus on scope and approach |
| `Status: Stable (vXX.Y)` | Implementable; further changes require a compatibility statement |
Protocol versions use **YY.N** (example: `26.0-draft` on G2P / GCAP / DESP). G2P, GCAP, and DESP version independently. Promotion through Draft → Proposed → Stable → RFC is documented on [Document lifecycle](/document-lifecycle).
### One sentence per line
Prefer one sentence per line in new or substantially revised normative text so Git diffs stay reviewable. Do not reflow an entire file just to match the convention.
### Compatibility statement
Normative PRs must state compatibility impact. After a line is **Stable**, changes require an explicit compatibility statement; the README compatibility matrix is the planned home for cross-protocol drift and is not populated yet.
### Review checklist
Before requesting editor review:
- Target is a living file under `specs/`, `members/`, or `architecture/` — not `rfcs/`.
- Status header is present and accurate.
- RFC 2119 keywords appear only in normative files.
- Compatibility impact is stated in the PR.
- Open items stay marked as open (the living specs use `*(Open: …)*`) unless the PR actually closes them.
- Two spec editors are requested on the PR.
## Implementation reports (Phase 0 onward)
There is no implementation tree, test harness, or report template in this repository. The required feedback path is GitHub Discussions.
Phased adoption in `architecture/design-principles.md` (from RFC #1 §Phased Adoption):
| Phase | Name | What to report |
|---|---|---|
| **Phase 0** | Shadow mode | Commitments exchanged and tracked; execution stays on the Grid 1 baseline |
| **Phase 1** | Local vertical integration | Local host-utility integration experience against the living specs |
| **Phase 2** | Regional federation | Cross-domain announce-and-listen and partition behavior |
File reports under the matching Discussion category (Commercial terms, Reliability assurance, or Engineering). Running-code evidence feeds the next revision; it does not amend RFC #1.
Operational Phase 0 steps live on [Run Phase 0 shadow mode](/phase-0-shadow-mode).
## Licensing and acknowledgment
By submitting an issue, discussion post, or pull request you agree the contribution is licensed **CC BY 4.0** and may be incorporated into G2TF publications. Code that emerges in the work is **Apache-2.0**.
Substantive contributors are acknowledged in subsequent RFC publications, following the acknowledgments section of RFC #1.
"Grid 2.0"™, "G2TF"™, "G2P"™, "GCAP"™, and "DESP"™ are trademarks of the Grid 2.0 Task Force. Neither license grants trademark rights. A trademark usage policy for describing conformant implementations is forthcoming in `GOVERNANCE.md`.
Grid 2 is voluntary and sits inside existing Grid 1 rules. Contributions must not assume the overlay supersedes NERC, FERC, utility, or TSO/ISO requirements.
## Next
Discussions vs Issues vs PRs, the `errata` label, two-editor review, and the decision log.
Draft → Proposed → Stable → RFC, YY.N versions, and required compatibility statements.
Editor, contributor, and Task Force roles; CC BY 4.0 and Apache-2.0; trademarks.
Status headers, RFC 2119 keywords, living files vs immutable RFCs.
Dry-run commitments, Grid 1 baseline execution, then Phase 1 and Phase 2.