syed99

I had a chance to play around with the product and I really love the ease of creating a multi step workflow, to the point where I'm sure I can train my marketing team to use it. That being said, is there a way to share these workflow with others...either privately or publicly?

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.

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.

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.

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.

Git actions speak louder than code

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.

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!

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.

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.

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.

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.

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.

Forgit about it :p

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.