# Analytics Ensure all the metrics are configured as mentioned below for the Dev360 module - ## DORA Metrics You can configure DORA metrics (Cycle Time, Deployments, CFR, MTTR), with your specific internal process that may include Draft PRs, enforce correct branches for tracking, and use of Squash/Merge feature for streamlined commit history. For detailed configuration steps, refer to each metric guideline in the links below - #### [Cycle Time](https://help.typoapp.io/typo-help-docs/configurations/cycle-time) #### [Deployment PRs](https://help.typoapp.io/typo-help-docs/configurations/deployment-prs) #### [CFR](https://help.typoapp.io/typo-help-docs/configurations/change-failure-rate-cfr) #### [MTTR](https://help.typoapp.io/typo-help-docs/configurations/mean-time-to-restore-mttr) ## Pull Request Configurations \[To be followed in your Git] #### When Creating a PR 1. **Keep it small**\ PRs should be focused and scoped. Big PR = slow review.\ Aim for one clear purpose - not a feature + refactor + bug fix in one.
2. **Write a clear title + description**\ Explain what the PR does and why. Mention any trade-offs or edge cases.\ Bonus: link to related issues or tickets.
3. **Prefer regular merge over “Squash & Merge”**\ Squashing may make the commit history look clean, but it hides valuable details: 1. You lose the step-by-step progress of the work 2. `git blame` and debugging becomes harder 3. Contributions from multiple developers get flattened **Preferred:** Use regular merges to preserve meaningful commit history\ **Avoid:** Squashing unless it’s a one-off minor fix or explicitly discussed
4. **Group commits logically (if not squashing)**\ Use commits to separate concerns - for example 1. One for implementation 2. One for tests 3. One for cleanup or comments
5. **Mark WIP clearly**\ Not ready for review? Add `[WIP]` or set as a Draft PR. Don’t surprise reviewers.
6. **Add tests (if needed)**\ If you're changing logic, adding tests isn’t optional - it’s a kindness.
7. **Tag the right people**\ Assign reviewers who know the context. Don’t just tag the whole team.
#### When Reviewing a PR 1. **Be kind, not vague**\ “This is confusing” → ❌\ “Could you rename this function to clarify what it does?” → ✅
2. **Review the intent, not just the code**\ Understand why the change was made - not just whether the code “works.”
3. **Ask questions, don’t assume**\ “Why was this approach chosen?” is better than “This is wrong.”
4. **Use suggestions generously**\ Inline GitHub suggestions save time and foster a collaborative feel.
5. **Don’t let perfect block progress**\ If the PR is good enough to ship, ship it. You can always improve later.
6. **Approve or request changes - don’t ghost**\ If you open the PR, close the loop. Don’t leave people hanging.
## Issue Tracker Configurations \[To be followed in your Issue Tracker] Here are some best practices for your Issue tracker project management to fetch accurate data insights into Typo- ### Project Structure #### Issue Types * **Epics**: Large bodies of work that can be broken down * **Stories**: User-focused features or changes * **Tasks**: Technical work items * **Bugs**: Defects requiring fixes #### Components * Organize by functional areas (Frontend, Backend, Infrastructure) * Limit to 5-7 main components * Use labels for more granular categorization ### Workflow States #### Standard Workflow `Backlog → To Do → In Progress → Review/QA → Done` #### Extended Workflow (for larger teams) `Backlog → To Do → In Progress → Code Review → Testing → Ready for Release → Done` #### **Key Points** * Keep states minimal but sufficient * Each state should represent a distinct phase * Avoid creating states for edge cases * Consider adding a "Blocked" flag rather than a blocked state ### Issue Management #### Fields to Maintain * Component * Priority (P1-P4) * Sprint * Story Points * Labels (for filtering) * Epic Link (when applicable) #### Assignment Rules * Assign during sprint planning, not before * One primary assignee per issue * Use watchers for stakeholders * Consider team capacity before assignment ### Developer Assignee Field * Single assignee per issue * Don't assign until sprint planning * Respect team member capacity (WIP limits) * Use watchers for additional stakeholders ### Estimation #### Story Points * Use Fibonacci sequence: 1, 2, 3, 5, 8, 13 * Cap at 13 points - larger items should be broken down * Consider effort, complexity, and uncertainty * Don't assign points to bugs (use priority instead) #### T-Shirt Sizing (Alternative) * Use for initial backlog grooming * XS, S, M, L, XL * Convert to points during sprint planning ### Sprint Organization #### Sprint Setup * Fixed duration (typically 2 weeks) * Consistent sprint names: `YYYY-MM-DD Sprint XX` * Set sprint goals * Maintain velocity tracking #### Sprint Hygiene * Regular backlog grooming (bi-weekly) * Sprint planning meetings * Daily standups using the board * Sprint retrospectives ### PR Linking * Link PRs directly to issues * Use standard naming: `[PROJ-123] Brief description` * Automated status updates via Git integration ## Deployment To set up deployment, you must integrate your CI/CD tool with Typo. Once integrated you can configure the settings using the configure button present on the top right corner. [Here are the detailed guidelines.](https://help.typoapp.io/typo-help-docs/configurations/ci-cd-deployment) ## Resource Allocation #### Setting Up Categories By default, the data shown in investment distribution is based on your issue tracker ticket types. This can be configured as per your requirements. To set this up, use the "configure" button in the top right corner. [Here are the detailed guidelines.](https://help.typoapp.io/typo-help-docs/configurations/investment-distribution) Some commonly used categories by engineering teams are mentioned in the next section. #### Investment Distribution Categories Here are the core resource allocation categories in tech teams: * **Features** * New product development * Enhancements * Growth initiatives * Customer requests * **KTLO** * System maintenance * Critical bugs * Security patches * Production incidents * **Tech Debt** * Refactoring * Architecture improvements * Test coverage * Platform upgrades * **Infrastructure** * DevOps/CI/CD * Developer tooling * Monitoring * Scalability * **Innovation** * Technical spikes * Prototypes * New tech evaluation * Research * **Support** * Customer tickets * Operations * Data management * Compliance ## Custom Reports To create a custom report, navigate to the Custom Report section & click on the Create Report button located at the top right corner of the screen. [Here are the detailed guidelines.](/typo-help-docs/platform/reports.md) ## Incidents To set up incidents, navigate to the incident section and click on the configure button located at the top right corner of the screen. [Here are the detailed guidelines.](https://help.typoapp.io/typo-help-docs/configurations/incident) ## Initiatives To set up incidents, navigate to the initiative section and click on the create button located at the center of the screen. [Here are the detailed guidelines.](/typo-help-docs/configurations/initiative.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://typo.gitbook.io/typo-help-docs/implementation-plan/phase-2-metric-configuration/analytics.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.