JIRA

purpose echoes can connect to your jira cloud instance and help you tag jira issues with their intended outcomes and initiatives they contribute to this allows you to express the purpose of work during the planning process in jira and have related code contributions inherit these annotations, therefore reducing the labelling effort for engineers in the example above, a pull request references jira sub task jira 3 in its title echoes successively inspects jira 3 , its parent story jira 2 , and the parent epic jira 1 , collecting all values of the intent field along the path it finds an intent on the epic and applies the corresponding label to the pull request this required a single tag in jira, and no developer action installation and configuration echoes jira integration consists of an atlassian connect app which only requires read permissions to your jira instance installation is done through https //app echoeshq com/admin/integrations/ the connect button asks for the base url of your jira instance (e g , https //mycompany atlassian net ) and take you to the installation page on the jira marketplace once installed, you will see custom fields appear on your jira instance (you can filter fields on "echoes" to find them easily) the custom fields must be manually added to screens! echoes creates the " echoes intent " and " echoes effort " custom fields on your jira instance but doesn’t add them to any screens by default in order to leave this decision up to the jira administrator follow the https //support atlassian com/jira cloud administration/docs/add a custom field to a screen/ to add the custom fields to the screens of your choice enforcing categorization the " echoes intent " custom field can be made required on issues to enforce categorization refer to jira https //support atlassian com/jira cloud administration/docs/manage issue field configurations/ documentation to mark the field as required how to use once connected to your jira cloud instance, echoes creates and manages two custom fields the "echoes intent" multi select field is populated with the outcomes and initiatives configured in echoes, and is automatically updated as the configuration changes over time the "echoes effort" single select field is populated with a simple t shirt size scale automating code contributions labeling the "echoes intent" field is used to express the intended outcomes or initiative motivating a jira issue (either task, story, or epic) opening a github pull request or gitlab merge request which https //support atlassian com/jira software cloud/docs/reference issues in your development work/ (either in the pull request title, the message headline of one of its commits, or the branch name) will automatically apply labels for the corresponding intents without any action from the author labeling behavior details labels are automatically applied when a github pull request (or gitlab merge request) is opened , edited , or reopened , and doesn't have echoes labels yet this is the nominal case, where the creation of a ticket predates the creation of a code contribution, and that contribution references the ticket it resolves when the "echoes intent" custom field is updated on a jira ticket, echoes automatically applies the corresponding labels to all (directly or indirectly) linked pull requests which aren't already labeled this is most useful in the context of a new echoes installation labeling a few epics can be enough to automatically categorize hundreds or linked already existing pull requests to minimize confusion, echoes never overrides labels previously set on a pull request for the same reason, echoes may only add or remove more labels if previously existing labels on a pull request match thoses on the jira ticket accounting for non coding activity you may want to account in echoes for efforts which contribute to goals but don't materialize as contributions in the source code manager for example, this could be an engineer spending one day investating a production issue, or provisioning resources in your cloud provider this is the purpose of the "echoes effort" custom field when an issue gets resolved, echoes accounts for the effort as set in "echoes effort" this field is empty by default, which means that jira issues are generally only accounted for through efforts arising from linked github pull requests and gitlab merged requests attributing a non zero value to the "echoes effort" custom field will confer the issue a weight of its own, using the same t shirt size scale used for pull requests and merge requests usage of the completion field on jira in addition to the above configuration, to make the best use of echoes, we recommend that you follow https //confluence atlassian com/cloudkb/best practices on using the resolution field 968660796 html regarding the usage of the "completion field" on your jira issues echoes uses the completion field as primary source of information to evaluate whether a jira issue is considered "open", or "closed" faq are jira issues' parent or epic links followed? echoes follows both the “epic link” and "parent" fields a github pull request which references a jira issue will get automatically labeled with all tags carried by the issue, its parent (if any), and its epic (if any) what is the purpose of the "echoes effort" field? the "echoes effort" custom field allows to attribute a non zero effort to a jira ticket a ticket doesn't contribute to echoes reported efforts by default the reason for this is that echoes measures effort from github pull requests and gitlab merge requests, and considers tickets to be a description of efforts rather than efforts themselves there are however cases where engineers spend efforts on tasks which do not lead to changes in github or gitlab (e g , investigating a production issue, or working on architecture plans) when such tasks exist as jira tickets, setting a non empty value for the "echoes effort" field allows to account for these efforts