Live data from Hacker News

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

tara.ai

51–60 of 97 posts

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

#51
post #26

Earlier quoted context omitted.

This is the correct answer.

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 s…

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

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

#52
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/

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

#53
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?

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

#54
post #17
post #10

Earlier quoted context omitted.

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

Please do!

Scrum-ptious (when a scrum goes really well)

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

#55
post #49
post #30

Earlier quoted context omitted.

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

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.

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!

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

#57
post #26

Earlier quoted context omitted.

This is the correct answer.

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 s…

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.

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

#58
post #10
post #9

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

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

Git actions speak louder than code

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

#59

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 lik…

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.

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

#60

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?

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.
Post reply on HN