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 docid\ xffw j5mh55jdea45lmxs for inspiration categorizing engineering efforts echoes automatically publishes your categories across your product development tools through integrations docid\ n 7mj2ehlg3gio5544lot for example as repository labels on github docid\ sx5k4dytpcgcvkajjzqkj and gitlab docid\ at0ssiisruecp1zlrtqwd , or as options within a custom field on jira docid 894ilvdbdj3sdmgz0hm3i 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