Echoes lets you express the purpose and challenges of your day-to-day work, directly from your development platforms of choice. This data is surfaced into dashboard which shine a light on your work and help management create the best possible conditions for you to suceed.
We surface no individualized data, no performance metrics, no scores. The goal is to help organizations set clearer goals, improve focus, and offer a better context overall for engineers to deliver their best work. This starts by giving managers an accurate understanding of the reality of the teams.
TL;DR: use the labels prefixed with echoes/ to add context to your pull requests. That's all! No need for additional tickets, time-tracking, or switching to a different tool.
These labels are centrally defined in Echoes to represent what matters to your organization, and Echoes keeps them in sync across all of your repositories so you don't have to.
- echoes/intent labels express why the pull request exists.
- echoes/initiative labels express to what initiative (e.g., feature, or project) the pull request contributes to.
- echoes/effort labels express how much effort when into the pull request (M being the default, which corresponds to the average pull request for your team).
- echoes/impediments labels express difficulties encoutered while getting this pull request to completion.
Echoes requires pull requests to be tagged with at least one intent or initiative, and optionally with the effort and impediments.
There are certain scenarios where Echoes can infer the intent from the context and will label GitHub pull requests and GitLab merge requests automatically:
- When Echoes is connected to other (such as a , , or ), it follows these external references to find a label. Echoes may also follow parent links depending on the integration: in the example of JIRA, a single label at the EPIC label will cascade to its user stories, its tasks, down to the pull requests referencing them.
Echoes integrates with the GitHub check API and can alert you when a pull request is missing the required labels. This check is only enabled for authors that belong to a team from the point of view of Echoes. The check is skipped for example for new employees who haven't yet been added to a team within Echoes, or for open source contributors from the community.
Echoes offers a reusable GitLab job to do the labels check. Include the corresponding yaml file and add this job to your stages to enable it:
Q: What if I don't know which label to set for a particular pull request? Leave it blank! It's better to have some untagged items rather than randomly tagged pull requests.
Q: Can I add a new echoes/ label from GitHub if needed? No: Echoes will regularly reconcile labels on repositories with its configuration and your label will get deleted. New labels must be added from Echoes configuration and will then get published on all repositories.
Q: Will it make any difference on results if I send fewer/more, or smaller/larger pull requests? No: Echoes doesn't look at the diff, nor at the absolute number of pull requests. You can continue contributing exactly as you're used to, with the minor change of adding labels!
Q: Can I get access to the dashboard? Yes, you can ask the Echoes administrator for your organization to create an invite and share a signup link. This will give you access to the dashboard, as well as to an individual report highlighting your contributions over time (which nobody but yourself has access to). You can also get some of the data automatically sent to .
Q: What happens if a commit appears in multiple pull requests? Echoes keeps tracks of commits and can recognize when a same commit appears in the context of different pull request. One very common scenario is when changes are submitted against a staging branch, and this staging branch gets merged to main to trigger a release: Echoes will account for the commits when they are first introduced to staging.