Changelog - 2023
Echoes is released continuously, our changelog is therefore an arbitrary month-to-month aggregation of changes.
May
JIRA plugin permissions update
The Echoes JIRA Connect App now requires WRITE permissions in order to support some of the features added this month. Please check your JIRA instance to approve this new scope.
JIRA tickets tags inheritance
GitHub pull requests and GitLab merge requests historically inherit their labels from a linked JIRA ticket and all of its ancestors. This commodity exists to avoid categorizing items twice. JIRA tickets themselves however would never have their "Echoes - Intent" field be automatically set, even when part of a tagged EPIC.
JIRA tickets now inherit the value of the "Echoes - Intent" from their ancestor tickets. This action happens automatically in two scenarios:
- When a new ticket is filed and has a parent.
- When an existing ticket is updated to be linked to a parent.
This change requires an updated set of permissions for the Echoes JIRA integration. Please check your JIRA instance for approval.
JIRA handling of archived nodes and initiatives
When a node or initiative gets archived, it disappears from all integrations (e.g., from GitHub repository labels, and from the JIRA custom field). In the case of JIRA, this would cause past recorded efforts to lose their association with this archived entity.
The behavior to remove the corresponding value of the JIRA custom field upon archival was preserved, but previously recorded efforts now remain unmodified by this action.
April
Enforce effort labels on GitHub pull request
The builtin GitHub check allows to optionally validate the presence of Echoes labels on pull requests. This feature is commonly used to reduce the share of untagged work making it into main. This check did not previously enforce the presence of an "Effort" label, as Echoes naturally defaults to the value M.
Some teams aim for the highest possible level of data quality, and that includes putting an accurate weight on pull requests. Therefore it is now possible to enforce the presence of an "Effort" label on a team-per-team basis in their settings.
When that second toggle is enabled, pull requests without an echoes/effort label will be marked as failed. As before, pull requests lacking a label for the primary dimension, or having multiple labels for dimensions that do not allow it, will continue being marked as failed.
March
Builtin tagger
The builtin tagger is improved in several ways
- It is multi-dimensions capable, which means that it can add tags across multiple dimensions.
- It is restricted to labels that already exist, which means that it won't offer to tag a work item with labels that wouldn't have yet been created at the destination (e.g., a particular GitHub repository). This is notably important in the context of public repositories and scoped publication, where some labels may be deliberately excluded from some destinations.
GitHub pull request checks
The builtin GitHub check that validates the presence of labels on pull requests is now multi-dimensions aware and offers a better user feedback on failure:
New onboarding experience
The onboarding is redesigned to offer a choice of a preset to use as primary dimension,
Improvements and bugfixes
- The general performance of the application was improved to accommodate organizations with over 500 repositories and 100k pull requests.
- The trajectory table now preserves the expanded state of its rows when data is refreshed.
February
Generalized outcomes
Outcomes in Echoes were initially designed to capture the intended outcome of engineering efforts. But our users leverage the flexibility of the configuration to model arbitrary categories: type of work (e.g., "bug", "feature"), company goal contributed to, and more.
Echoes now embraces this variety of use cases by generalizing outcomes into arbitrary user-defined dimensions. Not only can you rename the default "intent" dimension to anything more appropriate to your use case, you can know create additional dimensions to categorize work across more than a single axis.
A bonus side-effect of this development is that it makes the impediments dimension customizable, which was previously not possible.
Learn more about dimensions.
Generalized initiatives
Initiatives in Echoes are commonly used to model projects or sizable features. In the past, initiatives would force you to determine a composition at its creation (e.g., "80% throughput", "20% risk mitigation"). This was an issue for users who categorize efforts across the type of work (e.g., "bug", "feature"), and for whom the composition was impossible to know beforehand.
Initiatives are now redefined as named areas of work which contain an optional set of common attributes that apply to all efforts within this scope. This makes it possible to create an initiative without any common attributes, and later examine the distribution of work within this initiative.
Learn more about initiatives.
Dimensions presets
Together with generalized outcomes, Echoes supports creation additional dimensions from presets inspired by actual usage of the product:
Learn more about dimensions presets.
Label publication
The mechanism underlying the creation of labels and custom fields across integrations (i.e., GitHub, GitLab, JIRA, Linear) is now more resilient to renames and conflicts. Those changes open the door to offering more customization of label naming (for example dropping the echoes/ prefix): please reach out if this is something you'd be interested to see next.
January
Properly handle reopened tickets
Echoes properly handles tickets (e.g., JIRA, Linear, Shortcut) being reopened after having been completed at some point. When a ticket is reopened, it disappears from the list of "Completed" items and appears back into "Inflight".
DORA metrics on the main report
The main report shows a simplified view of the four DORA metrics:
