Jira bersifat Turing-complete

 (seriot.ch)
2 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Jira Automation dapat merepresentasikan mesin Minsky dengan dua penghitung tak terbatas dan status instruksi hingga, sehingga dapat menunjukkan sifat Turing-complete Jira
  • Status Epic menjadi program counter, jumlah Bug dan Task yang terhubung menjadi dua register, dan aturan Automation menjadi tabel dispatch untuk tiap instruksi
  • INC dan DEC diimplementasikan dengan membuat dan menghapus issue terhubung, sementara percabangan kondisi ditentukan dengan memeriksa jumlah issue terhubung melalui aturan kondisi JQL
  • Contoh penjumlahan dimulai dari A=2, B=3, lalu mengurangi Bug dan menambah Task hingga pada eksekusi nyata di *.atlassian.net mencapai 5 Task dan status berhenti
  • Contoh Fibonacci mengurangi loop lewat konversi tipe issue, dan saat menyentuh batas kedalaman rantai 10 di Jira Cloud, proses dapat dilanjutkan dengan pemicu ulang manual

Mesin Minsky yang dibuat dengan otomatisasi Jira

  • Jira Automation dapat merepresentasikan Minsky register machine dengan dua penghitung tak terbatas dan status instruksi yang hingga, sehingga memungkinkan reduksi yang menunjukkan bahwa Jira bersifat Turing-complete
  • Model yang dibuktikan Minsky pada 1967 hanya terdiri dari INC r; goto S dan if r == 0 goto S else (DEC r; goto S')
  • Komponen Jira dipetakan ke setiap elemen mesin Minsky
    • Register A: jumlah issue Bug yang terhubung
    • Register B: jumlah issue Task yang terhubung
    • Program Counter: status dari satu issue Epic
    • Dispatch Table: aturan Jira Automation untuk tiap status instruksi
    • Clock: transisi yang dipicu otomatisasi atau pemicu ulang eksternal setelah batas rantai tercapai
  • Status Epic mengenkode instruksi saat ini, dan Automation rules memeriksa jumlah issue terhubung untuk berpindah ke status berikutnya
  • INC dan DEC diimplementasikan dengan membuat dan menghapus issue terhubung dari tipe terkait, sedangkan percabangan kondisi ditangani dengan aturan kondisi JQL

Contoh eksekusi dan batasan

  • Program penjumlahan disusun sebagai program Minsky yang mengurangi A sambil menambah B 
    1. if A == 0 goto 3 else (DEC A; goto 2)
2. INC B; goto 1
3. HALT
  • Implementasi minimal terdiri dari satu Epic, 5 issue terhubung, dan masing-masing satu aturan Automation untuk setiap status instruksi

  • Workflow dan aturan

    • Di Jira Workflow, buat status awal BACKLOG, lalu TODO, DEV, PROD, dan atur agar semua status bisa saling bertransisi
    • Buat satu Epic pada status BACKLOG
    • Aturan TODO mengimplementasikan DEC A; if A=0 halt, else goto DEV
      • Dipicu saat status Epic berubah ke TODO
      • Jika ada setidaknya satu Bug terhubung, hapus satu Bug dan ubah Epic ke DEV
      • Jika tidak ada Bug, ubah Epic ke PROD untuk berhenti
    • Aturan DEV mengimplementasikan INC B; goto TODO
      • Dipicu saat status Epic berubah ke DEV
      • Buat Task baru dan hubungkan ke Epic
      • Ubah Epic ke TODO
    • Pada kedua aturan, opsi "Allow rule to trigger other rules" diaktifkan

  • Nilai awal dan hasil

    • Hubungkan 2 Bug dan 3 Task ke Epic untuk inisialisasi A=2, B=3
    • Saat Epic diubah ke TODO, rangkaian berikut dijalankan berantai 
      (2,3) TODO →
(1,3) DEV  →
(1,4) TODO →
(0,4) DEV  →
(0,5) TODO →
(0,5) PROD
    • Ini dijalankan pada instance nyata *.atlassian.net, dan pada akhirnya Epic mencapai PROD dengan 0 Bug dan 5 Task terhubung
    • Eksekusi ini menjadi hasil perhitungan 2 + 3 = 5 menggunakan otomatisasi Jira

  • Konfigurasi Fibonacci

    • Convert Issue Type dapat langsung mengubah tipe issue seperti Bug → Story, Story → Task
    • CONVERT dapat direpresentasikan sebagai DEC + INC, sehingga tidak memperluas kemampuan komputasi, tetapi mengurangi tabel dispatch pada loop pemindahan dan mempermudah penanganan program yang lebih kompleks
    • Fibonacci direpresentasikan sebagai (A, B) → (B, A+B), dan terdiri dari tiga register A=Bug, B=Task, C=Story serta tiga status 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
    • Status awalnya adalah A=1, B=1, C=0, dan deret 1, 1, 2, 3, 5, 8, 13, ... muncul pada B, yaitu jumlah Task
    • Berbeda dari mesin penjumlahan, mesin Fibonacci tidak memiliki status berhenti dan berjalan sampai mencapai batas kedalaman rantai 10 di Jira Cloud
    • Saat mencapai batas itu, operator dapat memicu ulang Epic untuk melanjutkan, dan satu kali edit status akan memulai kembali eksekusi berantai
    • Jira Data Center mengekspos automation.rule.execution.timeout dan pengaturan terkait sebagai properti yang dapat dikonfigurasi
    • Dengan asumsi pembuatan issue dan eksekusi aturan tak terbatas, bahasa otomatisasi Jira dapat mengenkode mesin dua penghitung, dan menurut kriteria umum bahwa komputer fisik juga terbatas, kuota terbatas Jira Cloud tidak membantah konstruksi ini

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Opini Hacker News

  • Jira benar-benar mengerikan, dan punya potensi untuk berubah menjadi bentuk kengerian apa pun

    • Jira adalah contoh paling akhir dari konsep alienasi
      Kalau Marx mengenal Atlassian, Grundrisse pasti akan jauh lebih membara
    • Yang paling buruk adalah semua perusahaan yang membuat produk manajemen kerja pada akhirnya bergerak ke arah Jira
      Cukup bandingkan GitHub Issues tahun 2014 dengan wujudnya sekarang: https://github.com/features/issues
      Dan mereka terus, terus, menambahkan fitur duplikat

  • Jira sangat populer dan juga punya API wrapper yang bagus untuk bahasa yang Anda sukai
    Agak mengejutkan bahwa para pengembang enterprise yang punya semangat hacker belum mengotomatisasi sebagian besar pekerjaan yang diminta Jira dengan hal-hal seperti skrip command line Python
    Kalau saya bisa membuatnya lebih mudah dipakai lebih dari satu orde besaran dibanding orang-orang yang memaksakan Jira, situasinya akan berbalik, dan Jira menjadi alat yang didorong untuk melindungi dirinya sendiri
    Kadang saya memakai Jira dengan cara yang nyaris jahat, dan itu sangat bagus untuk menghindari tanggung jawab
    Saat ada masalah, Anda tinggal bilang, “Ini sudah tertulis jelas di ratusan update Jira yang saya buat, dan kalian membacanya, kan?”
    Sekarang juga sudah ada AI, jadi tinggal ikat semuanya dengan skrip kustom dan biarkan AI mengerjakan kerja kasar Jira

    • Cukup banyak orang sudah melakukan itu, tetapi masalahnya adalah setiap instance Jira merupakan serpihan salju fraktal dari properti kustom yang bertumpuk dari migrasi lama yang gagal dan strategi organisasi baru
      API sering kali bisa melakukan hal-hal yang tidak diizinkan UI, dan karena semua orang bergerak berdasarkan UI, Anda jadi masuk ke sudut-sudut aneh yang rusak
      Misalnya, Anda bisa saja tidak menyadari bahwa custom_field_5537 harus dipasangkan dengan custom_field_442 agar terlihat di dashboard orang lain
      Lalu custom_field_10995 mengklaim sebagai field integer dan juga dikembalikan sebagai integer di XML, tetapi saat membuat issue Anda harus memakai string konstanta ajaib yang tidak terdokumentasi, sementara saat update justru tidak perlu begitu
      Web UI tidak melakukannya seperti itu, dan di HTML maupun request yang masuk hanya ada integer, sedangkan hanya 80% string yang cocok dengan teks tampilan dropdown
      Otomasi Jira adalah pengalaman pemrograman terburuk yang pernah saya alami
      Konfigurasi yang lebih sederhana jelas ada dan mungkin cukup mudah, tetapi ini tetap keterlaluan
      Sedihnya, usaha yang dikeluarkan tetap sepenuhnya sepadan. Sangat direkomendasikan
    • Di tempat saya bekerja dulu, kami membuat beberapa alat penghemat waktu lewat API, dan semuanya adalah skrip shell kecil
      Kami menambahkan field teks kustom pada tiap tiket untuk deskripsi yang bisa dibaca manusia, dan saat rilis dideploy, skrip deployment otomatis mengisi timestamp-nya
      Kami merilis satu tiket per unit kerja dan menangani beberapa tiket per hari
      Dikombinasikan dengan filter kustom, Jira memberi changelog yang bisa dibaca manusia untuk tiap board dan untuk seluruh perusahaan, dan pesan-pesan ini diteruskan ke sisi bisnis lewat Slack agar semua orang tahu apa yang sedang dideploy
      Ini juga menjadi log audit rilis yang bisa dicari dan terhubung ke perubahan kode
      Proses deployment juga mengubah status tiket Jira, jadi developer cukup merge tiket ke main lalu tiket itu terdeploy dan selesai di Jira
      Ada juga banyak skrip kecil yang otomatis membuat tiket untuk pekerjaan berulang
      Selama bertahun-tahun semuanya sangat kokoh dan kemungkinan besar masih berjalan sampai sekarang
      Aturan penamaan field kustom memang kurang bagus, tetapi jika tim mengendalikan konfigurasi Jira, tidak sulit menjaga semua orang tetap memakai standar yang sama
      Awalnya saya tidak menyukai Jira dan dulu sekali memang banyak masalah, tetapi belakangan ini jika konfigurasinya benar, itu tidak seburuk itu
      Kalau itu perusahaan saya, saya tidak akan memilihnya, tetapi dari sudut pandang saya sebagai developer, admin, pengguna akhir, dan pengembang alat internal, setelah dikonfigurasi dan mulai berjalan, biasanya itu tidak terlalu mengganggu
    • “Ikat semuanya dengan skrip kustom dan biarkan AI mengerjakan kerja kasar Jira” terdengar seolah-olah kegemukan Jira masih belum cukup
      Kalau ditambah lebih banyak teks, Jira somehow akan selalu mengeksekusi semuanya di atas seluruh teks itu, jadi pasti akan makin lambat
      Kalau perusahaan Anda butuh pemanas, pakai saja Jira
    • Sudah sangat lama kami pindah ke JetBrains YouTrack, dan kami melakukan hal semacam ini dengan API-nya
      Cukup fleksibel, dan dengan AI jadi makin terbuka
    • Seluruh perusahaan kami pada dasarnya berjalan di atas Jira
      Sebagian besar proses bergantung pada Jira, dan transisi tertentu menjalankan webhook untuk otomasi
      Begitu mendapat akses AI, salah satu hal pertama yang saya buat adalah Jira MCP
      Sekarang saya berusaha hampir tidak pernah menyentuh Jira secara langsung, dan menyuruh Claude membuat issue Jira, menulis komentar, membuat subtask, menautkan issue, dan sebagainya
      Dulu saya takut setiap kali harus meneliti cara implementasi dan memecahnya menjadi tugas-tugas
      Karena makin rinci saya memecahnya, makin banyak issue Jira yang harus saya buat untuk menampung tiap tugas
      Sekarang saya tinggal menuliskan semuanya ke sebuah file lalu menyerahkan kerja kasar Jira kepada large language model

  • Ketika kembali ke tempat lama saya bekerja, ternyata mereka masih memakai JIRA
    Saat wawancara tentu saya bilang, “Oh JIRA ya, kalian masih pakai itu? Ya saya bisa pakai”
    Secara teknis memang bisa dipakai, tapi melihat JIRA versi terbaru benar-benar mengejutkan
    Ada mungkin seribu ketidaknyamanan kecil, dan salah satu yang terburuk adalah saat mencoba memilih teks dengan klik ganda, tiba-tiba field masuk ke mode edit
    Yang saya ingat dulu adalah JIRA Server 4.0, dan nostalgia itu bisa dilihat di sini: https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
    Kalau diperbesar cukup jauh, tiap issue punya judul, tipe, versi perbaikan, versi yang terdampak, dan strukturnya langsung berlanjut ke komentar. Sangat sederhana

    • Soal klik ganda yang masuk ke mode edit itu memang benar
      Menyebalkan sekali. Bahkan manipulasi teks dasar saja salah
      Tapi ada manajer proyek yang bilang mereka suka itu
      Katanya karena mereka tidak pernah memakai double-click drag untuk memilih seluruh kata
      Seperti biasa, pengguna yang lebih mahir ditarik turun demi kenyamanan orang yang nyaris tak bisa memakai komputer
    • Reaksi “JIRA ya, kalian masih pakai itu?” terdengar aneh
      Rasanya seperti saya melewatkan sesuatu atau jatuh ke lubang waktu
      Saya tidak paham kenapa Jira dibicarakan seperti Visicalc
      Saya sekarang tidak bekerja di perusahaan IT, jadi mungkin saya melewatkan perubahan besar dalam dua tahun terakhir
    • Ada korelasi yang bisa dicari antara harga saham dan persepsi pengguna yang positif terhadap produk pada masa produk itu masih terjaga
      Saat beralih dari 4.x ke 6.x, muncul juga berbagai ketidaknyamanan kecil, atau produk yang sepenuhnya berbeda seperti kotak-kotak OFBiz yang seret dan hanya tampak mirip di permukaan
      Para engineer itu sudah pergi sejak lama, dan 280 dolar per saham ikut mereka bawa
    • Sekarang saya tidak perlu lagi memakai Jira atau alat serupa di pekerjaan utama, jadi saya benar-benar penasaran, apakah ada kesepakatan tentang alternatif yang lebih baik dari sudut pandang seluruh tim proyek, bukan hanya developer?
    • Bahkan versi JIRA itu pun bisa dengan mudah jadi mengerikan kalau konfigurasinya salah
      Masalah inti JIRA adalah hak untuk mengonfigurasinya dengan benar selalu hanya dimiliki segelintir orang, dan mereka itu malas, sibuk, atau tidak memakainya setiap hari sehingga tidak peduli
      Tentu itu bukan satu-satunya masalah
      Ia sangat lambat sampai sulit dibayangkan, dan juga punya batasan aneh seperti issue yang tidak bisa menjadi parent bagi issue lain

  • JIRA terlalu lambat, dan para admin sepertinya tidak tahu cara mengonfigurasinya dengan benar
    Hanya dari memakainya saja sudah terasa traumatis

    • Bisa dibilang ini bukan salah alatnya
      Hanya saja tidak ada satu orang pun di planet ini yang mampu mengonfigurasi alat itu dengan benar
      Kita tidak bisa menyalahkan alat atas ketidakmampuan manusia
      Pertanyaan untuk siapa alat itu dibuat adalah masalah yang sama sekali berbeda, dan sebaiknya tidak kita bahas sekarang
    • Yang selalu jadi masalah adalah kelambatannya
      Pada dasarnya sistem tiket tidak lebih dari basis data berisi tiket, relasi antar tiket, dan status
      Tentu kalau tiket yang saling terhubung, custom field, dan plugin sangat banyak, kompleksitasnya bisa meledak
      Meski begitu, saya tetap tidak paham bagaimana sesuatu yang cuma menangani data teks sederhana dan lampiran bisa terasa selambat dan setidak tertahankan itu

  • Akhirnya sekarang kita bisa memainkan Doom di Jira

    • Benar. Quake 3 Arena Multiplayer juga bisa

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

  • Jadi ini menjelaskan kenapa kita tidak bisa menentukan apakah suatu task Jira akan berhenti atau tidak

    • Jadi ini termasuk “bisa main Doom di Jira” ya?
      Apakah Jira juga menyediakan shotgun pump-action untuk membunuh para iblis yang muncul sebagai akibatnya?

  • Coba saja pakai Azure Boards, nanti Anda akan jadi cinta JIRA
    Karena tidak ada software di dunia yang tidak bisa dibuat lebih buruk oleh Microsoft

    • Saya selalu benci Gmail dan masih benci juga, tetapi setelah pindah kerja tahun lalu dan perusahaan baru memakai Outlook, pandangan saya berubah
      Sulit mencari kata yang cukup menghina untuk Outlook, dan kata “benci” bahkan belum mulai menggambarkannya
      Untuk menerima dan mengirim email, tugas paling dasar sekalipun, dia sudah kewalahan
      Notifikasi email masuk di ponsel, saya buka aplikasinya, tidak ada apa-apa, tarik ke bawah untuk refresh pun tidak terjadi apa-apa
      Biasanya baru muncul 1 sampai 15 menit kemudian
      Semua yang dilakukan di Outlook terasa sangat menyiksa
      Dulu sekali saya juga memakai Outlook pada era Office 2003, dan saya tidak ingat itu seburuk ini. Saya tidak tahu bagaimana bisa mundur sejauh ini
      Belum lagi Teams. Saya bahkan tidak ingin mulai membahasnya. Saya juga tidak benar-benar paham masalah apa yang program itu coba selesaikan
      File bersama ada di OneDrive, tapi juga ada di Teams, dan entah kenapa juga ada di Outlook
      Saya harus memindahkan file backup komputer, sekitar 30GB image CloneZilla, ke OneDrive/Teams/Outlook, dan itu memakan waktu selamanya, sementara kipas laptop Ryzen 6-core dengan Win11 terus meraung seperti gila
      Bagaimana caranya? Kenapa?

  • Semua mesin workflow dan orkestrasi itu Turing-complete
    Karena memang tujuannya adalah mengotomatisasi alur eksekusi

    • Berapa banyak di antaranya yang bisa berjalan tanpa batas?
      Atau bisa dipicu ulang oleh manusia dan lanjut dari titik saat berhenti?
    • Saya rasa tidak begitu
      Pertama, JIRA itu bukan orkestrasi
      Kedua, yang seharusnya dilakukan workflow adalah mengaitkan status tertentu dengan informasi eksternal dan membuatnya mudah dimanipulasi
      Untuk menjadi Turing-complete, Anda butuh trigger dan rule, semacam penghitung tak terbatas, dua stack, pita dua arah, atau semacam itu
      Coba buktikan saya salah

  • Saya suka otomatisasi Jira
    Saat masuk ke tim baru yang memakai Jira, saya biasanya menyiapkan otomatisasi untuk menjumlahkan story point dari subtugas agar mengisi story point task induk secara otomatis, atau memindahkan tiket kembali ke backlog secara otomatis jika tidak punya atribut yang cukup rapi
    Misalnya jika assignee, story point, prioritas, atau deskripsinya belum ada
    Setelah lewat satu sprint saja, board tim jadi jauh lebih rapi
    Saya tidak tahu kenapa itu bukan default, tapi mudah diperbaiki dengan otomatisasi

    • Kenapa penetapan assignee diperlukan agar tiket dianggap rapi?
      Assignee seharusnya ditetapkan kepada orang yang mengambil pekerjaan itu, bukan menjadi bagian dari tahap perapian