Jira es Turing-completa

 (seriot.ch)
2 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Jira Automation puede representar una máquina de Minsky con dos contadores infinitos y un estado finito de instrucciones, lo que permite demostrar la completitud de Turing de Jira
  • El estado de un Epic funciona como contador de programa, y la cantidad de Bugs y Tasks enlazados actúa como los dos registros; las reglas de Automation forman la tabla de despacho por instrucción
  • INC y DEC se implementan creando o eliminando issues enlazados, y la bifurcación condicional se decide inspeccionando la cantidad de issues enlazados mediante reglas condicionales JQL
  • El ejemplo de suma, con A=2 y B=3, reduce Bugs y aumenta Tasks hasta llegar a 5 Tasks y a un estado de detención en una ejecución real sobre *.atlassian.net
  • El ejemplo de Fibonacci reduce los bucles usando conversión de tipos de issue, y cuando alcanza el límite de profundidad de cadena de 10 de Jira Cloud, puede continuar con un re-disparo manual

Máquina de Minsky construida con automatización de Jira

  • Jira Automation puede representar una Minsky register machine con dos contadores infinitos y un número finito de estados de instrucción, por lo que es posible una reducción que demuestra la completitud de Turing de Jira
  • El modelo que Minsky demostró en 1967 se compone solo de INC r; goto S y if r == 0 goto S else (DEC r; goto S')
  • Los componentes de Jira corresponden a cada elemento de la máquina de Minsky
    • Registro A: cantidad de issues Bug enlazados
    • Registro B: cantidad de issues Task enlazados
    • Contador de programa: estado de un único issue Epic
    • Tabla de despacho: reglas de Jira Automation por estado de instrucción
    • Reloj: transición disparada por la automatización o re-disparo externo después del límite de cadena
  • El estado del Epic codifica la instrucción actual, y las Automation rules inspeccionan la cantidad de issues enlazados para hacer la transición al siguiente estado
  • INC y DEC se implementan creando y eliminando issues enlazados del tipo correspondiente, y la bifurcación condicional se maneja con reglas condicionales JQL

Ejemplos de ejecución y limitaciones

  • El programa de suma se compone como un programa de Minsky que reduce A mientras incrementa B 
    1. if A == 0 goto 3 else (DEC A; goto 2)
2. INC B; goto 1
3. HALT
  • La implementación mínima se compone de un Epic, 5 issues enlazados y una regla de Automation por cada estado de instrucción

  • Flujo de trabajo y reglas

    • En el Workflow de Jira se crean el estado inicial BACKLOG y luego TODO, DEV, PROD, configurando que todos los estados puedan transicionar entre sí
    • Se crea un Epic en estado BACKLOG
    • La regla de TODO implementa DEC A; if A=0 halt, else goto DEV
      • Se dispara cuando el estado del Epic cambia a TODO
      • Si hay al menos un Bug enlazado, elimina un Bug y transiciona el Epic a DEV
      • Si no hay Bugs, transiciona el Epic a PROD para detenerse
    • La regla de DEV implementa INC B; goto TODO
      • Se dispara cuando el estado del Epic cambia a DEV
      • Crea un nuevo Task y lo enlaza al Epic
      • Transiciona el Epic a TODO
    • En ambas reglas está activada la opción "Allow rule to trigger other rules"

  • Valores iniciales y resultado

    • Se inicializa A=2, B=3 enlazando 2 Bugs y 3 Tasks al Epic
    • Al transicionar el Epic a TODO, se ejecuta en cadena el siguiente flujo 
      (2,3) TODO →
(1,3) DEV  →
(1,4) TODO →
(0,4) DEV  →
(0,5) TODO →
(0,5) PROD
    • Se ejecutó en una instancia real de *.atlassian.net, y al final el Epic llega a PROD con 0 Bugs y 5 Tasks enlazados
    • Esta ejecución es el resultado de calcular 2 + 3 = 5 con la automatización de Jira

  • Configuración de Fibonacci

    • Convert Issue Type puede cambiar de inmediato el tipo de un issue, por ejemplo de Bug → Story o de Story → Task
    • CONVERT puede expresarse como DEC + INC, así que no amplía la capacidad computacional, pero reduce la tabla de despacho de los bucles de movimiento y facilita manejar programas más complejos
    • Fibonacci se expresa como (A, B) → (B, A+B) y se compone de tres registros A=Bug, B=Task, C=Story y tres estados TODO, QA, DEV 
      TODO:
    if any linked Task exists:
        CONVERT Task → Story
        INC Bug
        transition to TODO
    else:
        transition to QA

QA:
    if any linked Bug exists:
        CONVERT Bug → Task
        transition to QA
    else:
        transition to DEV

DEV:
    if any linked Story exists:
        CONVERT Story → Bug
        transition to DEV
    else:
        transition to TODO
    • El estado inicial es A=1, B=1, C=0, y en B, que corresponde a la cantidad de Tasks, aparece la sucesión 1, 1, 2, 3, 5, 8, 13, ...
    • A diferencia de la máquina de suma, la máquina de Fibonacci no tiene estado de detención y se ejecuta hasta alcanzar el límite de profundidad de cadena de 10 en Jira Cloud
    • Al llegar a ese límite, un operador puede volver a disparar el Epic para continuar, y con una sola edición de estado la ejecución en cadena se reinicia
    • Jira Data Center expone automation.rule.execution.timeout y configuraciones relacionadas como propiedades configurables
    • Suponiendo creación infinita de issues y ejecución infinita de reglas, el lenguaje de automatización de Jira puede codificar una máquina de dos contadores, y bajo el criterio habitual de que las computadoras físicas también son finitas, las cuotas finitas de Jira Cloud no refutan esta construcción

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Comentarios de Hacker News

  • Jira es tan absolutamente terrible que tiene el potencial de transformarse en cualquier otra forma de terribilidad

    • Jira es el caso definitivo del concepto de alienación
      Si Marx hubiera conocido Atlassian, el Grundrisse habría ardido intensamente
    • Lo peor es que todas las empresas que hacen productos de gestión de trabajo terminan yendo en dirección a Jira
      Basta con comparar GitHub Issues de 2014 con lo que es ahora: https://github.com/features/issues
      Y siguen, siguen, agregando funciones duplicadas

  • Jira es popular y también tiene buenos wrappers de API para el lenguaje que prefieras
    Sorprende que los desarrolladores corporativos con espíritu hacker no hayan automatizado ya la mayor parte de lo que Jira les pide hacer con algo como scripts de línea de comandos en Python
    Si logro que sea más de un orden de magnitud más fácil de usar que quienes imponen Jira, el tablero se da vuelta, y Jira se convierte en una herramienta que se empuja para protegerse a sí misma
    A veces he usado Jira de forma casi maliciosa, y es excelente para evadir responsabilidades
    Cuando surge un problema, basta con decir: “Esto estaba claramente escrito en los cientos de actualizaciones de Jira que puse; sí las estaban leyendo, ¿verdad?”
    Ahora que también hay IA, solo hay que unirlo todo con scripts personalizados y dejar que la IA haga el trabajo tedioso de Jira

    • Mucha gente ya hizo algo así, pero el problema es que cada instancia de Jira es un copo de nieve fractal de propiedades personalizadas con migraciones viejas fallidas y nuevas estrategias organizacionales apiladas en capas
      Muchas veces la API puede hacer cosas que la UI no permite, y como todo el mundo se guía por la UI, uno termina en rincones raros y rotos
      Por ejemplo, podrías no darte cuenta de que custom_field_5537 tiene que ir emparejado con custom_field_442 para que aparezca en el dashboard de otra persona
      Además, custom_field_10995 dice ser un campo entero y también se devuelve como entero en XML, pero al crear una tarea exige usar una cadena de constante mágica no documentada, y al actualizarla ya no hace falta
      La UI web no hace eso, y en el HTML y en las solicitudes simplemente va un entero, mientras que solo el 80% de la cadena coincide con el texto mostrado en el desplegable
      La automatización de Jira fue la peor experiencia de programación que he tenido
      Seguro existen configuraciones más simples y hasta pueden ser bastante fáciles, pero aun así es demasiado
      Tristemente, el esfuerzo sigue valiendo totalmente la pena. Lo recomiendo muchísimo
    • En un lugar donde trabajé antes, hicimos varias herramientas para ahorrar tiempo con la API, y todas eran pequeños scripts de shell
      Agregábamos a cada ticket un campo de texto personalizado para una descripción legible por humanos, y cuando se desplegaba una release, el script de despliegue llenaba automáticamente la marca de tiempo
      Liberábamos un ticket por unidad de trabajo y procesábamos varios tickets al día
      Combinado con filtros personalizados, Jira daba un changelog legible por humanos para cada board y para toda la empresa, y esos mensajes se enviaban por Slack al lado de negocio para que todos supieran qué se estaba desplegando
      También servía como un registro de auditoría de releases consultable y vinculado a cambios de código
      El proceso de despliegue también cambiaba el estado de los tickets en Jira, así que el desarrollador solo tenía que hacer merge del ticket a main y quedaba desplegado y completado en Jira
      También había muchos scripts pequeños que generaban automáticamente tickets para trabajos repetitivos
      Fue muy sólido durante años, y probablemente siga funcionando hoy
      La convención de nombres de los campos personalizados no era gran cosa, pero si el equipo controlaba la configuración de Jira, no era difícil mantener el mismo criterio para todo
      Al principio no me gustaba Jira y hace mucho tenía muchos problemas, pero hoy en día, si lo configuras bien, no está tan mal
      No lo elegiría para mi propia empresa, pero habiéndolo usado como desarrollador, administrador, usuario final y desarrollador de herramientas internas, una vez que queda configurado y empieza a funcionar, por lo general no estorba
    • “Unirlo todo con scripts personalizados y dejar que la IA haga el trabajo tedioso de Jira” suena como si la hinchazón de Jira todavía no fuera suficiente
      Si le agregas más texto, Jira de alguna manera va a intentar ejecutar automáticamente todo sobre todo ese texto, así que se volverá más lento
      Si tu empresa necesita calefacción, usa Jira
    • Hace muchísimo tiempo nos cambiamos a JetBrains YouTrack, y hacemos este tipo de cosas con su API
      Es bastante flexible, y con la IA se ha abierto todavía más
    • Toda nuestra empresa básicamente funciona sobre Jira
      La mayoría de los procesos dependen de Jira, y ciertas transiciones disparan webhooks para automatizaciones
      Una de las primeras cosas que hice en cuanto obtuve acceso a IA fue crear un Jira MCP
      Ahora trato de casi no tocar Jira directamente, y le pido a Claude que cree issues de Jira, escriba comentarios, cree subtareas, vincule issues, etc.
      Antes me daba miedo cada vez que tenía que investigar cómo implementar algo y dividirlo en tareas
      Porque mientras más fino lo desglosara, más issues de Jira tenía que crear para contener cada tarea
      Ahora simplemente lo organizo todo en un archivo y le dejo el trabajo tedioso de Jira al modelo de lenguaje grande

  • Volví a un lugar donde había trabajado antes y seguían usando JIRA
    En la entrevista, obviamente dije: “Ah, ¿JIRA? ¿Todavía usan eso? Sí, puedo usarlo”
    Y sí, realmente podía usarlo, pero ver la versión más reciente de JIRA fue un verdadero shock
    Tiene como mil molestias pequeñas, y una de las peores es que cuando intentas seleccionar texto con doble clic, de repente el campo entra en modo de edición
    Lo que yo recordaba era JIRA Server 4.0, y aquí se puede revivir ese recuerdo: https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
    Si haces suficiente zoom, cada issue tenía título, tipo, versión corregida, versión afectada, etc., y la estructura llevaba directamente a los comentarios. Era muy simple

    • Lo del doble clic que entra en modo edición es totalmente cierto
      Es desesperante. Incluso algo tan básico como la manipulación de texto está mal hecho
      Pero un gerente de proyecto dijo que le gustaba
      Porque no usa doble clic y arrastre para seleccionar una palabra completa
      Como siempre, por la comodidad de gente que apenas sabe usar una computadora, arrastran hacia abajo a los usuarios más hábiles
    • Suena raro eso de “¿JIRA? ¿Todavía usan eso?”
      Me hace pensar si me perdí de algo o si caí en un agujero temporal
      No entiendo por qué hablan de Jira como si fuera Visicalc
      Ya no trabajo en una empresa de IT, así que tal vez me perdí algún cambio gigantesco en los últimos dos años
    • Se puede encontrar una correlación entre el precio de la acción y la percepción positiva de los usuarios en la época en que el producto todavía se sostenía
      Al pasar de 4.x a 6.x, también llegaron esas pequeñas molestias, como las cajas tambaleantes de OFBiz y productos completamente distintos que solo coincidían en la apariencia externa
      Esos ingenieros se fueron hace mucho, y también se llevaron sus 280 dólares por acción
    • Ya no necesito usar Jira ni herramientas parecidas en mi trabajo principal, así que tengo verdadera curiosidad: ¿hay algún consenso sobre una alternativa mejor, no solo desde la perspectiva de los desarrolladores sino del equipo completo del proyecto?
    • Incluso esa versión de JIRA podía volverse fácilmente espantosa si se configuraba mal
      El problema central de JIRA es que el poder para configurarlo bien siempre queda en manos de unos pocos, y esas personas están ocupadas, o no les importa, o no lo usan todos los días
      Claro, ese no es el único problema
      Es inimaginablemente lento, y también tiene restricciones rarísimas, como que un issue no pueda ser padre de otro issue

  • JIRA es demasiado lento, y los administradores parecían no saber cómo configurarlo bien
    Solo con haberlo usado me dejó trauma

    • Se podría decir que no es culpa de la herramienta
      Simplemente no existe ni una sola persona en este planeta capaz de configurarla correctamente
      No se puede culpar a la herramienta por la incompetencia humana
      Ahora, para quién fue hecha, esa ya es una pregunta completamente distinta y no deberíamos discutirla en este momento
    • Lo que siempre me frena es la lentitud
      En esencia, un sistema de tickets no es más que una base de datos con tickets, relaciones entre tickets y estados
      Claro, si tienes muchos tickets enlazados, campos personalizados y plugins, la complejidad puede explotar
      Aun así, no entiendo cómo algo que maneja datos de texto simples y archivos adjuntos puede ser tan insoportablemente lento

  • Por fin ya se puede jugar Doom en Jira

    • Sí. También se puede Quake 3 Arena Multiplayer

  • https://mattrickard.com/accidentally-turing-complete

  • Así que eso explica por qué no se puede determinar si cierta tarea de Jira se va a detener o no

    • Entonces, ¿eso cuenta como “se puede jugar Doom en Jira”?
      ¿Jira también incluye una escopeta de corredera para matar a los demonios que produce como resultado?

  • En cambio, prueba Azure Boards y terminarás amando JIRA
    Porque no existe software en el mundo que Microsoft no pueda empeorar

    • Siempre odié Gmail y todavía lo odio, pero el año pasado cambié de trabajo y la nueva empresa usa Outlook, así que cambié de opinión
      Me cuesta encontrar palabras que expresen de verdad mi desprecio por Outlook, y decir que “no me gusta” ni siquiera alcanza para empezar
      Le cuesta hasta la tarea más básica de recibir y enviar correo
      Me llega una notificación de email al celular, abro la app y no hay nada; hago pull-to-refresh y tampoco pasa nada
      Normalmente aparece entre 1 y 15 minutos después
      Todo lo que haces en Outlook es terriblemente engorroso
      También usé Outlook hace mucho, en la época de Office 2003, y no recuerdo que fuera tan malo. No sé cómo lograron retroceder tanto
      Y ni quiero empezar con Teams. Ni siquiera entiendo bien qué problema intenta resolver ese programa
      Los archivos compartidos están en OneDrive, pero también en Teams y, por alguna razón, también en Outlook
      Tuve que mover archivos de respaldo de la computadora, unas imágenes de CloneZilla de alrededor de 30 GB, a OneDrive/Teams/Outlook, y tardó una eternidad, mientras el ventilador de mi laptop Ryzen de 6 núcleos con Win11 estuvo girando como loco todo el tiempo
      ¿Cómo? ¿Por qué?

  • Todos los motores de flujo de trabajo y orquestación son Turing completos
    Porque su propósito mismo es automatizar el flujo de ejecución

    • ¿Y cuántos de ellos pueden ejecutarse infinitamente?
      ¿O ser reactivados por una persona para continuar desde el punto en que se detuvieron?
    • No lo creo
      Primero, JIRA no es orquestación
      Segundo, lo que un flujo de trabajo debe hacer es vincular cierto estado con información externa y facilitar la manipulación de ambas cosas
      Para ser Turing completo, necesitas disparadores y reglas, algo como un contador infinito, dos pilas, o una cinta bidireccional
      Demuéstrame que estoy equivocado

  • Me gusta la automatización de Jira
    Cuando entro a un equipo nuevo que usa Jira, configuro automatizaciones para sumar automáticamente los story points de subtareas y llenar con eso los story points de la tarea padre, o para mandar automáticamente al backlog los tickets que no tienen suficientes atributos refinados
    Por ejemplo, si les falta responsable, story points, prioridad o descripción
    Después de un solo sprint, el tablero del equipo queda mucho más ordenado
    No sé por qué no viene así por defecto, pero es fácil arreglarlo con automatización

    • ¿Por qué sería necesario asignar un responsable para considerar que un ticket está refinado?
      El responsable debería asignarse a quien tome ese trabajo, no ser parte de la etapa de refinamiento