iba99

We just launched an API and should have a migration tool soon. Right now, it's typically a simple CSV import of issues, but the data mapping doesn't work too well with Jira's data. So far, it's been a trojan horse approach. A small team starts using Tara, enjoys the experience, and it starts to spread within the organization. Startups have been our bread & butter, but we also have small teams at larger enterprises using it.

The long game is to continue with the approach of allowing small teams to use Tara, and go under the radar for as long as possible.

As for Notion integration, yup, it's on the roadmap. Our integrations roadmap should get faster now that our restful API fully releases this week.

One other thing we've noticed is how slow Confluence and Jira are together. It's fascinating that stitching these products together under one Atlassian service (through acquisitions) hasn't served to provide a good or modern user experience.

We built our "define" feature to allow for spec'ing, and docs. And let's not forget how frustrating markdown is in confluence. We're working to really service markdown well in our text editor, and should have it released soon.

Hey Mani! Great to see you here- it's been a while.

You read our minds. We are thinking about how we can integrate with Jira for a truly sync'ed experience (since several teams have suggested using our interface to make updates in Jira + since we have simple built-in dashboards it just makes it easier to use for everyone). The challenge is to design it in such a way, that you don't have to spend a ton of time configuring the integration, mapping fields or needing a dedicated engineer for setup. We're on it - in the meantime would love to hear your feedback if you get the chance to try out Tara.

If you care to commit. Once version control permits. Bit by bit.

Scrum-ptious (when a scrum goes really well)

Here are the issues though with Jira's Github integration: 1- Requires unito or an additional plugin to truly function 2- Needs quite a bit of setup to get minimal value 3- No built-in dashboards optimized for git events (ie when is a PR merged, predicted vs actual, how does that relate to your team's current sprint). 4- One-directional sync (vs a true bi-directional sync).

We've optimized for built-in dashboards, minimal setup and a bi-directional sync. Over time, we're also going to be building inside the terminal or inside Github's interface, to truly enable seamless interactions with Git.

One way to work through this would be to provide viewer vs collaborator user types - but ofc a viewer wouldn't be able to actually create tickets. The true goal is to build a system where everyone is productive as soon as they join, where a $5-$8 cost seems incremental, vs the work the system is able to augment for a full-time developer, business person or a contractor. This is why we're designing Tara to initially be an interface in terms of user interactions, but over time, to augment work as it happens. We've started down this path with effort predictions, sprint loads and automation of statuses.

Here's a few that didn't make the cut:

The Dev files - the source code is out there

Dancing with the git stars.

(I could go on).

Thanks giga, let us know how you get on with the platform as you start using it! We've thought about work hierarchy and how to create persistent states across the workspace with the universal drawer. It allows fast task, doc and subtask creation.

The ideal here is to get to a point where you don't have to think about creating, it happens naturally.

Thanks for reporting this! Please try a page refresh or typing in /logout and heading back to login again. This may happen with certain browsers or configurations - it's happening rarely so we still need to properly debug. Let us know if you've been able to get into your workspace.