Show HN: Tara 2.0 – Fast Jira alternative with automation based on Git events

iba99 2021-08-17 15:00:14 +0000 UTC [ - ]

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!

dsr_ 2021-08-17 23:55:00 +0000 UTC [ - ]

Can I self-host it?

The only reason we're going to move away from JIRA is that Atlassian dropped server installs and is moving everyone to their cloud or datacenter products.

Have a great conversion from JIRA and a reasonably-priced self-hosted option, we'll be looking at you in six months.

syed99 2021-08-18 00:30:16 +0000 UTC [ - ]

Its definitely something we've been exploring when putting our product roadmap together. I'm curious though, if we had a private cloud instance vs self hosted? I'd love to understand why self hosted would be the option you'd go for.

dsr_ 2021-08-18 02:11:09 +0000 UTC [ - ]

Our security policy doesn't let us put confidential information into other people's hands unless they are willing to commit to the full value of damages from a breach on their side.

It's a great question to differentiate sales critters: the new ones are sure that they can work something out; the middle ones are dubious; the experienced people chuckle and disengage politely.

andy_ppp 2021-08-18 07:51:04 +0000 UTC [ - ]

Are any external suppliers stupid enough to agree to this? Isn’t it basically writing you an unlimited cheque if someone hosting your data gets hacked?

dspillett 2021-08-18 10:57:30 +0000 UTC [ - ]

I suppose some might reason that if something that serious happens they'll be out of business anyway, and just make sure the responsibility can't follow them if it does happen and the business does fall.

Those that specialise in holding other party's data like this will have liability insurance to cover significant events financially (though there is of course still reputational risk to consider) and processes in place to try make sure such events don't happen so calling on that insurance never needs to happen.

> if someone hosting your data gets hacked

It wouldn't be if any someone got hacked, just if something they are responsible for fails and enables a data leak, so they are not accepting third-party risk unless they themselves involve third parties in the mix. Proving you are not the source of a leak could be an interesting proposition though.

firebird84 2021-08-18 13:19:12 +0000 UTC [ - ]

This is actually a fairly big deal in enterprise sales. I learned that one of the reasons my company didn't use Slack and opted for a larger company's (arguably inferior) clone was that Slack was basically not suable (blood from a stone and all that). My company basically wanted the ability to hold the provider liable for a breach. I look around at our other vendors and most of them appear to be capable of weathering a lawsuit, whereas Slack (at that time) was not. Now...however....things have changed. :)

Terretta 2021-08-18 11:25:08 +0000 UTC [ - ]

Every supplier to regulated industries is smart enough to do this, as it’s generally required.

andy_ppp 2021-08-18 11:32:22 +0000 UTC [ - ]

I suppose you need to charge a lot more to provide such guarantees.

sjogress 2021-08-18 12:47:14 +0000 UTC [ - ]

I think for most/many European companies, especially those that are potentially handling PII, there are regulatory concerns with using US based hosting/companies.

My employer for instance has put a ban on deploying anything new on AWS/Azure/Google Cloud until legal issues have been settled after Privacy Shield was invalidated.

Everything new right now needs to be on EU/EFTA data centers run by EU/EFTA companies. This essentially means self hosting since most clouds are owned by US companies.

shagie 2021-08-18 01:06:15 +0000 UTC [ - ]

A lot of orgs have various regulatory constraints. For much of public sector, you're either going to need to be able to have it hosted on AWS GovCloud or allow the organization to self host it on their own servers.

syed99 2021-08-18 02:04:36 +0000 UTC [ - ]

Thanks for the clarification, there’s definitely a pathway for us to allow for this in the near future. I think it’s a safer path than running after industry specific compliances.

robertlagrant 2021-08-18 07:15:11 +0000 UTC [ - ]

Working in a regulated industry, shipping (e.g.) some docker images and a Helm chart is definitely preferable!

superMutex 2021-08-18 00:57:32 +0000 UTC [ - ]

In our case it's due to regulations in place. For example, our data must stay on Canadian servers at all times.

syed99 2021-08-18 01:44:34 +0000 UTC [ - ]

Makes a lot more sense now, the flexibility to configure to your own resources for regulatory reasons.

tyingq 2021-08-18 03:24:53 +0000 UTC [ - ]

You'll probably also encounter people who are a bit jaded after their experience with Jira's hosted cloud versus on-prem. Jira on-prem can be slow also, but at least you can throw ridiculous amounts of hardware at it and make it okay-ish.

syed99 2021-08-18 04:23:49 +0000 UTC [ - ]

We had a horrendous experience with on-prem during my last tenure. A lot of it came from lack of support and performance improvements. Atlassian has its way to strong arm it’s biggest customers into paying more or throwing in sub processors in the mix. At some point we had IT, Dev Ops and Engineering consultants trying to get our workflows running.

Eventually we caved and pushed their account execs to support a “secure” private cloud that passed our IT teams compliance criteria. Fun times!

lanbanger 2021-08-18 09:20:34 +0000 UTC [ - ]

Can you define what data has to remain on Canadian servers? If it's just user data, and not your actual code, then you could use a synthetic data provider like https://synthesized.io to convert real user data to synthetic with similar properties, then host your code wherever you want.

joshuaissac 2021-08-18 12:59:39 +0000 UTC [ - ]

Jira tickets (and Tara tickets) are going to have user data (including poorly-defined user requirements). Turning that into synthetic data with Synthesised will almost definitely lead to developers building software that does not match the original requirements.

lanbanger 2021-08-19 07:08:23 +0000 UTC [ - ]

If you have real user data in non-production systems (e.g., development JIRA/tracking system) you're already doing it wrong. At the firm I work at we scan all non-prod systems for user identifying data and flag it up for removal.

prpl 2021-08-18 06:33:35 +0000 UTC [ - ]

datacenter is an on-prem product though?

detaro 2021-08-18 06:55:45 +0000 UTC [ - ]

Sure, at absolutely stupid price increases especially for smaller orgs. It starts at $42,000 a year... Also known as 840$ per user if you have 50 users.

danpalmer 2021-08-18 09:16:58 +0000 UTC [ - ]

That's $70 a month, which seems high, but not extortionate given that it's meeting very specific requirements.

detaro 2021-08-18 09:22:56 +0000 UTC [ - ]

The very specific requirement of doing exactly the same thing you could do for a fraction of the price the year earlier: manage issues? Running software is not some exotic requirement.

danpalmer 2021-08-19 10:24:10 +0000 UTC [ - ]

> Running software is not some exotic requirement.

But running software in an environment you don't control, but where it's expected to run perfectly or else you're on the hook for the support, that is. On-prem services are hard to get right, there's all sorts of issues around things like upgrades, software versions, etc.

I get that it used to do this, but software gets updated and moves on. I think it's reasonable to expect that you can remain on an outdated version and old pricing scheme, but give up support after some period of time, but I could also understand companies not wanting to offer that.

OJFord 2021-08-18 11:54:03 +0000 UTC [ - ]

The on-prem requirement; probably most paying users with that requirement are not very price sensitive, since it's a regulatory requirement on them, or similar. They're also probably typically large orgs (so it doesn't look so expensive per user, if they would even consider it in those terms), and resistant to switching providers due to other requirements/processes anyway.

detaro 2021-08-18 17:11:20 +0000 UTC [ - ]

I choose the 50 users example for a reason: I know plenty companies in that kind of size that prefer self-hosting and are looking to replace Jira now.

OJFord 2021-08-19 00:05:21 +0000 UTC [ - ]

And that sucks, I do understand, I just don't think Atlassian will feel the loss, and stands to gain far more by jacking the price for the price insensitive customers who remain, as above.

stunt 2021-08-18 09:50:19 +0000 UTC [ - ]

It's hard to tell if it's it integrated with Git directly or only via Github & Gitlab!

Both Github and Gitlab have built-in project management features! Why should I use a different tool if I'm using Github/Gitlab?

syed99 2021-08-18 20:18:51 +0000 UTC [ - ]

With GitHub we sync all the issues in real time. So all changes you make in Tara reflect on GitHub issues too. We make it easier for larger teams who run sprints and require a more accessible interface work better together i.e designers, PMs and EMs.

For the Gitlab for the time being we only allow connection of issue tickets to MRs and some organized views of commits and MRs in our progress mode.

korginator 2021-08-18 02:05:24 +0000 UTC [ - ]

Any plans of supporting kanban boards in future? We find that kanban works very nicely to manage certain types of projects, and we're currently using Jira's kanban features for many projects. I'd love to see alternatives.

Sync'ing with self-hosted Git servers would be good to have. Many of our projects are hosted on Git servers in a "secure network" behind a corporate VPN that, for legal and commercial reasons, cannot be hosted externally. Any thoughts on this?

syed99 2021-08-18 02:20:27 +0000 UTC [ - ]

We do plan on supporting kanban views over the next few months. It’s a WIP along with list views.

The question about self hosted git servers, we do support them but not officially through the GitHub app which is on the App Store. We do have a fully compatible backend that can integrate with any self hosted git using webhooks, we haven’t exposed those to users as of yet.

korginator 2021-08-18 03:02:13 +0000 UTC [ - ]

Thanks for the response, though my question was more about whether you've thought through how your webhooks based approach can work through VPNs.

For example, one of the organisations I work with uses a CheckPoint capsule VPN with some non-standard configuration that's controlled by their IT department that manages and supports client workstations.

To even access the Git server requires the user to be connected through VPN. I suppose you'll need Tara to follow the same route to the Git server that's sitting behind this VPN, right? This would be quite a different story than having Tara connect to a public facing self-hosted Git server, e.g., on our own data center or on AWS.

I suspect this will he a hard (impossible?) problem to solve unless Tara itself goes self-hosted and is on the same VPC as the Git server behind our VPN.

syed99 2021-08-18 03:06:51 +0000 UTC [ - ]

Thanks for clarifying. Yes this would be fairly different and requires an extra layer or configuration on our backend. You’re absolutely right about following the same route to the server per user and since our current configuration allows a workspace level workflow, we would have to write some middleware to handle this use case.

You are absolutely right about a self hosted solution being the better workaround which means it resides on an internally accessible network where the setup experience would be much more seamless.

vladvasiliu 2021-08-18 08:22:19 +0000 UTC [ - ]

For those kinds of situations, I've seen SaaS companies offer some kind of internal "connector", which could then establish an outgoing connection to a known domain, thus allowing the IT dept. to limit the access as they require.

anticodon 2021-08-18 04:01:11 +0000 UTC [ - ]

We use JIRA and GitLab at work. In the GitLab CI/CD configuration we define a few hooks that update JIRA task status on various events (MR is created, MR is merged, etc). It's a bit of manual work but it's working flawlessly for years. How is it different from this offer?

syed99 2021-08-18 04:47:26 +0000 UTC [ - ]

It works the same way for the automations but it’s a one click set up for GitHub. It’s makes it easier for Team leads or people who may not have the resources to bind together workflows and it ensures consistency in experience. Secondly we also infer statuses on PRs and through CI/CD that let you know where features are in the pipeline (coming very soon). Our aim is to make powerful git event drive features more accessible with the least amount of configuration.

buro9 2021-08-18 08:31:53 +0000 UTC [ - ]

Tell me about the sync... how complete is it? And the pricing... how do you accommodate OSS projects?

Our scenario is that our work comes in from multiple places, i.e; OSS community (one repo), SaaS offering (another repo) and Enterprise offering (another repo). What we're trying to achieve is a single pane of glass for a team to see all of their work, but the work to remain in the respective repos. So whatever tool we use must treat Github Issues as the system of record, and any tool must reflect what it does in Github. And further, it would be great to make that single pane of glass dynamic... i.e; I'm a Prometheus engineer and I want to create a team/project that aggregates all work on Alertmanager across all of the big projects that use it (even the ones that exist in other orgs).

ACK that our use-case may be at the extremes of what others do, so it's cool if this is not yet possible.

Additionally with the OSS repos per-user licensing of potentially all contributors is a tough ask, we would have no control over our pricing and most contributors would be idle... they're not employees, but we'd want to ensure the community could use/see the same tools that we would use, how could we enable community involvement in the tools without exposing ourselves to a loss of control over the operating costs of it?

chris1993 2021-08-18 01:59:04 +0000 UTC [ - ]

I looked but can't see in the FAQ or anywhere - do you provide a way to migrate from Jira and do you integrate with bitbucket?

syed99 2021-08-18 02:27:15 +0000 UTC [ - ]

Hi there, we currently don’t have a bitbucket integration but it’s on our roadmap towards the end of the year. We will however be updating our migrate tools early Q4 with Jira/Confluence mapping.

Nelkins 2021-08-17 22:47:09 +0000 UTC [ - ]

I love the pun on the front page. Will definitely be keeping an eye on this.

iba99 2021-08-17 22:52:11 +0000 UTC [ - ]

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).

syed99 2021-08-18 04:34:13 +0000 UTC [ - ]

Git actions speak louder than code

ellisv 2021-08-18 00:17:01 +0000 UTC [ - ]

Please do!

iba99 2021-08-18 04:22:36 +0000 UTC [ - ]

Scrum-ptious (when a scrum goes really well)

syed99 2021-08-18 02:12:16 +0000 UTC [ - ]

Forgit about it :p

dotancohen 2021-08-18 03:44:10 +0000 UTC [ - ]

Bring out the git.

iba99 2021-08-18 04:28:49 +0000 UTC [ - ]

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

manigandham 2021-08-18 03:56:27 +0000 UTC [ - ]

Congrats on the new launch Iba and Syed, I still remember meeting you guys years ago in LA, you've come a long way!

I'll echo some of the other comments here that most of the bigger companies I've worked with want a better JIRA but are weary of smaller companies, data security, and the switching costs involved.

Is there a way to offer this on top of the existing Atlassian tools? A similar model would be something like Scratchpad for Salesforce: https://scratchpad.com/

iba99 2021-08-18 04:41:30 +0000 UTC [ - ]

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.

ddon 2021-08-17 22:39:03 +0000 UTC [ - ]

Why startups don't try to break this charge per user per month thing? Would be great to have products which would charge like $10 a month for up to 5 users or so... why so greedy and charge 10 per user? So, if small team of 5..10 people, at $8 a month per user, is like $100 a month for single service. And if startup needs like 5..10 different services to pay, it becomes like a pretty good amount for paying for different services.

gexla 2021-08-17 23:45:00 +0000 UTC [ - ]

If you're actually employing 5 people then $100 is nothing for service which is central to your work. If it's 5 people not making money, then maybe you don't need a proprietary service.

brightball 2021-08-18 00:19:32 +0000 UTC [ - ]

This is the correct answer.

saurik 2021-08-18 01:10:47 +0000 UTC [ - ]

I guess if you assume that "small teams" are all working 100% on the one project... which isn't even slightly reasonable (hell: that isn't even reasonable for large teams). The per-user thing essentially means you are paying costs constantly for people who just need access to something as a contributor even though they are using it once a month. It is incredibly frustrating having to be like "ugh, I contracted with someone to work on some icons for my app, but now I have to pay for them to have a 'seat' on all of our project management tooling".

brightball 2021-08-18 20:27:56 +0000 UTC [ - ]

Primarily, you just look at this as a cost of the person's salary.

$10 / person as a standalone fee seems very different than...

$X,000 / month salary + benefits + $10 / month for a service that helps them get more done with their time that you're paying for.

Totally agree about guest contributors though. IMO ClickUp.com has the best pricing model of the bunch for this type of thing.

iba99 2021-08-18 03:09:59 +0000 UTC [ - ]

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.

syed99 2021-08-18 04:32:44 +0000 UTC [ - ]

We’ve explored ways to handle this. One of the things we’ve considered is metered billing where you only pay for the time the seat is used. It’s very similar to Github seat model but probably closer to slacks billing system.

Other explorations we did were around finer grained permissions or a collaborator vs assignee. The reason the industry itself is geared towards seats based plans in the is to drive better revenue predictability and handle cost variability between free and paid users better but we’re seeing more and more creative changes to sass billing models.

johschmitz 2021-08-18 05:15:44 +0000 UTC [ - ]

Why not charge based on typical "packages" containing a certain number of interactions with the service?

robertlagrant 2021-08-18 07:26:29 +0000 UTC [ - ]

This sort of thing is pretty annoying to procure. Imagine you have 20 suppliers and they all have bespoke pricing arrangements, vs you have 20 suppliers, who each charge you X per active user per month.

wiradikusuma 2021-08-18 03:51:14 +0000 UTC [ - ]

Maybe you can use generic usernames like freelancer01@mycorp.com and only change the display name e.g. Jim Smith <freelancer01@mycorp.com> in January, Sarah Lee <freelancer01@mycorp.com> in February?

syed99 2021-08-17 23:04:52 +0000 UTC [ - ]

Hi ddon, one of the founders here. I personally do agree on flipping the pricing models to be more inclusive. We’ve tried our best to make them as cost effective as possible and even go as far as allowing unlimited users on a free plan.

When we were working on pricing, we looked into everything from compute costs per user, data storage per workspace, new feature development, marketing costs and much more over the span of time. We came up with our pricing based off those costs and hence on our lower plans we’re still under the price of similar tools.

We’d love to, in the future figure out more flexible ways to price our users but at the same time maintain the service and growing feature set. I can assure you that we definitely gave having a Spotify family plan like pricing model a thought. In the mean time we are working with startups to accommodate their needs as they move into paid plans by offering discounts on long term commitments, we’re always open to discussions with our users and helping them stay empowered on our platform.

jillesvangurp 2021-08-18 06:48:09 +0000 UTC [ - ]

Very simple; at the prices you cite, the largest charge is the one you forgot about: people hours needed to maintain and setup these services. 100$ sounds like a lot but it's only 1-2 hours of development time per month; less if you are in a competitive market. And lets face it, it's never just 1 hour per month. Just spending a week or so setting this stuff up could fund years of SAAS bills potentially in terms of time spent. And a week is not a lot.

You also get this sunk cost fallacy where you basically keep on poring in more time (and money) because you've already invested so much. Self hosted commodity services only makes sense these days if you have too much money or very specific needs that you are willing to pay for. Even at their premium pricing, they are a pretty good value proposition for most companies.

Asana on the freemium layer is still pretty good value and an easy upgrade once your team grows. Same for github. We pay for neither. Github comes with Github actions too with lots of free CI minutes per month. The Slack freemium layer is pretty decent as well (more than enough for any startup). I'd consider paying for all of the above if I had to because these products are kind of nice to use as well. But I don't. 0$ / month is a pretty hard price to beat.

But even at hundreds per month, self hosting would still cost more and deliver less.

syed99 2021-08-19 01:03:26 +0000 UTC [ - ]

I guess from the other sub thread below Self Hosting takes away alot of the liabilities of operating the software when you're small, atleast in the a very litigious US and Europe. Larger incumbents eventually have been moving away from that self hosted model to provide consistent service or layer on professional services for those that can afford it.

manigandham 2021-08-18 00:54:50 +0000 UTC [ - ]

Offering a similar product at lower pricing is usually the worst-way to compete unless it's a major disruption (free, different business model, etc). You might help a few small customers but you'll end up missing on most of the revenue that your competitors are capturing.

While bills do add up, you should only be paying for services if they're delivering more value then the price you're paying.

syed99 2021-08-18 02:40:35 +0000 UTC [ - ]

That’s how we see it too. We didn’t underprice it to simply compete, it’s a mix of how the actual tech is built and how we can keep our net costs per user low. We’re just curious and love to hear how users perceive pricing and want to facilitate a conversation. The major value prop here is around automation; reducing engineering time in manual status updates in tickets and high value actions like assignment or effort prediction.

rochacon 2021-08-18 01:04:52 +0000 UTC [ - ]

Basecamp kind does this, but it has a single $99/month unlimited plan. I also wanted this, because not all users need the entire product anyway (i.e. bug reporters, guests).

syed99 2021-08-18 02:11:28 +0000 UTC [ - ]

That’s a good point. They do charge for the integrations though per user. Majority of our user base though syncs with github and slack. That is kind of where the compute costs go up specially with GitHub syncs but there are avenues we can explore with upcoming pricing where that’s an option to use the base tool. Thanks for bringing up their pricing plan as an example.

rocmcd 2021-08-17 23:42:54 +0000 UTC [ - ]

Because per user pricing is in line with the value you are receiving as a customer. If you are not receiving $XXX dollars per month in value, why use the service at all?

You are trading money for time and efficiency, after all.

nonameiguess 2021-08-18 00:44:35 +0000 UTC [ - ]

Ironically enough, self-hosted Jira used to do this, until they got rid of the server licenses and forced everyone onto their cloud, and now they charge per user.

syed99 2021-08-18 01:43:18 +0000 UTC [ - ]

Yup they did. Back at my former workplace they basically stopped updates and overlaid it with packages such as support, upgrade packs and more. At the end the price ended up equating to the same cost as the private cloud instance.

wyuenho 2021-08-18 12:10:19 +0000 UTC [ - ]

Any integration with Notion on the roadmap? How do teams migrate from JIRA to Tara?

iba99 2021-08-19 00:43:14 +0000 UTC [ - ]

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.

a-dub 2021-08-18 08:15:55 +0000 UTC [ - ]

i'm just going to throw out a few questions asking if features i wish these kinds of systems had are in here. maybe they are, and if they aren't, hopefully it's helpful!

what is the workflow like for going from a commit id (ala git-blame) to all available discussion and context around that change?

is there any sort of unified search through history that shows both changes and all discussion/context around them? (pull requests, kanban cards, related issues and prs, design docs/sketches/etc, slack threads)

is there any workflow/smarts for detecting recurring issues/bugs/fixes?

i used to ask "can you drive most of it by email" ... i guess these days it's "can you drive most of it by chat integration?"

syed99 2021-08-19 00:56:25 +0000 UTC [ - ]

Thats something we're working on i.e most of our R&D goes here, we've been building up capacity on getting contextual data from the commits/PR's and possibly from slack too and then surfacing it as meta data as a first step. For example being able to identify questions, solutions, possible additions to documentation.

The aim is to eventually pass on that data or use it for smarter inference like catching duplicates, bug frequency, reintroduction of code and possibly identifying tech debt. Our vision has been to go ticketless, while we're supplying the tooling to make those tickets today, in the future contextual information from different systems could provide enough context to do that work.

Gravityloss 2021-08-18 20:28:02 +0000 UTC [ - ]

Confluence is excellent. Jira is too slow and a big productivity brake. Tara seems interesting.

iba99 2021-08-19 00:40:54 +0000 UTC [ - ]

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.

jotato 2021-08-17 20:51:50 +0000 UTC [ - ]

Login with google isn't working. I'm redirect to google, select my account, and then I'm sent back to the login page.

edit: I just created an account using my email instead. You give a 404 after clicking "take me to my workspace" after the onboarding flow.

syed99 2021-08-17 22:40:53 +0000 UTC [ - ]

Hi, it might be a cache issue with your user object. I’d suggest navigating to app.tara.ai/logout and then try logging back in.

iba99 2021-08-17 22:39:23 +0000 UTC [ - ]

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.

Aeolun 2021-08-18 00:12:34 +0000 UTC [ - ]

I like this, but my enterprise will not be switching away from Jira any time soon, which is my main problem with all these new fancy services. It just shows me what is possible, but I can never have.

xyst 2021-08-18 11:25:00 +0000 UTC [ - ]

True. The decision makers at Fortune 500s usually don’t care about the performance of the tool. I find companies that offer all in one solutions (ie, Microsoft Teams vs just using Slack) have better chances at securing a contract. My company has probably paid out millions per year for a lesser product just so it integrates with existing software and services (outlook, office products like excel, office 365, azure ad, …). Plus they only have to deal with one vendor.

syed99 2021-08-18 01:40:54 +0000 UTC [ - ]

I do agree it’s hard, I’d love to know though, if there was a way for you to use the tool internally. How would you envision that happening, could it be a plugin, something working side by side JIRA perhaps?

Aeolun 2021-08-18 02:07:06 +0000 UTC [ - ]

Well, for tools of this kind, they could never be hosted, it would have to be on-premise.

I think if a tool like this would ever be adopted the first thing it’d need to do is sync with Jira, so things that happen in the tool happen in Jira too, and vice versa.

I’m not too sure though, I guess I kind of feel that the inertia is just too big. Unless it can do the same things that people (not developers, business people) want to do with Jira all the time (add thousands of custom fields, do arbitrary queries on those, build lots of unuseable dashboards, tens of different issue types with different fields and tabs for each, link issues with semantic types) and do them better, Jira will never be replaced.

I guess what I’d hope for is a way I can use the app while not having to deal with Jira, but then so much of our process is based on obscure Jira features that I’m not sure it’s possible.

ukd1 2021-08-18 02:06:06 +0000 UTC [ - ]

The website is super slow for me, which doesn't feel like a good thing.

syed99 2021-08-18 02:30:59 +0000 UTC [ - ]

Sorry to hear that, we just migrated hosts, our page FCP and speed index was around 3 seconds but if that’s not what you experienced, we’re definitely going to take a look into it.

sorenjan 2021-08-18 13:30:02 +0000 UTC [ - ]

Scrolling is very laggy in Firefox.

otabdeveloper4 2021-08-18 05:28:39 +0000 UTC [ - ]

It's not a "Jira alternative" in any sense. (Well, maybe in the sense that any issue tracker can be a Jira alternative.)

If you really want a Jira alternative, look at Youtrack.

gigatexal 2021-08-17 21:38:06 +0000 UTC [ - ]

looks super clean. Jira is powerful but the UI sucks

iba99 2021-08-17 22:45:33 +0000 UTC [ - ]

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.

0xbadcafebee 2021-08-18 00:16:44 +0000 UTC [ - ]

I honestly wouldn't use such a tool for anything mid to large size. Git is kind of a nightmare. Now, an SQL database, or a distributed key-value store, I would use as a backend.

nonameiguess 2021-08-18 00:48:18 +0000 UTC [ - ]

I don't believe they mean they're using git as the data store for the application. Sync with git means updating tickets based on parsing action commands embedded in commit messages pushed to your git server. Jira can actually do this, too, though I think you need to be using Bitbucket as your git server.

allset_ 2021-08-18 01:44:34 +0000 UTC [ - ]

You do not need to use Bitbucket, works with Github too.

iba99 2021-08-18 03:13:45 +0000 UTC [ - ]

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.

chrisweekly 2021-08-18 01:56:57 +0000 UTC [ - ]

Gitlab, too -- tho Jira still sucks.

syed99 2021-08-18 02:06:34 +0000 UTC [ - ]

We use Firestore as our DB :) I don’t think git and LFS as a hosting service could take us beyond a hundred users.