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

121–130 of 305 posts

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

#121

Post by MandieD »

runlevel1 wrote: post #65
rhencke wrote: post #38

Earlier quoted context omitted.

How does this relate to the performance issues being discussed?

In the case of Confluence specifically, it makes the cost of experimentation a lot steeper. Confluence's WYSIWYG editor will often make changes that can't be reversed with "undo" -- especially those involving indentation. Copy-paste frequently screws up its formatting as well. So if you don't want to risk losing lots of work, you have to make many smaller changes. With each change taking a few seconds, it adds up qui…

I always write my stuff in Word first, then paste into Confluence.

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

#122

Post by mattm »

emilfihlman wrote: post #81
judge2020 wrote: post #14

Cloudflare has this as well: >you will not and you have no right to: ... (f) perform or publish any benchmark tests or analyses relating to the Cloud Services without Cloudflare’s written consent; https://www.cloudflare.com/terms/#react-modal:~:text=(f)%20p...

This is just awful

As a software engineer who has been woken up in the middle of the night while oncall because some random user wanted to run their own performance tests against our system, I can completely understand why companies want to prevent this from happening without their awareness.

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

#123

Post by jiggawatts »

mattm wrote: post #122
emilfihlman wrote: post #81

Earlier quoted context omitted.

This is just awful

As a software engineer who has been woken up in the middle of the night while oncall because some random user wanted to run their own performance tests against our system, I can completely understand why companies want to prevent this from happening without their awareness.

a) That's not the reason.

b) Rate limiting is practically mandatory in an era of multi-gigabit client network connections on even mobile phones.

Remember: It's not a DDoS attack if it's one user.

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

#124

Post by jiggawatts »

saagarjha wrote: post #103
hchz wrote: post #87

Earlier quoted context omitted.

"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”.

Translation: His boss is an idiot and their lunch is going to be eaten by a company where management gives a shit about product quality.

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

#125

Post by jiggawatts »

sytse wrote: post #44
ineedasername wrote: post #30

Earlier quoted context omitted.

That explains the stance but is not sufficient to justify it. It gives Atlassian infinite power to stomp on any benchmark that shows poor performance under a claim that it is flawed. It is also irrelevant that it's been in your ToS since 2012: Precedent or longevity do not make consumer-unfriendly restrictions acceptable. This is implicitly recognized by allowing internal assessment: That assessment would be just as…

Those suggestions in your last paragraph look very reasonable to me. At GitLab we explicitly allow performance testing as our ninth and final stewardship promise https://about.gitlab.com/company/stewardship/#promises But I recognize there is a trade-off and companies can reasonably but the balance at different points.

There is no tradeoff.

DeWitt clauses are corporate censorship and are 100% self-serving.

There is zero benefit to consumers having no benchmarks at all available for entire product categories.

There is an enormous benefit to corporations to be able to silence critics with the threat of bankruptcy via lawsuit.

This is big corporations using the law to bully journalists and citizens, nothing more.

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

#126

Post by mgkimsal »

ratww wrote: post #62
confluence_perf wrote: post #41

Earlier quoted context omitted.

We have certainly heard from some customers that agree that 'everything' is slow, but we've also heard from other customers saying they have no problems. We would love to fix "everything", and we have some longer term projects focused on this -> However, "everything" fixes seem to be a more incremental boost and also take longer time to complete. If you have any feedback about "specific" items that are the most frust…

> but we've also heard from other customers saying they have no problems Can I suggest following up with those customers to see if and how they're using the product, what's their computer configuration, if there's anything special about them?

There's a bit of verbal sleight-of-hand going on - probably not intentionally.

"This is very slow"

"We have no problems"

These aren't addressing the same things, really (unless the OP was translating "we're happy with the speed of the entire system" as "we have no problems").

Are the people reporting "no problems" actual end users. People I know who've become acclimated to Jira that I know would happily respond "we have no problems" while the people below them who have to use Jira 10x more often (multiple times per hour, vs a daily look at progress, for example) would happily say "this is slow as molasses (and that's a problem)".

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

#127

Post by jiggawatts »

dekhn wrote: post #113

The obvious way to deal with this is to write a passive github repo that contains a performance test harness and test plugins that run against Atlassian servers. Make it trivial for any customer to download and use (I'm going to guess that Atlassian has some license terms about API use that could make this tricky). Simultaneously, tweet results from anonymous twitter, post to hacker news, get picked up in the trade p…

I've had similar ideas for shedding some much-need light on other similar performance pain points that large corporations are sweeping under the rug via legal means.

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

#128

Post by [deleted] »

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…

[deleted]

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

#129

Post by confluence_perf »

skrap wrote: post #111
confluence_perf wrote: post #73

Earlier quoted context omitted.

Hi ratww, Thank you for reiterating this point, and I'll try to shed some light on this. We actually are working on systemic changes to try to make this lighter/better but I can't talk about specifics until the feature is available. On the other hand, any level of specificity is great, for example: 1) full page loads are slower and more annoying than Transitions (or, vice versa) 2) loading Home page is slower and mor…

If you want to make performance a feature, you need to (in order!) * define a metric * measure it automatically with every commit * define a success threshold * make changes to get yourself under the threshold * prohibit further changes which bring you above the threshold Just do it like that for pretty much every view in the system.

As recommended by another poster to take advantage of the technical community here, I have one question and one comment if you can provide more insights:

question a) My understanding is that performance numbers fluctuate a LOT, even at sampling in the tens of thousands. Do you have any recommendations of tools or methods to reduce this variance?

comment b) we're definitely trying to do this but we're not there yet - most of our metrics don't meet goals we set. Instead the blocking goals must be 'don't make it any worse', which is doable -> but it doesn't necessarily make anything better yet (thus all the questions about what is most annoying that we can fix first).

Hopefully point (b) is clear - I'm not saying "our performance is great/good/acceptable", just the best I can do (as a PM) is try to figure out what to prioritize to fix.

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

#130

Post by smarx007 »

jiggawatts wrote: post #123
mattm wrote: post #122

Earlier quoted context omitted.

As a software engineer who has been woken up in the middle of the night while oncall because some random user wanted to run their own performance tests against our system, I can completely understand why companies want to prevent this from happening without their awareness.

a) That's not the reason. b) Rate limiting is practically mandatory in an era of multi-gigabit client network connections on even mobile phones. Remember: It's not a DDoS attack if it's one user .

Well, an "average" HN user may use something like a load testing tool such as https://github.com/loadimpact/k6 or at least rent a few VMs with 10Gbps links for a few hours and use wrk/ab so I would not be so sure about (a).

Edit: oh, and then they might dust off that Kali Linux VM lying around somewhere...

Post reply on HN