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

91–100 of 305 posts

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

#91

Post by hchz »

grzm wrote: post #83
dylan604 wrote: post #80

Earlier quoted context omitted.

If you need tips or TRICKS to make a product useable, you have a BAD product.

I agree, and I also know that you have to deal with the world as it is right now even while you work to make it better. If you have to use Jira or Confluence at work, you probably want to know how to make that as useful as possible. If you're working at Atlassian, you probably want to make your customer's experience as enjoyable as possible as soon as possible. Ideally you have a great product and great documentation…

Some people don't want to use it at all, and don't care for the situation that C-suite everywhere buys Atlassian's trash.

They don't want minor improvements to help it limp along, they want to vent and complain about it.

I think it's impossible that Atlassian evolves into a good product company, but it's entirely possible that my next CTO googled for opinions on the product, found a few discussions on HN with a combined 3,000 complaints about what a garbage fire it is, and went with Clubhouse.

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

#92

Post by saagarjha »

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…

If you’re being rate limited, try emailing the moderators at hn@ycombinator.com and they might be able to help you.

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

#93

Post by cronix »

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.

Or conversely, some might actually be thankful in the long run for being forced to bite the bullet and to find an alternative which raises productivity/efficiency and as a byproduct, usually a happier work environment.

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

#94

Post by epage »

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…

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 support Markdown in the developer workflow (PRs) but rich-text-only for Tasks (to be non-dev friendly?).

At my current job, I'm involved in developer productivity and have been interviewing people to collect input for where we want to take development. We currently use Phabricator which uses Remarkup. This is a source of frustration because its not quite the markdown they use everywhere else.

From these, I'm thinking Markdown Pages would be the top choice since it allows developer-only interactions and marketing-only interactions to stay within what they are comfortable with,

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

#95

Post by saagarjha »

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…

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 where you support bold and italics but mot much else.

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

#96

Post by redisman »

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

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

#98

Post by confluence_perf »

acdha wrote: post #89
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…

> 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. What do your metrics show? I instrument my web sites so I know how long every operation – server responses, front-end JS changes, etc. – takes and can guide my development accordingly. You have a much larger budget and could be answering this question with hard da…

Hi acdha,

We have metrics, but of course as with many such things you always want more insights than the amount of data you're collecting (so we're always trying to grow this as appropriate).

This data is what led to the above (added edit trying to reply to @rusticpenn) saying we can see that "some instances are slower than others", and "some users are slower than others". I can't share those numbers of course though.

However, privacy reasons does prevent us from collecting too much data, so differentiating why individual users might have different experiences (even when other known factors are similar/identical) is difficult.

Also I'd be happy to take any suggestions you have about what to look at back to my engineering team, if you're willing to share other ideas. I know we're tracking several of the ones you mention but more options is always better.

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

#99

Post by saagarjha »

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

It’s amazing what legal gets away with at most companies and how little actual engineers and management gets to see of this part of their company. I am sure any self-respecting Cloudflare engineer would be horrified to see that this is in their ToS and yet it exists.

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

#100

Post by confluence_perf »

saagarjha wrote: post #95
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…

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.

Post reply on HN