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

101–110 of 305 posts

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

#101

Post by saagarjha »

dylan604 wrote: post #78
Hamuko wrote: post #49

Earlier quoted context omitted.

The problem with Atlassian's Terms of Service is that most of their end-users are not paying for the software and do not really care if they violate an agreement they were either forced to make or which someone made on their behalf.

They will suddenly care when Atlassian locks them out of being able to access anything. Then, we'll see posts on Twitter or here or elsewhere about some user crying about not getting access to "their" stuff on a 3rd party's site.

The thing we’ve constructed of users not owning their content that they post on platforms and then holding the ability to lock them out of access to it arbitrarily is really one of the worst things that has happened to the web.

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

#102

Post by keithnz »

confluence_perf wrote: post #28
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…

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…

this "trying to show concern" is just fake. Atlassian have a ticket tracking system for their problems. They just ignore so much of the big hard problems, they close tickets with hundreds and hundreds of people on it explaining a multitude of core problems. Coming on HN is just trying to spin it for PR purposes is just not going to work, thread after thread on HN just shows that many many people have been BURNT by Atlassian products. However, I will say, Confluence has improved, but so many things still suck about it, including it being sluggish, and a search that seems really brain dead.

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

#103

Post by saagarjha »

hchz wrote: post #87
confluence_perf wrote: post #25

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)

"My boss told me to generate a bunch of JIRAs in reaction to the recent accurate discussions on HN of how poor our performance is, so I need specific dit-dot issues to buff our team metrics rather than address the cause of the issues, which is a political non-starter"

A more charitable interpretation might be “my boss won’t let me fix things unless I have specific comments about problems from people who use the software”.

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

#104

Post by acdha »

redisman wrote: post #96
acdha wrote: post #85

This is not surprising: anyone who’s used Atlassian products knows that quality has been job number 97 for years. That doesn’t happen by accident – someone’s made the decision that they’ll make sales anyway and cut the QA budget. One of the most obvious examples: they have multiple WYSIWYG editor implementations which aren’t compatible. When you format something in Jira it’ll look fine in the preview and then render…

That doesn’t sound like a QA issue. Rather they have too many competing departments that are reimplementing the same things

That’s the cause. Normally that’d be caught in testing — the same input producing different outputs isn’t hard to test — and it’s commonly reported by users. Maybe they each think the other team should fix it but who cares: from the user’s perspective it’s broken.

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

#105

Post by michaelt »

confluence_perf wrote: post #28
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…

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…

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 of the screen to disappear.

Opening a Kanban board with 11 issues displayed? 4.2 seconds for the page to load.

Click an issue on the board? 2.5 seconds for the details to pop up.

Close that task details modal - literally just closing a window? 200 milliseconds. Not to load a page - just to close a modal!

In case I'm being hard on cloud Jira by insisting on using a classic project, I also checked with a 'Next-gen software project' with less than 2000 issues.

I click a link to view a particular comment on an issue. 4.8 seconds until the issue, comment and buttons have all loaded.

I choose to view a board? 9.9 seconds from entering the URL to the page load completing.

I'm viewing the board and I want to view a single issue's page. I click the issue and the details modal pops up - and just as I click on the link to the details, the link moves because the epic details have loaded, and been put to the left of the link I was going for, causing me to click the wrong thing. So this slow loading is a nontrivial usability problem.

View a single issue, then click the projects dropdown menu. The time, to display a drop-down menu with three items? 200 milliseconds.

This is what people mean when they say the performance problems are everywhere - viewing issues, viewing boards, viewing comments, opening dropdowns, closing modals? It's all slow.

And if you imagine a backlog grooming meeting that involves a lot of switching back and forth between pages and updating tickets? You get to wait through a great many of these several-second pageloads.

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

#106

Post by chrisseaton »

confluence_perf wrote: post #86
igetspam wrote: post #34

Earlier quoted context omitted.

Know what would be great? Markdown support. The WYSIYG is full of bad assumptions and has been forever. In the beginning, we could at least opt out but that's long gone. I actively encourage companies I consult for to use anything but confluence because it seems to be designed specifically for the lowest common denominator with no allowance for people who work faster with a keyboard.

followup questions: what level of support are you looking for, and what would be sufficient? 1) markdown macro (limits markdown to the body content, and not interacting with other macros or styling) 2) copy/paste markdown -> autoconvert to WYSIWYG (limits markdown to copy/pasting, so no editing Markdown inside) 3) "markdown pages" (something like 'this page is Markdown only, no WYSIWYG) I make no comments/promises on…

Just normal Markdown for all edit fields! GitHub manages to have a single (almost) Markdown format everywhere. Could we have that in all Atlassian products. There’s no need for your own format.

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

#107

Post by confluence_perf »

epage wrote: post #94
confluence_perf wrote: post #86

Earlier quoted context omitted.

followup questions: what level of support are you looking for, and what would be sufficient? 1) markdown macro (limits markdown to the body content, and not interacting with other macros or styling) 2) copy/paste markdown -> autoconvert to WYSIWYG (limits markdown to copy/pasting, so no editing Markdown inside) 3) "markdown pages" (something like 'this page is Markdown only, no WYSIWYG) I make no comments/promises on…

Not who you are respondin to but some thoughts 1. Don't be Slack / Teams :) What I mean by this is if you support it, support it correctly rather than "markdown as keyboard shortcuts" that some products do where if you make the simplest of editing changes, your "markdown" isn't recognized. 2. Devs want to consistently use Markdown across their entire suite At my last job, we were switching to Azure DevOps. They suppo…

Thanks for the detail! Point (1) is very interesting

on (2) -> it sounded like you're saying (a) 'across entire suite identically is good', but that also (b) 'if there's a clear separation of Dev vs nonDev apps/docs, having different support is okay', did I read that right? please correct me if wrong.

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

#108

Post by odiroot »

simon1ltd wrote: post #3

Nothing says “great product” like a ToS that bans you from discussing the problems. I self-host a confluence install, and it’s performance is poor even with a good sized VM and absolutely zero other traffic to it.

It's the Oracle school of public relations via litigation.

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

#109

Post by lexicality »

I'm more concerned about 3.3(c) "[you will not] use the Cloud Products for the benefit of any third party".

Surely if I'm tracking bugs in Jira, that is to the benefit of my users?

What if I am using post-it notes to keep track of a client's request and they demand I use Jira instead because I keep losing the notes. It's extremely to their benefit that I use the cloud services...

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

#110

Post by davb »

michaelt wrote: post #105
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…

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…

That tallies with the experience I had using Jira cloud a few years ago. It sounds like it's still a great case study in how not to architect an issue tracker.
Post reply on HN