Categories
Categories defines how engineering efforts are categorized in your organization. They are tree that can be an entirely configurable to map to your particular context.
The default suggests to categorize engineering efforts according to the intended outcome motivating the change.
- Customer value: end-user visible changes intended to create customer value. For example: features development, as well as fixes for bugs hurting the user experience.
- Maintenance: changes intended at preserving our ability to evolve the software safely and effectively. For example: changes meant to improve developer experience, automate releases, or pay off technical debt.
- Risk mitigation: changes intended at mitigating risks. For example: changes related to security (such as upgrading a vulnerable dependency) or compliance.
This is a starting point which applies to pretty much any organization out there, and it's perfectly fine to stick with that! However, you may want to take it further, for example looking through our configuration guides for inspiration.
Echoes automatically publishes your categories across your product development tools through integrations: for example as repository labels on GitHub and GitLab, or as options within a custom field on JIRA.
This gives you a standardize to categorize efforts across the board, regardless how teams are organized locally. Echoes collects categorized activity data to produce reports and give you insights into your engineering's organization.
As a general rule, Echoes uses GitHub pull requests and GitLab merge requests as its primary source of truth for engineering efforts. However, Echoes gives flexibility in how efforts are to be categorized: this is a choice that belongs to each individual team based on the processes that makes them most effective.
- One team may be extremely rigorous in their use of JIRA and will preferably tag work items there. In this case, their code contributions will be categorized automatically through their links to JIRA EPIC, issues, and tasks.
- Another team may be experimenting with Linear, and will chose to tag the work there.
- Finally, one team may be operating effectively without tickets, and will chose to label their pull requests directly on GitHub.