I think the graph is not the best representing the phenomena. Probably accuracy = 1.0 is possible only when amount of properties = 0, because even with one property there is a chance employee won't bother enough to input it right knowing how terrible tool JIRA is. IOW, filling even one property to a task in JIRA is such a terrible experience, that people likely will put random data just to shorten the exposure to this horrible interface.

The accuracy of information added to Jira tasks by employees is inversely proportional to amount of detailed information being asked by managers to put there. So called overeager manager law, aka krzk's principle.

@lwn I love the timeline of initial disclosure to Cline:
https://adnanthekhan.com/posts/clinejection/#timeline

"January 1st, 2026: GHSA submitted via private vulnerability reporting on github.com/cline/cline. Same day, email sent to security@cline.bot ..."

January 8th, 2026: Follow-up email sent ... No response received to my email.

January 18th, 2026: Attempted direct message to Cline’s CEO on X with request to review the GHSA containing technical details. No response.

February 7th, 2026: Final attempt — new email to security@cline.bot, no response...

February 9th, 2026: Public disclosure via blog post."

Can we agree that Cline screwed so badly they should never be trusted again as software vendor? Ah, who am I kiddin, that's probably SW workflows managed by AI, so no one cares...

@broonie @monsieuricon Yep, most of them had at least one useful comment. The problem is that if SoC platform maintainer sends review with three comments of which two are correct and one is wrong, how can an unaware contributor figure out which one is right...
Well, the one about the copyright time is obvious and it simply should not have been sent.

Review on mailing list:

Copyright (C) 2026 Variscite Ltd. AI bot review and may be useless.

Copyright year is 2026, which is in the future. Should be 2024 or current year.

Great, now everyone will get to read useless AI agent reviews.

https://lore.kernel.org/all/20260303210131.2966214-8-Frank.Li@nxp.com/

@geert I'll Cc you on my complain / discussion with LF.

@z3ntu Crappy hell, what a PyTorch mess.

@okias There should be a "I am a tourist" checkbox when doing reviews :)

Every Google Maps review score in Germany is fake. Believe me.

Well, it does not have to be truly fake, but because of lack of negative reviews, what you have is score built only on positive experiences + advertisements.

Two of my honest, not defaming, describing real experience, negative (1-star and 2-star) reviews of two places in Munich from some visit in 2023 got removed by "defamation" process. It's the process where you as customer can do nothing, your review will be gone and Google will completely ignore your appeals.

I can assume that many or even most of negative reviews older than 2 years will be just removed by Google using this German defamation process, leaving only positive ones.

In the same time these places have many 5-star review written by agencies, posting similar AI-generated ludicrously exaggerated poetry, which obviously no one will ever drop, because they are not a defamation.

So please remember - Google Maps in Germany is full of crap reviews.

@geert And PyTorch needed it for ... ? :)

And pasting here my response for reference:

Thank you for responding and caring about this matter. It partially resolves the problem, but unfortunately only partially.

Email address of EU individual, like me or few other maintainers who confirmed that they received mentioned PyTorch Foundation mailing, is personal data thus protected by GDPR. Public availability of that address does not remove GDPR protection.

Therefore according to GDPR, neither the PyTorch Foundation, the Linux Foundation EU nor the Linux Foundation, was allowed to create the “list intended for technical cross-referencing”. You cannot harvest these emails, even if you do not intend to send advertising material.

Removal of harvested emails from marketing databases is of course correct, but insufficient. Linux Foundation and PyTorch Foundation should remove ALL HARVESTED emails from all other databases, including from the “list intended for technical cross-referencing”.

GDPR applies not only to Linux Foundation EU, but also to PyTorch Foundation which operates in EU. Specifically, the advertisement spam sent by PyTorch Foundation was about conference “PyTorchCon Europe 2026” it held/is holding in Paris, France. thus clearly it operated in EU. The emails were belonging to identifiable individual (e.g. me) and EU residents (e.g. also me), thus meeting all conditions necessary to trigger GDPR protection of personal data.

I received answer from Linux Foundation, apologizing for what happened explaining a bit with: "This occurred due to an internal marketing
operations error where a list intended for technical cross-referencing was
inadvertently marked as a mailable promotional list."

There is no explanation how the "technical cross-referencing" was created, but I assume that list is result of harvesting/scrapping addresses from available sources. Email address, even publicly exposed, is personal data, according to GDPR. Public availability does not remove GDPR protection.

The PyTorch Foundation therefore did not have right to collect these addresses.

Linux Foundation in reply to me stated they ONLY remove the addresses from marketing lists. They did not confirm that they removed the addresses from "list intended for technical cross-referencing", thus I find the the answers not satisfying.

If you're a swiss resident ( or know one ... ) you can get a custom hardware design onto an ASIC for FREE !!!

You get back one chip with your design (and a bunch of others!) and some board to help bring up/testing.

Also, this is "resident", no need to be a student or at uni or anything, you just need a valid Swiss address ...

I know I might be repeating myself here because I mentioned it a few month back but this bear repeating IMHO.

https://swisschips.ethz.ch/news-and-events/tiny-tapeout-submission-form.html

PS: Can I haz boost for reach ?

@monsieuricon Nice joke, but I am afraid it might be actually true...

@geert @arnd I sent email to helpdesk at korg, but obviously it's not korg issue.
IMO, harvesting emails and creating such database of involuntary subscribers by Linux Foundation project is absolutely not acceptable. @lfeurope @linuxfoundation should be THE example in standards for data privacy and compliance.

@ablu @arnd Harvesting from Github is not particularly better...

And now I see that PyTorch Foundation has been doing this for longer - I see at least one more mailing (to the same address from kernel sources) on 4th of February.

I would write them email with a complain, but contact form on https://www.linuxfoundation.org/about/contact simply does not work - clicking button "Submit" is a no-op.

I just got spam email from PyTorch Foundation / Linux Foundation to my email address used purely in Linux kernel sources and LKML. Email not passed to anyone, not even used as reply/from ever, not used on conferences (so not scan badging) so PyTorch Foundation <pytorchevents@linuxfoundation.org> apparently just grabbed it from kernel sources or kernel mailing list to create database of users for spam mailing.

Such a disappointment @lfeurope @linuxfoundation

@palmer How "low" alcohol did you get? Worth trying...