Live data from Hacker News

Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

atlassian.com

171–180 of 305 posts

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#171

Earlier quoted context omitted.

See, the irony of this is that you are just publicly sharing performance numbers which undeniably show a pattern of performance issues. It also doesn't seem to be possible without you first accepting ToS. Ooops!

who says this is an "issue" its just numbers. If you think its an issue thats your interpretation. For instance I used jira for communicate with my team about 3 projects and it only took me 3 hours. Maybe this person is writing a fiction story where the protagonist is using Jira and they are detailing how they spend their day. Its like a John Steinbeck novel

May I point you to the title of this submission?

"Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues"

No sane judge would agree with your interpretation.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#172

I'm curious, I'm a Cloud customer and I can tell you that the service is incredibly slow even for a small scale setup (2 Jira Projects and 3 Confluence Workspaces). There's an insane amount of network requests seemingly for mouse tracking. By telling everyone here, that Atlassian Cloud products are insufferably slow, am I violating the ToS? I was actually thinking about doing a write up on the issues I've had but thi…

Sorry to hear it's been a frustrating experience. I'm a PM for Confluence Cloud and we're always trying to make it better. Would you be willing to share more specifics, such as: - Pages with content X are the slowest - Trying to do A/B/C is annoyingly slow - etc ? (edit: looks like HN is severely limiting my reply rate so apologies for delays) We're trying to focus on frustrating pages/experiences rather than number…

Other commenters have hit on this already, but the worst one that bites me all of the time is this one:

1. I click a link to an issue 2. I need to do something on that issue, so I attempt to click on a particular section to go make a modification 3. Bam, some background script has loaded, some new piece of content was shoved in, and what I clicked wasn't the thing I was expecting to click

Also, certain interactions within JIRA take far too many steps, and each one takes far too long to load, so it makes me dislike JIRA even more.

Project managers love JIRA, but engineers don't, because each time you make us wait we are less inclined to deal with the software that PM's need us to use so they know how things are going, so instead we get more meetings. If JIRA were fast, we could cut down on meetings.

Please make JIRA fast.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#173

Earlier quoted context omitted.

As a programmer, being able to have something like what GitHub does (Markdown text, you can preview what the rendered version looks like) would be great. I assume that people who are less technical would like a more WYSIWYG editor but as long as the ability to write straight Markdown is there I am sure that I wouldn’t care. Oh, and make sure it’s actually a reasonable subset of Markdown, not like Discord or Slack whe…

Thanks! I'm not sure this is the most doable thing (I'm not familiar with the technical aspects of the editor storage format) but can definitely discuss with that team. The "reasonable subset of Markdown" is also a very useful specific detail, exactly the kind of specificity that helps us do our jobs.

There's CommonMark, a standard for Markdown. You could make that your goal, instead of feature parity with any of the proprietary implementations like Github.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#174
post #133

Earlier quoted context omitted.

It seriously makes you wonder whether they even use it internally, because not acknowledging or fixing those issues while pretending you have a fast system doesn't make sense.

Yep, and from a demo of YouTrack (from JetBrains), I got the opposite impression: it’s streamlined just the way a developer would want, keyboard shortcuts and all.

Youtrack still somtimes comes up some very weird shortcuts :) https://youtrack.jetbrains.com/issue/JT-19706

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#175

Earlier quoted context omitted.

Hi BillinghamJ, You're right, I apologize for not being clear. We're targeting 1s for "Initial loads" on new tabs/new navigation, which I assume you're referring to. Our target for 'transitions' is different. If however the numbers you're referring to are "initial load" numbers, then I'm not sure. (edit: and action responses again are also a separate category. Our largest number of complaints are about 'page load tim…

no dont give into this guy ... this is done over the net. The rate of transfer has to be taken into account. Unacceptable is a measure of comparison. Unacceptable to who, you have a faster provider for cheaper, with as many features??? Im pretty sure he doesnt because if he could he would go there. There are tradeoffs and Atlassian has many project they are working on. They understand that there is room for improveme…

You've shown poor understanding here.

> Getting things below 1s is nearing the speed of the connection itself

That is absolutely false. Internet latency is actually very low - even e.g. Paris to NZ is only about 270ms RTT, and you _do not_ need multiple full round trips to the application server for an encrypted connection - on the modern internet, connections are held open, and initial TLS termination is done at local PoPs.

For services like this - as they are sharded with customer tenancy - are usually located at least in the same vague area as the customer (e.g. within North America, Western Europe, APAC etc).

For most users of things like Atlassian products, that typically results in a base networking latency of Really well engineered products can even operate in multiple regions at once - offering that sort of latency globally.

> Im pretty sure he doesnt because if he could he would go there

Yeah, we don't use any Atlassian products - partly for this reason. We use many Atlassian-comparable tools which have the featureset we want and which are drastically faster.

> when you dont even have the response time to move your mouse and click on the next item in .5s.

There is clear documented understanding of how UX is affected by with various levels of latency - https://www.nngroup.com/articles/response-times-3-important-...

> Sometimes techies just love to argue

Not really, I have no particular investment in this - I don't use any Atlassian product, nor do I plan to even if they make massive perf improvements.

But I do have an objective grasp - for tools like this - of what's possible, what good looks like, and what user expectations look like.

> no dont give into this guy

I don't expect Atlassian is going to make any major decisions entirely based on my feedback here, but it is useful data/input for exploration, and I do feel it's right to point out that they're looking in the wrong ballpark when it comes to the scale of improvement needed.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#176

Earlier quoted context omitted.

I did a test for you just now. I have 100Mbps internet, 32GB RAM, 4ghz i7 processor and suchlike. To make it easy for Jira, I'm doing this at a weekend, late at night, during the new years holiday so the servers shouldn't be busy. On a cloud-based classic software project (which has less than 200 issues) opening a link to an issue it takes 4.8 seconds for the page to complete rendering and the progress bar at the top…

Hi michaelt, Thank you for the numbers -> I agree these are slow, and I can guarantee you that the Jira team is working on it (though I can't talk about details). These numbers are definitely outside of the goals. I appreciate the call out of "page to complete rendering and the progress bar at the top of the screen to disappear" and "until the issue, comment and buttons have all loaded". In a dream world of course, e…

Hopefully this demonstrates that the anti-performance-discussion ToS clause is harmful not only to your customers but to you as well. You're getting useful information here only because some people are willing to openly violate it.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#177

Earlier quoted context omitted.

who says this is an "issue" its just numbers. If you think its an issue thats your interpretation. For instance I used jira for communicate with my team about 3 projects and it only took me 3 hours. Maybe this person is writing a fiction story where the protagonist is using Jira and they are detailing how they spend their day. Its like a John Steinbeck novel

May I point you to the title of this submission? "Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues" No sane judge would agree with your interpretation.

[deleted]

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#178

I'm curious, I'm a Cloud customer and I can tell you that the service is incredibly slow even for a small scale setup (2 Jira Projects and 3 Confluence Workspaces). There's an insane amount of network requests seemingly for mouse tracking. By telling everyone here, that Atlassian Cloud products are insufferably slow, am I violating the ToS? I was actually thinking about doing a write up on the issues I've had but thi…

I think future customers would like to know what kind of performance to expect, so a write-up sounds like a great idea.

It sounds like a bad business decision to not support open discussion on performance, it makes me think that they have something to hide.

Re: Atlassian Cloud ToS section 3.3(I) prohibits discussing performance issues

#179

Earlier quoted context omitted.

Hi michaelt, Thank you for the numbers -> I agree these are slow, and I can guarantee you that the Jira team is working on it (though I can't talk about details). These numbers are definitely outside of the goals. I appreciate the call out of "page to complete rendering and the progress bar at the top of the screen to disappear" and "until the issue, comment and buttons have all loaded". In a dream world of course, e…

> In a dream world of course, everything would load in It's important you understand that "everything loading in That is not "a dream world" - not even close. A well built tool like this, meeting standard expectations (i.e. table stakes), would hit You should be targeting This is why people are saying the company needs to make a major shift on this - you're not just out of the ballpark of table stakes here, you're ba…

> A "dream world" would be more like 10ms.

A gateway solely adds 50 ms. So I'm not really sure where you get your numbers/benchmarks from... They are unrealistic

Post reply on HN