Wiki » History » Revision 2
Revision 1 (rashmita rout, 12/23/2025 05:26 PM) → Revision 2/4 (Redmine Admin, 12/26/2025 03:27 PM)
h1. Tinggit Platform Wiki – Operating & Knowledge Hub *This page is the authoritative entry point for how Tinggit plans, builds, ships, governs, and evolves its products.* {{toc}} --- h2. 1. Purpose of This Wiki The Tinggit Platform Wiki serves as the **single source of truth** for: * How work is executed (process & delivery) * How decisions are made and remembered * How quality, compliance, and risk are managed * How engineering standards are applied * Why product and business choices exist This wiki exists to: * Enable consistent execution * Preserve organizational memory * Support audits and compliance * Scale teams without losing clarity *bq.* If something is not documented here, it is not part of the official operating model. --- h2. 2. How to Use This Wiki Different audiences should use this wiki differently: |_. Role |_. Start Here | | Product Owners | Role-Based Guides → Product Owner Training Guide | | Engineers | Role-Based Guides → Sprint Team Training Guide | | QA / Compliance | Role-Based Guides → QA & Compliance Training Guide | | Leadership | Product & Business + Metrics & Audit | | New Joiners | How We Work at Tinggit | If multiple pages appear related, always follow the **hierarchy defined below**. --- h2. 3. Wiki Structure & Governance Model This wiki is organized into **six controlled sections**. Each section has a clear purpose and strict boundaries. --- h2. 4. Delivery & Process (Authoritative) This section defines *how work must be done*. These pages are **rules**, not suggestions. * [[Product Process Guidelines]] * [[Sprint Open Process]] * [[Sprint Execution Rules]] * [[Sprint Close Process]] * [[Sprint History, Metrics & Audit]] * [[Release Management Process]] * [[Edge Case & Exception Handling]] Rules: * These pages override all others * They must not be duplicated * Changes require review --- h2. 5. Role-Based Guides (Usage & Training) This section explains *how to apply the process* in day-to-day work. These pages: * Explain actions * Do not define rules * Always link back to authoritative process pages * [[Product Owner Training Guide]] * [[Sprint Team Training Guide]] * [[QA & Compliance Training Guide]] --- h2. 6. Product & Business Context This section captures *what* we are building and *why*. It provides long-term context and decision alignment. * [[Tingg Insight Business Requirements Document]] * [[Tingg Insight HIPAA Compliance Scope & Applicability]] * Product Vision & Goals *(to be added)* * Product Roadmap (High-Level) *(to be added)* Rules: * These pages do not track execution * They do not replace backlog items * They provide intent, not commitments --- h2. 7. Engineering Standards This section defines **technical and architectural expectations**. These pages describe: * Standards * Principles * Non-negotiable practices They do NOT contain: * Tutorials * Temporary implementation notes * Sprint-specific instructions Recommended pages: * Coding Standards * Architecture Principles * API & Integration Guidelines * Security & Compliance Practices * Branching & PR Guidelines --- h2. 8. Decision, Risk & Opportunity Register This section preserves **strategic memory**. It answers: * Why a decision was made * What risks were accepted * What opportunities were identified Recommended pages: * Key Decisions (ADR-style, lightweight) * Risk Register * Opportunity Register These pages prevent: * Repeating past mistakes * Hindsight bias * Loss of context during growth --- h2. 9. Reference & Supporting Material This section contains stable reference information. Examples: * Glossary * External documentation links * Tooling references Rules: * No process definitions * No operational rules --- h2. 10. Governance Rules (Mandatory) To keep this wiki effective: * No new process pages without review * No duplication of authoritative content * Sprint- or release-specific notes must not live here * Temporary information belongs in issues, not wiki Violations lead to confusion and loss of trust. --- h2. 11. Change Management Changes to this wiki must: * Be intentional * Be reviewed * Preserve history * Avoid rewriting the past This ensures: * Auditability * Stability * Long-term usefulness --- h2. 12. Final Statement *bq.* This wiki is not documentation for documentation’s sake. It is the **operating system of the Tinggit Platform** — designed to scale people, products, and decisions without chaos. Start here. Follow the structure. Do not improvise. Test