Dojo Feature
A feature that exists in narrative before it exists in reality.
A Dojo Feature is a declared capability that is discussed, planned, demonstrated, and referenced long before—or instead of—being fully implemented. Its primary value lies in roadmap presence, presentation slides, and stakeholder alignment rather than actual usage.
Key characteristics:
- Frequently mentioned, rarely completed
- Exists as demos, mocks, or feature flags
- Considered “in progress” indefinitely
- Used to signal momentum rather than deliver value
Next-Gen Synergy Platform
v2.0 (Alpha-Ready)Dojo Requirement
A requirement designed to exist, not to be fulfilled.
A Dojo Requirement is a formally stated need that is intentionally vague, expandable, or internally flexible. It enables continuous discussion and reinterpretation while preventing definitive completion. Its purpose is to sustain process, not guide execution.
Key characteristics:
- Ambiguous and open to interpretation
- Meaning shifts without wording changes
- Generates clarification cycles instead of decisions
- Considered “addressed” through documentation or discussion
Requirement ID: #DOJO-777
The solution must provide robust interactions that leverage synergistic data points to enhance user value.
Requirement ID: #DOJO-888
Add new Column with name Status to the table to see more info.
Dojo Acceptance Criteria
Criteria that validate agreement, not completion.
Dojo Acceptance Criteria define when a feature or task is considered acceptable without requiring it to be complete, correct, or usable. They focus on alignment, acknowledgment, or presentation rather than measurable outcomes.
Key characteristics:
- High-level and non-verifiable
- Satisfied through review or consensus
- Rarely testable in practice
- Used to close items without finishing them
- Stakeholders aligned
- "Look and feel" is correct
- No obvious blockers
Dojo Checkbox
A UI element that never behaves as expected.
A Dojo Checkbox is a UI element whose behavior is fundamentally unstable. Any attempt to fix it inevitably breaks another, previously working part of the system related to the checkbox. Over time, it becomes untouchable—surrounded by warnings, comments, tickets, and meetings—and is ultimately accepted as “working by design.”
Key characteristics:
- Fixing it causes regressions elsewhere
- Ownership is unclear, historical, or disputed
- Becomes a permanent discussion topic
- Eventually excluded from real use but kept for appearance
Dojo Document
Documentation that exists purely to be pointed at.
A Dojo Document exists not to explain, but to deflect. It serves as a shield against requests for clarity and accountability. The document typically contains circular references, outdated diagrams, and “Coming Soon” placeholders in the most critical sections—ensuring it is never truly actionable.
Key characteristics:
- Exists primarily to be referenced, not read
- Contains circular references and obsolete visuals
- Critical sections marked as “TBD” or “Coming Soon”
- Deflects questions rather than answering them
(To Be Delegated)
(To Be Defined)
Dojo Commit
A commit made today so it can be discussed, reverted, or removed tomorrow.
A Dojo Commit is created with a single purpose: to justify a future follow-up comment or commit that removes or reverts it. Typically minimal in scope—often a one-line change or comment—it demonstrates activity rather than delivering lasting value.
Key characteristics:
- Intentionally temporary
- Low-impact or cosmetic change
- Designed to invite future discussion or cleanup
- Serves visibility rather than functionality
Dojo Refactoring
Change without improvement.
A Dojo Refactoring reorganizes code, structure, or documentation without improving functionality, performance, or maintainability in any measurable way. Its primary function is to signal technical diligence, reset conversations, and justify future work—while leaving core problems untouched.
Key characteristics:
- Changes structure, not behavior
- Generates discussion without resolution
- Often repeated in cycles
- Defers real fixes under the appearance of progress
Before
After
Dojo Hotfix
A fast fix that restores confidence, not correctness.
A Dojo Hotfix is an urgent change applied to resolve a highly visible issue while deliberately ignoring the root cause. It restores surface stability just long enough to satisfy stakeholders, with the unspoken agreement that a “proper fix” will be discussed later—usually indefinitely.
Key characteristics:
- Fixes symptoms, not causes
- Implemented under time pressure
- Restores temporary surface stability
- Leaves underlying issues intact
- Introduces future instability