Skip to content

Latest commit

 

History

History
37 lines (30 loc) · 4 KB

README.md

File metadata and controls

37 lines (30 loc) · 4 KB

Developer

Forward-looking material for people building the DIN Protocol: plans, designs, proposals, contributor process, and work tracking.

Scope rule: documents here describe what we plan, propose, decide, or how we work — they stay valid even as the code changes. Documentation of what currently exists on develop lives in Documentation/ instead (public/ for participants, technical/ for people modifying the code).

Layout

Location Contents
ROADMAP.md Active phase plans (P3–P4) and the full work-package table with owners, dependencies, and status
UP_LOG.md Completed phases moved out of ROADMAP.md once fully shipped (currently: P2)
BACK_LOG.md Unscheduled / not-yet-phased items awaiting triage into a ROADMAP.md work package
design/ Target designs not yet (fully) implemented: system architecture, DevNet 2.0 mechanism design, P3 design plan (coordination page for the P3 mechanism-design push), tokenomics design, staking design, white paper summary, production staking/slashing spec, feasibility report, design decisions log (cross-cutting decision tracker, started with DIN-DAO)
issues/ Backlog of design/implementation write-ups per mechanism or feature (some with design.md / implementation.md / simulation.md subdocs)
proposals/ Tooling proposals — tools that don't exist yet (client labeling, model-owner contract/service builders)
tasks/ Contributor task specs (task_DDMMYY_n.md)
tasks-plan/ Per-contributor task plans pending maintainer review (tasks-plan/<github-user>/task-plan-DDMMYY-n.md); approved items are forwarded into tasks/ specs
discussion/ Open discussions (Filecoin support, Foundry migration)
rejected-ideas/ Ideas evaluated and rejected, with rationale (e.g. TKNN-Shapley)
CONTRIBUTING.md Contribution process and code standards pointers
MAINTAINING.md Maintainer process: peer review, merging, issue/task approval and closure, what GitHub enforces
partner-outreach-checklist.md Conversation checklist for potential DIN partners, with an open question on shared outreach tracking
CODE_STANDARDS.md Code style and quality expectations
DEVELOPMENT_SETUP.md Setting up a development environment
GOOD_FIRST_ISSUES.md Curated starter tasks for new contributors

Where does a new document go?

  1. Describes code that exists on develop? → Documentation/ (never here). Participant-facing → Documentation/public/; for code readers/auditors → Documentation/technical/.
  2. A design or spec for something not built yet? → design/ (protocol mechanisms) or proposals/ (tooling).
  3. A backlog item someone could pick up? → issues/.
  4. A scoped task for a specific contributor? → tasks/. A contributor's proposed batch of tasks, still awaiting maintainer review? → tasks-plan/<github-user>/; once approved, its items become tasks/ specs.
  5. An open question or debate? → discussion/. A decision not to do something → rejected-ideas/.

Graduation rule: when a design from design/ or issues/ ships, don't move the document — write (or update) the current-state description in Documentation/technical/ and mark the design here as shipped with a pointer. The design doc remains as the record of intent; Documentation/ records reality. (Example: issues/staking-mechanism.md → Documentation/technical/mechanisms/staking-mechanism.md.)