Live data from Hacker News

Jellyfin LLM/"AI" Development Policy

jellyfin.org

101–110 of 112 posts

Re: Jellyfin LLM/"AI" Development Policy

#101
post #38

Earlier quoted context omitted.

Relevant: https://noslopgrenade.com

What do you recommend if I've been regularly producing blog-length posts in Slack for years, no LLM present? It's where I write man...should I quit that out? I try to be information dense...

If you're writing it, that's not a slop grenade. From the page:

> They asked you because they wanted your human judgment.

Re: Jellyfin LLM/"AI" Development Policy

#102
I understand (and largely agree with) the intent behind this policy as written in the Jellyfin LLM guidance: it’s trying to protect contributor and maintainer time by preventing low-effort, unverified, "looks plausible" LLM output being dumped into issues, PRs, and support channels.

That said, I don’t think a blanket "never post LLM-written text" rule is the right boundary, because it conflates two very different behaviours:

  1. Posting unreviewed LLM output as if it were real investigation or understanding (bad, and I agree this should be discouraged or prohibited), versus
  2. A human doing the work, validating the result, and using an LLM as a tool to produce a clear, structured summary (good, and often beneficial).
Both humans and LLMs require context to understand and move things forward. For bug investigation specifically, it is increasingly optimal to use an LLM as part of the workflow: reasoning through logs, reproduction steps, likely root cause, and then producing a concise update that captures the outcome of the investigation.

I worked on an open source "AI friendly" project this morning and did exactly this.

I suspect the reporter filed the issue using an LLM, but I read it as a human and then worked with an LLM to investigate. The comment I posted is brief, technical, and adds useful context for the next person to continue the work. Most importantly, I stand behind it as accurate.

Is it really worth anyone’s time for me to rewrite that comment purely to make it sound more human?

So I do agree with Jellyfin's goal (no AI spam, no unverifiable content, no extra burden on maintainers). I just don’t think "LLM involvement" is the right line to draw. The right line is accountability and verification.

Re: Jellyfin LLM/"AI" Development Policy

#103

I think at some point we will need a "PEP-8" for LLM / AI code contributions document that is universally reusable and adoptable per project, call it an "Agent Policy" or what have you, that any agent worth its Salt should read before touching a codebase and warn the user that their contributions might not be accepted or what have you, depending on project policy, just like we have GPL, BSD, MIT, etc it would probabl…

> that any agent worth its Salt should read before touching a codebase and warn the user that their contributions might not be accepted Are you talking about some agent that is specific for writing FOSS code or something? Otherwise I don't see why we'd want all agents to act like this. As always, it's the responsibility of the contributor to understand both the code base and contributing process, before they attempt…

You can't assume if someone's using a specific model, model has to know to go out of their way to look at a file. I guess I'm saying at the model level, because "agent" files might not even be setup for that person.

Re: Jellyfin LLM/"AI" Development Policy

#104

What's the grief with squashing commits? I do it all the time when I'm working on stuff so that I don't have to expose people to my internal testing. So long as the commit(s) look fine at the end of the day, I don't see what the deal is there.

Seems like both "show your working" and "make it easier for us to review" are the reasons. Seems reasonable to me. "Commit 1: refactor the $THING to enable $CAPABILITY" "Commit 2: redirect $THING2 to communicate with $THING1" "Commit 3: add error handling for $EdgeCase" --- long explanation in commit body A single commit with no commentary just offloads the work to the maintainers. It's their project so their rules.

It's possible to both over-squash and under-squash. You want each commit to do one thing (conceptually), and if you make a lot of in-progress commits, you do want to squash those. But squashing a bunch of related "things" into one commit is too much. The art is in recognizing what one "thing" is.

Re: Jellyfin LLM/"AI" Development Policy

#105
post #31

Earlier quoted context omitted.

> 1) we accept good quality LLM code there is no such thing as LLM code. code is code, the same standards have always applied no matter who or what wrote it. if you paid an indian guy to type out the PR for you 10 years ago, but it was submitted under your name, its still your responsibility.

I don't agree at all. There's a huge difference between "someone wrote this code and at least understands the intention and the problem it's trying to solve" and "the chat bot just generated this code, nobody understands what the intention is". I'm comfortable having a conversation with a human about code they wrote. It's pointless to have a conversation with a human about code they didn't write and don't understand.…

> It's pointless to have a conversation with a human about code they didn't write and don't understand.

this was a problem before LLMs

Re: Jellyfin LLM/"AI" Development Policy

#106

Earlier quoted context omitted.

> that any agent worth its Salt should read before touching a codebase and warn the user that their contributions might not be accepted Are you talking about some agent that is specific for writing FOSS code or something? Otherwise I don't see why we'd want all agents to act like this. As always, it's the responsibility of the contributor to understand both the code base and contributing process, before they attempt…

You can't assume if someone's using a specific model, model has to know to go out of their way to look at a file. I guess I'm saying at the model level, because "agent" files might not even be setup for that person.

My point is, not everyone is using agents to put together ill-checked PRs to contribute to FOSS, I've personally never used it for that, so if the agents suddenly "warn the user that their contributions might not be accepted", I'd probably throw the agent out the window.

Re: Jellyfin LLM/"AI" Development Policy

#107
post #31

Earlier quoted context omitted.

I don't agree at all. There's a huge difference between "someone wrote this code and at least understands the intention and the problem it's trying to solve" and "the chat bot just generated this code, nobody understands what the intention is". I'm comfortable having a conversation with a human about code they wrote. It's pointless to have a conversation with a human about code they didn't write and don't understand.…

> It's pointless to have a conversation with a human about code they didn't write and don't understand. this was a problem before LLMs

It was, and those PRs should be banned too...

Re: Jellyfin LLM/"AI" Development Policy

#108
post #31

Earlier quoted context omitted.

I don't agree at all. There's a huge difference between "someone wrote this code and at least understands the intention and the problem it's trying to solve" and "the chat bot just generated this code, nobody understands what the intention is". I'm comfortable having a conversation with a human about code they wrote. It's pointless to have a conversation with a human about code they didn't write and don't understand.…

> It's pointless to have a conversation with a human about code they didn't write and don't understand. this was a problem before LLMs

Scale can be transformational: getting shot was always bad but when guns lowered the skill requirement and increased lethality wars became even more deadly. LLMs greatly increase the pool of potential scammers and the cost of detecting them.

Re: Jellyfin LLM/"AI" Development Policy

#109

Earlier quoted context omitted.

I am quite obviously blind, but I still stand by my sentiment. I would rather have a "bad" but honest PR body than a machine translated one where the author isn't sure about what it says. How will you know if what it says is what you meant?

突然出現一大段外文文字會讓很多人感到反感。即使不能百分之百確定翻譯準確,大多數使用者仍然更傾向於將其翻譯成英語。

As a native english speaker I don't run into this problem, but in the context of a PR do you think having the original native PR documentation alongside the machine translated documentation would have a similar problem?

Re: Jellyfin LLM/"AI" Development Policy

#110

Earlier quoted context omitted.

Better to use Google Translate for this than ChatGPT. Either ChatGPT massively changes the text and slopifies it, or people are lying about using it for translation only because the outputs are horrendous. Google Translate won't fluff out the output with garbage or reformat everything with emoji.

Google Translate uses GPTs under the hood. GPT was invented by Google’s machine translation team. I think you are misunderstanding my point.

I didn’t say GPTs in general. ChatGPT specifically should be avoided. So many people are posting the most blatant ChatGPT slop full of em dashes and emoji and then claiming they just used it to translate.
Post reply on HN