Changelog - 2023
Echoes is released continuously, our changelog is therefore an arbitrary month-to-month aggregation of changes.
Echoes automates a lot of work around categorizing engineering efforts. One of these features is the ability for GitHub pull requests and GitLab merge requests to have their labels automatically inherited from the JIRA ticket they reference.
While this is a much appreciated featuure, it was designed with the typical contribution flow in mind, with the ticket being created and labeled first, and the code contributions appearing later. This was sufficient for new users for whom tickets, GitHub pull requests, and GitLab merge requests already exist.
Changing the label on a JIRA ticket will now propagate to all directly and indirectly linked GitHub pull requests and GitLab merge requests. The most notable effect of this change is that it is now possible to ingest weeks of activity into Echoes with very few manuel labeling actions.
This feature will soon be generalized to other integrations (e.g., Linear), and expanded to also propage the new labels to linked issues.
It was previously cumbersome to use Echoes with Linear projects. Linear projects don't carry labels, making it impossible to label a project with the initiative or goal it contributes to, and have Echoes cascade this information to the subtree of issues and contributions.
This new feature allows linking an Initiatives in Echoes to a corresponding project in Linear. All issues within this Linear project will be considered part of this initiative by Echoes. As a result, all GitHub pull requests and GitLab merge requests referencing these issues will be automatically assumed to contribute to the initiative (and automatically labeled accordingly).
Are you a Linear user? Let us know how this new feature feels, and whether you want to see more automatoin in this direction!
We fixed an issue where an event on a previously merged GitHub pull request or GitLab merge request originally labeled with a now archived category (e.g., an archived node or initiative) would appear as untagged in Echoes.
Our GitLab integration was significantly improved with two goals in mind:
- Removing Echoes dependency on GitLab Premium plan (or above).
- Reducing the required token permissions to integrate Echoes with GitLab.
There is no user-visible impact beyond the setup time, where it is now possible to select the subset of projects on which Echoes should be installed.
Echoes used to report the allocation of engineering efforts on completed work items (e.g., merged GitHub pull requests, merged GitLab merge requests, or resolved issues). While this is acceptable for engineering leaders looking for an aggregated overview of how engineering efforts are being spent, this was not good enough for manages of individual contributors looking to steer the activity on a day-to-day basis.
This change introduces the ability for Echoes reports to include ongoing work, such as opened GitHub pull requests and GitLab merge requests, allowing for a lot more reactivity for managers of individual contributors.
- Fixed an issue where a team creation would be rejected when its name conflicts with a previously archived team.
Embedded components allows to exports visual components of Echoes into a third-party platform such as Notion or Confluence.
Embedded components are an early feature: please reach out to [email protected] for feedback or if you'd like to see another platform supported.
Learn more about embedded components.
Among the many responsibilities of an engineering leader is making sure that the workload is sustainable for the team. Echoes now surfaces for each team the heatmap of contribution times across weekdays and hours, highlighting off-hours and weekend work.
This new components can be found in the "Health" tab of a team's page.
Our Shortcut integration was not caught up with all the improvements introduced in the recent months. It is know at the same level of quality than our JIRA and Linear integrations.
Learn more about our integrations.
Echoes supports being installed on GitHub Enteprise Server on-premises deployments. It uses the same GitHub App mechanism and its associated security guarantees. Echoes is also capable of consolidating data across multiple GitHub organizations and instances.
See GitHub Enterprise Server for more information.
Engineering directors overseeing multiple teams want to navigate their reports without going back to the organization's overview. It is now possible to change team from the report itself by clicking on the heading.
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.
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.
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.
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.
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.
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:
The onboarding is redesigned to offer a choice of a preset to use as primary dimension,
- 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.
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.
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.
Together with generalized outcomes, Echoes supports creation additional dimensions from presets inspired by actual usage of the product:
Learn more about dimensions presets.
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.
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".
The main report shows a simplified view of the four DORA metrics:
