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.

Hi folks, we launched to ShowHN over a year ago: https://news.ycombinator.com/item?id=23033387

Since then, we've continued to chip away at the problem of building responsive project management software, that syncs to Git source control and works with no setup. A re-designed Atlassian stack if you will, with automation based on Git events. So we can finally stop updating tickets as often as we do; the work is already in git, and it should be automatically reflected in our issue tracking or project management software.

With support from HN, we’re getting closer to this mission. You've spent time with us in calls, video sessions and over boba, to talk through how you ship mission-critical product updates, and how Jira continues to frustrate your teams, because it just wasn't designed for shipping.

Today, we're releasing a host of new features. Tara AI 2.0 delivers a new design optimized for creation, zero loads, automated workflows, and our new restful API.

Also, you can now create tasks, requirements, with automated roll-over for sprints, in 1/4th of the time it takes in typical PM software. We've created a hierarchy system with a universal work drawer, so work can be viewed and organized across the workspace.

As always, our free plan is still free for unlimited users, with upgrades available to premium or co-pilot plans.

I'd love to hear your feedback & thoughts. Thanks!

Solid point, but I would counter that a feature or a product is never truly complete. The goal should be to get to a stage where users can derive value from the feature (or product), and ship.

In our case, the main ask from developers is the ability to sync/connect their tasks to merge requests on Gitlab. v1 of the integration does exactly that, and additional elements will be shipped over the coming weeks as users activate the integration.

We're a few months away from introducing Tara premium, which includes access controls for teams and user level permissions (ie contributor, etc), and is based on simple subscription based pricing. It's pretty much what our users have asked for, and we're continuing to listen to their feedback.

That being said, our entire ethos is to have a functional free forever plan, where users can manage their tasks and run their sprints, without worrying about hitting a 10 user limit, limited-time trials or task limits. We're avid supporters of open source, and we believe closed source software should have wider availability. So much of B2B software is behind paywalls, demos and short trials, hence our approach.

At it's core, we find it to be an Apple OS vs Windows OS problem. You can either build highly complex project management systems, with 50 different types of subsets, customizations and setup instructions (ie Windows?) or try to design software that just works through simplicity in design and set defaults based on your workflow (ie Apple!).

It's an interesting conundrum and one that we think B2B software rarely gets right. Why can't B2B software inspire delight in the user and just work?

We've decided to have a laser focus on teams that ship early and often, and help with their workflows, by innovating through design. That being said, we still have a long way to go.

Yep.

In our experience building any form of meritocracy in recruiting, was excruciatingly difficult due to

1) inherent subconscious bias on the part of the recruiting team 2) pedigree bias - employers only wanting to view candidates that were from certain ivy league institutions

We tried long and hard, for a good 18 months, and it became an arduous battle fraught with the possibility of having to make unethical decisions in the structure of our algorithms. Our whole thesis was to create a system that recommended candidates based on their github repos. Pretty sure someone will solve this problem, but in our experience, it felt like a losing battle since recruiters wanted access to certain types of candidates and were continuing to reject candidates that were surfaced, with non-traditional backgrounds.

This was 2015, I think someone will solve this problem with time. The experience did teach us a thing or two about git commits, PRs and the overall experience of productivity through git based systems.

I think we would just integrate with an existing tool for this vs building it ourselves.

On prem will take more time - but kanban and calendar views are on the roadmap.

Nobody does. It's ridiculous that it takes 21 clicks to create a sprint. We've literally timed ourselves in every Jira instance (cloud and next-gen), and every point of configuration, setup or action just takes hours.

A platform for productivity, should have zero to minimal setup, built-in views and it should work hard to get out of your way.

If it helps, creating a sprint is 1-click on Tara. And I'm hoping it stays that way!

One way we've tried to fix this is with our slack integration. Using the task URL, or ID, the integration quickly unfurls context in the task (showing story info) and allows quick actions. Same process with requirements/epics.

URL unfurling was shipped today with the slack app, and quick actions are coming in a few weeks.

Hey PJ! We've loved having Placenote on board. Hoping the new slack integration works well for you guys- if not just ping! FYI - notifications on sprint reports are shipping in 2 weeks.

On the roadmap but looks like we should checkout WorkOS :)

Not yet but it would form part of a future on-prem version of Tara, where privately-hosted instances of Github/Gitlab are accommodated.