Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Política de desarrollo con LLM/"IA" de Jellyfin

El auge de los LLM como herramienta de desarrollo útil durante el último año ha sido significativo. El poder y flexibilidad de herramientas como Claude Code y ChatGPT han brindado mucha funcionalidad tanto a desarrolladores experimentados como a nuevos. Pero hay contrapartidas.

El proyecto Jellyfin ha tenido, desde el primer día, un enfoque principal en la calidad del código: legibilidad, simplicidad, concisión. Este es un esfuerzo mayormente manual impulsado por un equipo dedicado de personas, motivado por el deseo de arreglar el código en el que se basa Jellyfin que, sin insistir demasiado, era extremadamente frágil, espaguetizado y propenso a complejidades sobre-ingenierizadas.

Estamos viendo un aumento precipitado de colaboradores que usan IA dentro del ecosistema Jellyfin, tanto en el servidor como en los clientes, así como un aumento en las críticas y preocupaciones sobre los LLM en general. En este momento escribimos esta política para abordar exactamente lo que esperamos y deseamos respecto a contribuciones e interacciones dentro de nuestra comunidad que puedan usar LLM. Estas reglas se aplican a todos nuestros proyectos oficiales y espacios comunitarios.

Directrices generales

1. La salida de LLM está expresamente prohibida para cualquier comunicación directa, incluyendo:

   • issues o comentarios
   • solicitudes de funciones o comentarios
   • cuerpos de pull requests o comentarios
   • publicaciones en foros/chats/etc. o comentarios

   En resumen, si publicas cualquiera de estos elementos, la salida deben ser tus propias palabras, explicación, descripción, etc., no un volcado literal de la salida de un LLM. Esperamos que entiendas lo que publicas. Violar esta regla resultará en el cierre/eliminación del elemento infractor.

   Se hará una excepción para traducciones asistidas por LLM si tienes problemas para expresar tu intención con precisión en inglés. Por favor, indícalo explícitamente ("He traducido esto desde MiIdioma con un LLM") y, si es posible, publica también en tu idioma original.

2. Las contribuciones de código generado por LLM están sujetas a más detalles abajo, pero el principio general es que "el 'código por vibra' puro será rechazado" y "eres responsable de lo que subes". Revisaremos en ese sentido. Si el código se ve terrible, será rechazado como tal.

Contribuciones de código LLM a proyectos oficiales

El uso de LLMs para código es controvertido y abierto a muchas interpretaciones. Estas directrices son nuestro mejor esfuerzo para asegurar que desarrolladores conocedores que buscan usar estas herramientas como ayuda legítima no sean obstaculizados en exceso, mientras prevenimos un flujo constante de contribuciones de baja calidad que violan nuestra ética central. Estas aplican a todos los proyectos oficiales de Jellyfin.

1. Las contribuciones deben ser concisas y enfocadas. Si el PR dice enfocarse en X, pero también modifica Y y Z no relacionadas, será rechazado. Esto incluye cambios incidentales en funcionalidad no relacionada, un sello distintivo de indicaciones mal redactadas o demasiado generales. Igualmente, un PR grande debe dividirse en múltiples commits pequeños y manejables para revisión e historial.

2. Los estándares de formato y calidad deben mantenerse. Comentarios excesivos e inútiles, código espagueti, espacios en líneas vacías, etc., se interpretarán como salida pura de LLM y se rechazarán; debes limpiar el desorden antes de enviar. También no subas metarchivos de LLM (ej. configuraciones .claude) ni ningún otro archivo no-código creado por editores.

3. Debes revisar la salida y poder explicar en el cuerpo del PR - sin usar salida de LLM como se indicó - qué se cambia y por qué. El cuerpo de tu PR (y, si aplica, los cuerpos de los commits) debe brindar contexto a otros desarrolladores sobre por qué se hizo un cambio, y si tu nombre está en él, queremos tus palabras y explicaciones, no las de un LLM. Si no puedes explicar lo que hizo el LLM, no nos interesa el cambio.

4. Los cambios deben estar probados. El código debe compilar y ejecutarse correctamente, o será rechazado. También debes probar explícitamente la funcionalidad modificada.

5. Debes poder y estar dispuesto a gestionar los comentarios de revisión e implementar los cambios sugeridos según sea necesario. En la práctica, esto significa que si no sabes qué se ha cambiado o por qué (ver punto #3) y, por tanto, no puedes implementar los cambios sugeridos ni discutirlos por ti mismo, entonces no estamos interesados en el cambio. Simplemente volcar los comentarios del revisor en un LLM y esperar que lo que salga sea "suficientemente bueno" no es aceptable.

6. Las funcionalidades o refactorizaciones requieren un nivel profundo de comprensión sobre qué se cambia y por qué. Nuestros revisores detectan fácilmente cuando los cambios se realizan sin que el desarrollador comprenda lo que está sucediendo. Estos serán rechazados. Como se indica en el punto #1, el PR debe contener múltiples commits discretos. Nosotros fusionaremos los commits según convenga tras la revisión. Los cambios grandes también deben seguir nuestras demás políticas de desarrollo (discusión, revisión, implementación, proceso de pruebas).

7. La discreción final siempre recae en los revisores. Si tu PR no puede ser revisado razonablemente por cualquier motivo (complejidad excesiva, tamaño, commits fusionados, etc.), será rechazado. Esto aplica tanto para PRs asistidos por LLM como para los que no. Se te pedirá dividir dicho PR en múltiples PRs que presenten cada uno un conjunto de cambios conciso y enfocado.

La regla de oro es esta: no simplemente dejes que un LLM suelto en la base de código con una indicación vaga de "vibra" y luego subas los resultados tal cual. Esto es desarrollo perezoso, siempre resultará en una contribución de baja calidad desde nuestra perspectiva, y no estamos para nada interesados en tales chapuzas. Haz un esfuerzo o por favor no te molestes. Y nuevamente, eres libre de usar LLMs para asistirte, pero no como la única fuente de cambios de código.

Herramientas, clientes, etc. generados por LLM compartidos en la comunidad

Por supuesto, eres libre de hacer lo que quieras en tus proyectos no oficiales. Sin embargo, aplicaremos las siguientes reglas para cualquier compartición de dichos proyectos en nuestras comunidades.

1. Cualquier proyecto desarrollado principalmente por LLM debe marcarse claramente como tal. Corresponde a los usuarios decidir si les resulta aceptable o no. Si usaste un LLM para asistencia secundaria (ej. documentación, formato, etc.) de manera obvia, recomendamos también divulgarlo.

2. Debes respetar y seguir las licencias. Si basas tu proyecto en código existente, seguir su licencia no es opcional. Debes acreditar completamente a los contribuyentes originales por todas sus contribuciones. No distorsiones el historial de Git, y no commites cambios pendientes de terceros como propios (ej. copiando el código y luego cometiéndolo). Hacerlo resultará no solo en rechazo, sino en expulsión de nuestra organización y comunidad. Tenemos tolerancia cero con el robo de código y los intentos de atribución de mala fe.

3. Para miembros de la comunidad: no reportes herramientas, clientes, etc. generados por LLM únicamente por ese motivo, y no participes en "cazas de brujas" anti-LLM. Como se mencionó, esto está permitido y es tu elección "apoyar" dicha herramienta/cliente/etc. o no.

4. Nosotros, los moderadores, no actuaremos como "policía de LLM" para proyectos de terceros escudriñando en busca de "contribuciones de LLM" que por lo demás sigan nuestras reglas; esto es tedioso y desperdicia nuestro tiempo y esfuerzo. En la práctica, la aplicación de la regla #1 depende del autor, y la regla #3 debe interpretarse en ese sentido. Si sospechas que una herramienta es generada por LLM y viola la regla #1, entonces ignórala o vótala negativamente y sigue adelante. Solo si vemos una violación flagrante de la regla #1 la aplicaremos, pero nuevamente no revisaremos código línea por línea jugando a "¿fue esto generado por LLM?". La regla #2 siempre se aplicará, independientemente del uso de LLM.