Atlassian enables default data collection to train AI(letsdatascience.com) |
Atlassian enables default data collection to train AI(letsdatascience.com) |
It seems like the real bottleneck is something else.
So a private repo should be safe, as long as you don't use copilot. While Atlassian wants to pull in data from private issue trackers/wikis.
GitHub does not have any of its own models. It routes to partners like OpenAI. Just because some data is from private repos, doesn’t mean all data is flowing nor does it mean it should be trained on just because it’s being inferences on, and there is a difference on the data that was used vs. all the data from that repo, and difference between just that repo vs. all private repos. And they made it all opted in as default. Draconian.
So yes, they did set a precedent and you’re here arguing why it’s okay.
Thanks for showing your colors so clearly Atlassian. Good riddance.
I am 100% supportive of it being used for training... AI, you, everyone.
The guy who has to keep it running day by day, next to the other 30 local-first systems.
- Bitbucket workers are hopelessly out of date (self hosted). We've had to put so many random workarounds in especially for Docker, as they don't keep them up to date enough
- I have had a bug in JIRA for years where I can't reorder a new ticket unless I refresh the page
- Every new feature they introduce into JIRA/Bitbucket over the past couple of years just doesn't work.
- I tried their AI stuff on the free trial, didn't work at all, tried to cancel, can't cancel the free trial online and had to write a load of support tickets (of which the support ticket contact form bugged out multiple times).
Anyone have any insight into why things have got so so dysfunctional? Tech debt? Talent leaving? Both? Even 'bad' enterprise software tends to be able to keep the most basic features running, but Atlassian is a whole new category. If you check their 'community' it is just hundreds/thousands of bugs with workarounds.
Absolutely insane that this is legal. The only reason to do this is to trick and abuse customers. It would be trivially easy to legislate away if our government cared to.
Atlassian seems like a typical entrenched big company, albeit an extreme example. They make money by selling to the bosses of their users and being the default name brand for many cases. Once a company gets to a certain size and doesn't directly compete much on quality internal corruption and incompetence can run rampant.
This affliction happens to almost every company, eventually. Nobody seems to have solved this.
I'm not sure how enterprise works though.
No one is focused on quality of the feature. It is all about speed. No one stops and thinks that may be users doesn't care about it. Data science teams are focused on cherry-picking data in a way that shows positive impact to show to the leadership that things are working. Engineers and teams are disincentivized to improve existing features, performance issues(unless it impacts revenue/some enterprise customer complains) and sometimes being punished for it. They are also steadily downsizing their support teams to cut costs.
Things are not going to improve. You should move away.
Even in mid-sized projects if you keep pushing for only new features you'll get a similar system. At least my experience in 3 or so midsized projects that I've worked on where nothing else mattered than checking of features from a huge backlog.
I don't have to switch to the browser most of the time!
I guess it's "good" to know that I'm not alone.
The amount of times I've searched for a ticket that I know it's there (because I either have it opened in a different tab, or because I just created it), but can't find, it's just way to many.
Gotta love the value that vibe coding has added to this world.
My theory is that there is no incentive for things to not be dysfunctional. At my org anyway Atlassian is almost as entrenched as Google, and we can't even conceive of using something different.
I use plane.so for personal projects after learning about it here. It's a lot simpler and the UI takes some getting used to, but it's fast and it works.
The migration would take 1-2 engineering man-days I suppose. But its money well spent.
Not surprised. Quote „…with significant institutional ownership from Vanguard, BlackRock, and others”.
You yourself just admitted that you still use their products often.
Jira is garbage (frontend, backend). Tough but true.
All your Confluence pages, Jira tickets, etc.
https://support.atlassian.com/security-and-access-policies/d... describes how to disable this, but it also appears that the setting to disable this doesn't exist (it's not visible on any of our instances).
One is a policy decision you can argue about. Both together suggest the friction is intentional.
The data residency point is worth flagging separately - a lot of enterprise buyers treat region-pinning as a privacy guarantee for everything in their contract. It was never that. Residency tells you where data is stored at rest, not who can access it for what purpose.
“If customers were to right now terminate their contract, the new data contribution settings will not apply to them as these will not be enforced until August 17, 2026,” (from https://www.theregister.com/2026/04/18/atlassians_new_data_c...)
So you can't even take a bit of time to consider your options.
And the specs become the new source (code).
fast forward..
Atlassian etc hold source specs -> scraped -> so AI may generate any of that.. then any of above..
the new source would be (?what? company missions? get-rich-quick-schemes?)
fast forward..
For stuff that I don't particularly care about privacy I've kept on the cloud (e.g. my blog, which is public anyway and as such is probably training bots regardless), but for stuff that I don't want to be used to train their models and/or sell to advertisers I have moved to be self hosted on my own network.
we're not far off it being good enough but it's not there yet.
cloud repos are handy, but, having to constantly worry if some criminal comes "joinks, its my data now", is not worth it.
[1] https://gitlab.com/jeremygonyea/jira-to-gitlab-migration-too...
"Tseytlin said that some Atlassian customers are completely excluded from metadata or in‑app "data contribution" entirely. This includes those who use customer-managed keys, or bring your own key, Atlassian Government Cloud, or Atlassian Isolated Cloud users. He said Atlassian will also not collect metadata or in-app data from customers with HIPAA compliance requirements or from some government and financial services customers."
https://www.theregister.com/2026/04/18/atlassians_new_data_c...
Atlassian: "Yolo!"
>rsyncrypto is a utility that encrypts a file (or a directory structure) in a way that ensures that local changes to the plain text file will result in local changes to the cipher text file. This, in turn, ensures that doing rsync to synchronize the encrypted files to another machine will have only a small impact on rsync's wire efficiency.
https://manpages.ubuntu.com/manpages/focal/man1/rsyncrypto.1...
I've lost count of how many times I search for a keyword and get no relevant results, but the document I'm looking for, which contains the keyword, is in my automatic pop-up of recent documents visited.
I got this info from an email they sent out
>To give you control over this change, we're introducing new in‑app settings that allow you to manage in‑app data contribution. Initially, these settings will apply to data in Jira, Confluence, and Jira Service Management, including data in your Atlassian Platform apps (Rovo, Home, Teams, Projects, Assets, Goals, Analytics, and Administration). We'll notify you when settings become available for additional apps you own, so you can review them in Atlassian Administration. Between today and May 19, 2026, we'll gradually roll out these settings in Atlassian Administration. We'll send you another email on May 19th as a reminder, so you have time to review and make any adjustments before August 17, 2026.
Not that they'd ever do that of course. Nobody with highly sensitive information about rival companies would ever do that.
Yes. Industrial espionage made easy.
So, is this an automatic opt-in without the ability to opt-out?
It's not just metadata, it's all "in-app data"
To get value out of Rovo, it needs detail. Your over-subscribed Jira power user/admin can't effectively make it happen. No guarantees Atlassian (Rovo itself) can make it happen either, but the patterns are going to develop and evolve closer and closer to the Agents that make the features.
They have a peculiar definition of Metadata, however. It's a proprietary data product derived from user content. It's a bit shit they way they sell it as metadata. It's a derivation. It's a product of Content, so it's Content - privacy safeguards cannot begin to cover the variation.
\"Metadata includes two data types referred to as content attributes and common patterns.
Content attributes are statistical characteristics, numeric fields, and derivatives of your in-app data. Examples of content attributes may include the number of story points assigned to a Jira work item or the complexity of a Confluence page. Common patterns are phrases, keywords, and topics we extract from search queries and results, Rovo Chat (conversations, prompts, and responses), and custom configuration data that are frequently seen across many customers, while omitting rare data that may be unique to your organization. Examples of common patterns may include common words, phrases, or Rovo Chat prompt topics that are frequently used by customers, such as “vacation policy” or “recap team activity.”\"
So let me guess, they're hoping that we forget about this by then, so that they can scoop up our data? I can't think any other reason for it.
Until they finish evaluating competitors, and eventually migrate to .... something, they are completely stuck. Jira is at the heart of all of their workflows and they cannot and will not move to cloud. This was an Atlassian partner, but they got screwed over on that part as well.
FWIW Github has similar shitty search interface. Not sure why.