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
developlives inDocumentation/instead (public/for participants,technical/for people modifying the code).
| 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 |
- Describes code that exists on
develop? →Documentation/(never here). Participant-facing →Documentation/public/; for code readers/auditors →Documentation/technical/. - A design or spec for something not built yet? →
design/(protocol mechanisms) orproposals/(tooling). - A backlog item someone could pick up? →
issues/. - 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 becometasks/specs. - 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.)