Skip to content

README.md

Latest commit

 

History

History
86 lines (65 loc) · 3.54 KB

README.md

File metadata and controls

86 lines (65 loc) · 3.54 KB
Raw

Developer Rules

The org-wide contribution conventions as a rules system: small numbered files that each enforce one checkable behavior.

Rules are grouped by category. Each DEV- rule enforces one behavior and carries acceptance criteria you can check. The Authoring category doubles as the shared standard that any other rules system can adopt.

Categories

Rules are numbered by category: DEV-0xx Authoring, DEV-1xx Contribution model, DEV-2xx Communication, DEV-3xx PR requirements, DEV-4xx Review.

0. Authoring

How to write a rule. These rules define the shape every other rule follows, including their own.

  • DEV-010: enforce one behavior per rule file
  • DEV-020: structure a rule as Problem, Solution, Acceptance Criteria
  • DEV-030: carry the shared rule frontmatter
  • DEV-040: reference a rule by ID as a followable link
  • DEV-050: keep the Problem statement short

1. Contribution model

How work flows from a business aim to a delivered change: Goal, Problem, Solution, Spec.

  • DEV-110: take ownership of a Goal
  • DEV-120: keep the Goal description to the allowed sections
  • DEV-125: write a Spec in the standard format
  • DEV-130: understand and agree the Spec first
  • DEV-140: give an ETA once the goal is clear
  • DEV-150: map every barrier blocking the goal
  • DEV-155: log a bottleneck as a Problem and design it out
  • DEV-160: write a clear Problem statement
  • DEV-170: deliver work as a pull request
  • DEV-180: keep the Spec as unimplemented behavior and graduate it

2. Communication

Where discussion goes and how work is referenced.

  • DEV-210: route discussion to the right channel
  • DEV-220: reference issues and PRs as list items

3. PR requirements

What a pull request must satisfy before it merges.

  • DEV-310: sign every commit
  • DEV-320: scope a PR to a few hours
  • DEV-330: keep docs in sync
  • DEV-335: keep each fact in one canonical place
  • DEV-337: index every docs tree from a README
  • DEV-338: give the repository a complete root README
  • DEV-340: name a PR for what users gain
  • DEV-350: mark a design PR docs(ui) with a Design section
  • DEV-360: open work as a draft PR linked to its Problem
  • DEV-365: mark a PR ready only when it is complete
  • DEV-370: report time across all stages
  • DEV-380: enforce markdown lint on push with a pinned rumdl hook
  • DEV-390: update user-facing docs in the same PR

4. Review

How to review, and the quality bar work is held to.

  • DEV-410: reject with Request Changes for objective problems
  • DEV-415: re-request review explicitly after addressing changes
  • DEV-420: scout open PRs when idle
  • DEV-430: deliver bug-free work; review is a safety check
  • DEV-440: judge work by value delivered, not effort spent

Rule file format

The file format is itself defined by the Authoring rules above: DEV-020 fixes the body shape, DEV-030 the shared frontmatter, and DEV-040 how rules reference each other. A rules system in another repo may add its own frontmatter fields, documented in that repo's own rules index.