Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

atlassian.com

Post reply on HN
Print view View original

221–230 of 305 posts

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

#221

Post by hadrien01 »

pluc wrote: post #133
plorkyeran wrote: post #51

Earlier quoted context omitted.

Literally everything? I don't think I could give an example of something which isn't frustratingly slow in Jira. It doesn't need targeted fixes to specific things; if I successfully made a list of the ten biggest offenders and they were all magically fixed tomorrow I don't think it'd appreciably change the experience of using Jira because the next 90 would still be awful. When faced with long-tail performance problem…

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.

They use the on-premises version, which is much faster: https://jira.atlassian.com/secure/Dashboard.jspa

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

#222

Post by deathweasel »

miken123 wrote: post #112
confluence_perf wrote: post #28

Earlier quoted context omitted.

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…

> Would you be willing to share more specifics That's something you could easily figure out yourself. E.g., just grabbing some random JIRA: https://hibernate.atlassian.net/jira/software/c/projects/HV/... Opening an issue in that tracker takes 24 seconds for me. Twenty-four.

9s to load that page. 3s just for `jira/software/c/projects/HV/issues/?filter=allissues`, which is 194 lines of HTML (with some scripts) but the bulk of the 3s is just content loading.

Wow.

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

#223

Post by bloaf »

launderthis wrote: post #169
confluence_perf wrote: post #141

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…

The internet is fast. Computers are fast. One second is enough time for my machine to download 10M data points and render them into an interactive plot.

https://leeoniya.github.io/uPlot/bench/uPlot-10M.html

In my mind, anyone doing UI development and seeing user interactions taking over 1 second should be asking themselves "did the user just try to operate on more than 10^6 of something?" and if the answer is no, start operating under the assumption that they've made a mistake.

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

#224

Post by Judgmentality »

hadrien01 wrote: post #221
pluc wrote: 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.

They use the on-premises version, which is much faster: https://jira.atlassian.com/secure/Dashboard.jspa

If that's true, the fact that they aren't dogfooding their own product makes me 100% confident they will fail.

I'm actually going to look into shorting Atlassian now.

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

#225

Post by jchook »

dalrympm wrote: post #22

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…

Check out Clubhouse.io

I've used many others including Github, GitLab, Phabricator, Redmine, etc., and Clubhouse does a great job IMO.

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

#226

Post by NickNameNick »

thewebcount wrote: post #185

I don't want to sound mean, but before discussing performance issues, can we talk about how completely unusable all of Atlassian's products are? I mean this sincerely. I feel bad saying it because I know there are lots of people probably on this site that worked on them. But I literally often have no idea how to proceed when using these products. That's something that hasn't happened to me since before I was a teenag…

As much as I don't want to defend confluence here, or anywhere...

The front page of your confluence instance's default space was configured by someone to show the all-activity feed.

You should be able to go in to your profile, and set your default space to a more specific and useful 'space', maybe your teams space.

While you're looking at your profile, you should also see a more tailored activity feed.

I can't help you with crucible.

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

#227

Post by smarx007 »

acdha wrote: post #210
smarx007 wrote: post #134

Earlier quoted context omitted.

Well, you certainly need "tips and tricks" to make Arch Linux fully usable. Every powerful tool needs to be adjusted to its use (Github is full of dotfiles and macOS bootstrap repos). Doing so is a sign of professionalism (craftsmanship).

I think that’s saying more about Arch than anything else. While it’s not wrong that people add dot files to track preferences, those aren’t necessary for basic usage. Someone using macOS without customizing anything still has a good experience. A key distinction is between domain complexity and what the product adds to that intrinsic complexity. If you use GitHub or GitLab issues with no customization you’ll have a b…

You are right, Arch has a poor product experience.

On the other hand, I do not view those systems as products when it comes to professional use. A non-techie might see a Mac as a fancy laptop but for me it's a tool. Just like an HSS cutting tool in a lathe, you'd carefully maintain it (you don't want to use a dull cutting tool) and tune it. Just like you want to regrind a cutting tool depending on the part you are machining, I disable Intel Turbo Boost using http://tbswitcher.rugarciap.com when I run long perf evaluations of my programs for academic projects. If M1 based Macs will not allow me to disable their boost clock functionality, they will be unsuitable for my work as a tool. When that happens, you simply pick the most fitting tool. Not necessarily switching dev platforms, in this case a separate machine running Linux for the eval may be OK.

Regarding issue trackers, there are still some things I miss about Bugzilla after moving to Github issues such as sorting issues by two fields in order (eg first by prio and then milestone). I similarly like complex queries that can be saved in YouTrack. I will admit that 5 years ago I thought that Bugzilla was ugly (it still is) and not user-friendly (one of the worst) but now I simply see it as a professional tool that does not get in my way once I learn how to use it. On the other hand, most of the tools with proper UX (not all, most notably airplane cockpits have proper UX but still do not get in the way of a pilot doing their job including manual overrides for all kinds of malfunctions) have some "user journey" which gets in the way of almost every pro user.

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

#228

Post by dane-pgp »

Judgmentality wrote: post #184
orangecat wrote: post #176

Earlier quoted context omitted.

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.

Not to mention the reputational damage from people asking "why the hell is this in the contract in the first place?" It says they're so afraid of the quality of their product they'd rather litigate their customers than fix their product.

I wonder if these should be called "Streisand clauses", because it seems that the net effect will be for people to increasingly associate Atlassian with badly performing software.

Certainly if someone asked me what I know about Atlassian, this would now be one of the first things that come to mind.

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

#229

Post by bak3y »

jchook wrote: post #225
dalrympm wrote: post #22

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…

Check out Clubhouse.io I've used many others including Github, GitLab, Phabricator, Redmine, etc., and Clubhouse does a great job IMO.

My org uses Clubhouse, and it's still slow. Probably not as slow as Jira, but it's a running joke where I work.
Post reply on HN