Doorgaan naar hoofdinhoud
Onofficiële Beta-vertaling

Deze pagina is vertaald door PageTurner AI (beta). Niet officieel goedgekeurd door het project. Een fout gevonden? Probleem melden →

Jellyfin LLM/"AI"-ontwikkelingsbeleid

De opkomst van LLM's als nuttig ontwikkelingsinstrument in het afgelopen jaar is aanzienlijk geweest. De kracht en flexibiliteit van tools zoals Claude Code en ChatGPT bieden veel functionaliteit voor zowel ervaren als nieuwe ontwikkelaars. Maar er zijn ook keerzijden.

Het Jellyfin-project heeft vanaf dag één sterk gefocust op codekwaliteit - leesbaarheid, eenvoud en beknoptheid. Dit is vooral een handmatig proces gedreven door een toegewijd team, gemotiveerd door de wens om de code waar Jellyfin op gebaseerd is te verbeteren. Zonder er te veel op in te gaan: die code was extreem fragiel, spaghettificatie vertonend en gevoelig voor over-engineerde complexiteit.

We zien een sterke toename van bijdragers die AI gebruiken binnen het Jellyfin-ecosysteem, zowel voor de server als clients, en tegelijk meer kritiek en zorgen over LLM's in het algemeen. Daarom stellen we dit beleid op om duidelijk te maken wat we verwachten van bijdragen en interacties in onze community waar LLM's mogelijk worden gebruikt. Deze regels gelden voor al onze officiële projecten en community-ruimtes.

Algemene richtlijnen​

  1. LLM-output is strikt verboden voor directe communicatie, inclusief:

    • issues of opmerkingen
    • functieverzoeken of reacties
    • pull request-beschrijvingen of reacties
    • forum-/chatberichten of reacties

    Kortom: als je iets post, moet de output in je eigen woorden zijn - uitleg, beschrijving, etc. - geen letterlijke dump van LLM-output. We verwachten dat je begrijpt wat je post. Overtreding leidt tot sluiten/verwijderen van het desbetreffende item.

    Een uitzondering geldt voor LLM-ondersteunde vertalingen als je moeite hebt je intentie nauwkeurig in het Engels over te brengen. Vermeld dit expliciet ("Ik heb dit uit MijnTaal vertaald met een LLM") en post indien mogelijk ook in je oorspronkelijke taal.

  2. LLM-codebijdragen hebben gedetailleerdere regels hieronder, maar het basisprincipe is: "puur 'vibe coding' wordt afgewezen" en "je bent verantwoordelijk voor wat je commit". We reviewen in die lijn. Als de code er slecht uitziet, wordt deze zo afgewezen.

LLM-codebijdragen aan officiële projecten​

Het gebruik van LLM's voor code is controversieel en vatbaar voor interpretatie. Deze richtlijnen zijn onze poging om ervaren ontwikkelaars die deze tools legitiem willen inzetten niet te belemmeren, terwijl we een stortvloed aan slordige bijdragen die onze kernethos scheden voorkomen. Dit geldt voor alle officiële Jellyfin-projecten.

  1. Bijdragen moeten beknopt en gericht zijn. Als een PR beweert X aan te pakken maar ook ongerelateerde Y en Z wijzigt, wordt deze afgewezen. Dit omvat toevallige wijzigingen aan ongerelateerde functionaliteit - een kenmerk van slecht geformuleerde prompts. Grote PR's moeten opgesplitst worden in kleine, beheersbare commits voor review en geschiedenis.

  2. Formattering en kwaliteitsstandaarden moeten gehandhaafd blijven. Overmatige nutteloze commentaar, spaghetti-code, spaties op lege regels, etc. worden gezien als pure LLM-output en afgewezen; je moet de rommel opruimen voor indiening. Commit geen LLM-metabestanden (bijv. .claude-configs) of andere door editors gemaakte niet-codebestanden.

  3. Je moet de output reviewen en kunnen uitleggen in de PR-beschrijving - zonder LLM-output zoals hierboven beschreven - wat er wordt gewijzigd en waarom. Je PR-beschrijving (en commits) moet context bieden aan andere ontwikkelaars over wijzigingen, en met jouw naam erop willen we jouw woorden en uitleg, niet die van een LLM. Als je niet kunt uitleggen wat de LLM deed, zijn we niet geïnteresseerd in de wijziging.

  4. Wijzigingen moeten getest zijn. De code moet correct bouwen en draaien, anders wordt deze afgewezen. Test expliciet de gewijzigde functionaliteit.

  5. Je moet in staat en bereid zijn om feedback tijdens de review te verwerken en de voorgestelde wijziging(en) door te voeren. In de praktijk betekent dit: als je niet begrijpt wat er is gewijzigd of waarom (zie punt #3), en dus niet zelf de voorgestelde wijzigingen kunt doorvoeren of bespreken, dan zijn we niet geïnteresseerd in de wijziging. Het simpelweg dumpen van reviewer-feedback in een LLM en verwachten dat de output "goed genoeg" is, voldoet niet.

  6. Nieuwe functies of refactoringen vereisen diepgaand inzicht in wat er wordt gewijzigd en waarom. Onze reviewers merken direct wanneer wijzigingen zijn gemaakt zonder dat de ontwikkelaar begrijpt wat er gebeurt. Deze zullen worden afgewezen. Zoals aangegeven in #1, moet de PR meerdere afzonderlijke commits bevatten. Wij zullen commits samenvoegen waar nodig na de review. Grote wijzigingen moeten ook voldoen aan onze andere ontwikkelingsbeleidsregels (discussie, review, implementatie, testproces).

  7. Het laatste oordeel ligt altijd bij de reviewers. Als je PR om welke reden dan ook niet redelijk kan worden beoordeeld (overcomplexiteit, omvang, samengevoegde commits, enz.), wordt deze afgewezen. Dit geldt net zo goed voor niet-LLM-ondersteunde PR's als voor LLM-ondersteunde PR's. Je wordt gevraagd om zo'n PR op te splitsen in meerdere PR's die elk een gerichte, beknopte set wijzigingen presenteren.

De gouden regel is deze: laat een LLM niet zomaar los op de codebase met een vage, onduidelijke prompt om vervolgens de resultaten ongewijzigd te committen. Dit is luie ontwikkeling, resulteert altijd in een bijdrage van slechte kwaliteit vanuit ons perspectief, en we zijn totaal niet geïnteresseerd in zulke rommel. Doe moeite of doe liever geen moeite. Nogmaals, je bent vrij om LLM's te gebruiken om je te ondersteunen, maar niet als enige bron van codewijzigingen.

LLM-gegenereerde tools, clients, etc. gedeeld in de community​

Je bent uiteraard vrij om te doen wat je wilt met je eigen niet-officiële projecten. Wel hanteren we de volgende regels voor het delen van dergelijke projecten binnen onze communities.

  1. Projecten die primair door LLM's zijn ontwikkeld, moeten duidelijk als zodanig worden gemarkeerd. Gebruikers beslissen zelf of ze dit acceptabel vinden. Als je een LLM hebt gebruikt voor secundaire ondersteuning (bijv. documentatie, opmaak, enz.) op een duidelijke manier, raden we ook aan dit te vermelden.

  2. Je moet licenties respecteren en volgen. Als je voortbouwt op bestaande code, is het volgen van de licentie verplicht. Je moet bestaande bijdragers volledig crediteren voor alle bijdragen. Verval de Git-geschiedenis niet en commit geen uitstaande wijzigingen van derden als jouw eigen werk (bijv. door code te kopiëren en te committen). Dit leidt niet alleen tot afwijzing, maar ook tot een ban uit onze organisatie en community. We hanteren een nultolerantiebeleid voor codetheft en pogingen tot kwaadwillige attributie.

  3. Leden van de community: meld LLM-gegenereerde tools, clients, etc. niet alleen op basis hiervan, en ga niet op anti-LLM-"heksenjacht". Zoals hierboven vermeld, is dit toegestaan en is het jouw keuze of je dergelijke tools/clients wilt "ondersteunen".

  4. Wij, de moderators, gaan niet de "LLM-politie" uithangen voor projecten van derden door muggenziften om "LLM-bijdragen" te vinden die verder aan onze regels voldoen; dit is vervelend en verspilling van onze tijd. In de praktijk betekent dit dat regel #1 aan de auteur is, en regel #3 in die context moet worden geïnterpreteerd. Als je alleen vermoedt dat een tool LLM-gegenereerd is en regel #1 overtreedt, stem dan tegen/negeer het en ga verder. Alleen als we flagrante overtredingen van regel #1 zien, zullen we ingrijpen. We gaan geen code regel voor regel nalopen voor het "is dit LLM-gegenereerd?"-spelletje. Regel #2 wordt altijd gehandhaafd, ongeacht LLM-gebruik.