Help us improve Compass for $200!

[Caylie Panuccio]

Hello Community!

I'm Caylie, the researcher for Compass.

I'm conducting research to understand your experience using Compass so far, and what we can do to improve how Compass works for you and your teams. 

• Sessions are 1 hour and conducted over video-conference, so you can participate from anywhere.

• During the research, we'll start with a general chat to get to know you, then, we'll look at Compass together

• As a token of our appreciation, you'll receive an e-gift card worth $200 USD within 5 days of completing your session.

If you're interested in taking part, please click here to answer a few questions and pick a time.

Cheers,

Caylie

[Todd Schwartz]

I have just become aware of Compass, so I'm not quite ready for a user experience interview.  But I do have some feedback on a feature that concerns me: Dependencies.  Compass appears to be designed for a human to manually enter and manage dependencies.  I think this is problematic, because it would duplicate the dependencies that are already expressed in code.  As the code continues to change, the manually entered dependencies would very easily become out of sync with the actual dependencies in the code.

Instead, I suggest that Compass be designed to scan the project repo for key files that identify potential dependencies, e.g. requirements.txt or pyproject.toml for a python project.  When Compass finds such potential dependencies, it could allow a human developer to confirm/correct/reject the dependencies.  When a dependency is removed from the requirements.txt or pyproject.toml file, then Compass would automatically remove the associated dependency.

[Caylie Panuccio]

Thank you for sharing your thoughts Todd! I will pass this onto the team.

[Taylor]

Hey @todd glad you discovered Compass and thank you for jumping in with your feedback!

I'd love to clarity a few things on dependencies and get your thoughts. Our goal with dependencies was to indeed design it for a human, but primarily to understand and navigate that information rather than manually input it. 

We do allow for manual input of the values of course, however, to your point, depending on how complex the system is the need to automate quickly becomes paramount. We deal with a massive variety of customers and their internal systems and developer experience all have their nuances.

For the manual update, we do see a lot of teams actually just start by documenting their 'upstream dependencies' manually via key services so they can understand when their are deployments, incidents, and other events happening - this appears on the activity feed once you add dependencies.

For the automated side, we allow customers to add the dependency in their `compass.yml` definition which is usually automated by some bot/job their internal platform engineering team would setup. There are so many strategies for dependency management - maybe you have a proper service mesh effectively deployed and you are quite mature, you may use observability tools to look at API requests, or you may map dependencies in some kind of file in code.

In addition to registering this in the `compass.yml` definition, you can also just use our public GraphQL API (which is available for every feature in the product) to interactive with the data model, dependencies included. Inside the Update Component mutation you can take whatever existing ways you use to detect dependencies and send that to Compass. We have an open-source repo with several code snippets to help here but reach out to us if you need further help.

Once pushed into Compass, we try to focus on how developers will use this information. Today, we see customers using this for several different reasons

1. They use the activity feed to see upstream events (deployments/incidents, etc.) during development or incidents. It helps an individual developer or team working on a single service understand the larger picture. These dependencies can cut across various component types - so the services, libraries, ML models, and other aspects that may change and they want to know about it.
2. During an incident, they will see the affeted service(s) in Slack or in their incident management tool and will jump into the link to the Compass service. They will check the activity feed, and then jump into a couple of different dependencies to see more information about those component - who owns them, where the slack channel is, etc. This radically cuts down time to resolve as it let's developer self-serve and quickly find critical information.
3. Building a new feature is increasingly involving multiple services/code bases that are assembled together to deliver some end value for the customer. Developers can use Compass to find popular services but also understand what THOSE services rely on and what tier it is. They would probably trust a Tier 0 service with 20 existing dependencies by other well-known services with lots of documentation than a Tier 3 service with no existing dependencies and no documentation. Furthermore, when they register that dependency, the team that owns the service providing the functionality can broadcast changes to all downstream consumers via announcements. This saves a TON of time and energy.

There is a lot more we want to do in tying these workflows together with JSW and JSM using the Automation platform and Notifications which we will continue to improve. But the bones are there. 

Lastly - We have thought about building our own mechanism to 'auto-detect' dependencies and put that into a triage bay exactly how you have described! If we can find a flexible and performant way to do this that covers most customers' setups or preferences then we will absolutely prioritise it, we have just been focussed on a few other areas for the time being.

With that being said - did you know we have a live marketplace to host various apps, using Forge, do extend Compass in an infinite number of ways....building a small app to do this and hosting it on our marketplace would fill a needed gap right now. We will be offering paid apps in the near future.

Let me know any further questions you have or general thoughts on this approach? When we circle back to an auto-detect feature, can we reach out to you?

[Black Jalid]

Hi Caylie,

I’m interested in participating in the Compass research session. It sounds like a great opportunity to provide feedback on the platform and help improve its functionality. I'll click the link to answer the questions and choose a time. Looking forward to the session!

[Jaki3]

Hi Caylie,

Thank you for reaching out. I'm interested in participating in the research session for Compass. The opportunity to share my experience and contribute to its improvement sounds great, and the e-gift card is a nice bonus.

Please let me know the next steps, and I'll be happy to answer the preliminary questions and schedule a time for the video conference. You can also visit my website vista roofing lincoln.

Cheers,

[Manuel Niederkofler]

hi,

can I also participate even if I am currently not using Compass.

Regards

[Caylie Panuccio]

Hi Manuel, thanks for checking! Unfortunately I do need people who use Compass for this study.

However, if you'd like to participate in our research projects you can sign up to the Atlassian Research Group here: https://www.atlassian.com/research-group

Cheers,

Caylie