Jira ट्यूरिंग-पूर्ण है

(seriot.ch)

2 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Jira Automation दो अनंत काउंटर और सीमित instruction states वाले Minsky machine को व्यक्त कर सकता है, जिससे Jira की ट्यूरिंग-पूर्णता दिखाई जा सकती है
Epic state program counter का काम करती है, और जुड़े हुए Bug व Task की संख्या दो registers बन जाती है; Automation rules हर instruction के लिए dispatch table बनती हैं
INC और DEC को linked issues के create/delete से लागू किया जाता है, और conditional branching JQL condition rules के जरिए linked issue counts की जांच करके तय होती है
addition उदाहरण में A=2, B=3 से शुरू करके Bug घटाए जाते हैं और Task बढ़ाए जाते हैं, और वास्तविक *.atlassian.net execution में 5 Task और halt state तक पहुंचा जाता है
Fibonacci उदाहरण में issue type conversion से loops कम किए जाते हैं, और Jira Cloud की chain depth limit 10 तक पहुंचने पर manual re-trigger से आगे बढ़ना संभव है

Jira Automation से बनाया गया Minsky machine

Jira Automation दो अनंत काउंटर और सीमित instruction states वाले Minsky register machine को व्यक्त कर सकता है, इसलिए Jira की ट्यूरिंग-पूर्णता दिखाने वाला reduction संभव है
Minsky ने 1967 में जिस मॉडल को सिद्ध किया था, वह केवल INC r; goto S और if r == 0 goto S else (DEC r; goto S') से बना है
Jira के components, Minsky machine के हर element से मेल खाते हैं
- Register A: जुड़े हुए Bug issues की संख्या
- Register B: जुड़े हुए Task issues की संख्या
- Program Counter: एक single Epic issue की state
- Dispatch Table: हर instruction state के लिए Jira Automation rules
- Clock: automation द्वारा trigger किए गए transitions, या chain limit के बाद external re-trigger
Epic state current instruction को encode करती है, और Automation rules जुड़े हुए issues की संख्या जांचकर अगली state में transition करती हैं
INC और DEC को संबंधित type के linked issues के creation और deletion से लागू किया जाता है, और conditional branching को JQL condition rules संभालती हैं

execution के उदाहरण और सीमाएं

addition program एक ऐसा Minsky program है जो A को घटाते हुए B को बढ़ाता है
```
1. if A == 0 goto 3 else (DEC A; goto 2)
2. INC B; goto 1
3. HALT
```
minimal implementation में एक Epic, 5 linked issues, और हर instruction state के लिए एक-एक Automation rule शामिल है
workflow और rules
- Jira Workflow में initial state BACKLOG, और उसके बाद TODO, DEV, PROD बनाई जाती हैं, और सभी states को एक-दूसरे में transition करने योग्य सेट किया जाता है
- BACKLOG state में एक Epic बनाया जाता है
- TODO rule, DEC A; if A=0 halt, else goto DEV को लागू करती है
  - Epic state TODO में बदलते ही यह trigger होती है
  - अगर कम-से-कम एक linked Bug हो, तो एक Bug delete किया जाता है और Epic को DEV में transition किया जाता है
  - अगर Bug न हो, तो Epic को PROD में transition करके halt किया जाता है
- DEV rule, INC B; goto TODO को लागू करती है
  - Epic state DEV में बदलते ही यह trigger होती है
  - एक नया Task बनाया जाता है और Epic से link किया जाता है
  - Epic को TODO में transition किया जाता है
- दोनों rules में "Allow rule to trigger other rules" enabled होता है
initial values और result
- Epic से 2 Bug और 3 Task link करके A=2, B=3 के रूप में initialize किया जाता है
- Epic को TODO में transition करने पर नीचे दिया गया flow chain की तरह execute होता है
```
(2,3) TODO →
(1,3) DEV  →
(1,4) TODO →
(0,4) DEV  →
(0,5) TODO →
(0,5) PROD
```
- यह वास्तविक *.atlassian.net instance पर चलाया गया, और अंत में Epic PROD तक पहुंचता है जबकि उससे 0 Bug और 5 Task जुड़े होते हैं
- यह execution, Jira automation के जरिए 2 + 3 = 5 की गणना का परिणाम बन जाता है
Fibonacci configuration
- Convert Issue Type Bug → Story, Story → Task की तरह issue type को तुरंत बदल सकता है
- CONVERT को DEC + INC के रूप में व्यक्त किया जा सकता है, इसलिए यह computational power नहीं बढ़ाता, लेकिन move loops की dispatch table को छोटा करके अधिक complex programs को संभालना आसान बनाता है
- Fibonacci को (A, B) → (B, A+B) के रूप में व्यक्त किया जाता है, और यह तीन registers A=Bug, B=Task, C=Story और तीन states 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
```
- initial state A=1, B=1, C=0 होती है, और B यानी Task count में 1, 1, 2, 3, 5, 8, 13, ... sequence दिखाई देता है
- addition machine के विपरीत, Fibonacci machine में कोई halt state नहीं है, और यह Jira Cloud की chain depth limit 10 तक चलता है
- limit तक पहुंचने पर operator Epic को फिर से trigger करके execution जारी रख सकता है, और एक बार state edit करते ही chain execution फिर शुरू हो जाता है
- Jira Data Center, automation.rule.execution.timeout और संबंधित settings को configurable properties के रूप में expose करता है
- यदि अनंत issue creation और rule execution माना जाए, तो Jira automation language दो-counter machine को encode कर सकती है, और जिस सामान्य मानदंड में physical computers भी finite माने जाते हैं, उसमें Jira Cloud के finite quotas इस निर्माण को खारिज नहीं करते

1 टिप्पणियां

GN⁺ 3 시간 전

Hacker News की राय

Jira पूरी तरह भयानक है, और उसमें किसी भी दूसरे तरह के भयानक रूप में बदल जाने की संभावना है
- Jira विमुखता की अवधारणा का अंतिम उदाहरण है
  अगर Marx, Atlassian को जानते, तो Grundrisse आग उगल देता
- सबसे बुरा यह है कि task management product बनाने वाली कंपनियाँ आखिरकार सब Jira की दिशा में चली जाती हैं
  बस 2014 के GitHub Issues और आज के उसके रूप की तुलना कर लें: https://github.com/features/issues
  और वे लगातार, लगातार डुप्लिकेट फीचर जोड़ते जा रहे हैं
Jira बहुत लोकप्रिय है और आपकी पसंदीदा भाषा के लिए API wrapper भी अच्छी तरह उपलब्ध हैं
यह हैरानी की बात है कि hacker mindset वाले enterprise developers ने Python command-line script जैसी चीज़ों से Jira में करवाए जाने वाले ज़्यादातर काम automate नहीं कर दिए
अगर मैं Jira थोपने वाले लोगों से एक अंक से भी ज़्यादा आसान तरीके से इसे इस्तेमाल करने लायक बना दूँ, तो पूरा खेल बदल जाता है, और Jira खुद को बचाने के लिए ठेला जाने वाला tool बन जाता है
मैंने कभी-कभी Jira को लगभग दुर्भावनापूर्ण तरीके से इस्तेमाल किया है, और ज़िम्मेदारी से बचने के लिए यह शानदार है
जब समस्या होती है, तो बस कह दीजिए, “यह सब मैंने लिखे हुए सैकड़ों Jira updates में साफ़-साफ़ लिखा था, और आप उन्हें पढ़ रहे थे, है न?”
अब AI भी है, तो custom script से सब कुछ जोड़कर AI से Jira का सारा छोटा-मोटा काम कराया जा सकता है
- काफ़ी लोगों ने पहले से ऐसा किया भी है, लेकिन समस्या यह है कि हर Jira instance पुराने failed migration और नई organizational strategy की परतों से बना custom properties का fractal snowflake होता है
  कई बार API ऐसे काम कर सकती है जिन्हें UI अनुमति नहीं देता, और क्योंकि सब UI को आधार मानकर चलते हैं, आप अजीब तरह से टूटे हुए कोनों में जा फँसते हैं
  उदाहरण के लिए, हो सकता है आपको पता ही न चले कि custom_field_5537 को custom_field_442 के साथ pair करना पड़ता है, तभी वह किसी और के dashboard पर दिखाई देता है
  और custom_field_10995 खुद को integer field बताता है और XML में भी integer की तरह लौटता है, लेकिन issue create करते समय आपको undocumented magic constant string इस्तेमाल करनी पड़ती है, जबकि update के समय फिर उसकी ज़रूरत नहीं होती
  web UI ऐसा नहीं करता; HTML और requests में तो बस integer जाता है, और string का सिर्फ़ 80% dropdown display text से मेल खाता है
  Jira automation मेरे जीवन का सबसे खराब programming experience था
  यक़ीनन इससे सरल setup भी मौजूद होंगे और काफ़ी आसान भी हो सकते हैं, लेकिन फिर भी यह हद से ज़्यादा है
  दुख की बात यह है कि इसके बावजूद लगाया गया effort पूरी तरह वाजिब है। ज़ोरदार सिफारिश है
- एक पुरानी नौकरी में हमने API से समय बचाने वाले कई tools बनाए थे, और वे सब छोटे shell scripts थे
  हमने हर ticket में इंसानों के पढ़ने लायक विवरण के लिए एक custom text field जोड़ा था, और जब release deploy होती थी, तो deployment script अपने-आप timestamp भर देती थी
  हम काम की इकाई के हिसाब से एक-एक ticket release करते थे, और एक दिन में कई tickets निपटा देते थे
  custom filters के साथ मिलकर Jira हर board और पूरी कंपनी के लिए इंसानों के पढ़ने लायक change log देता था, और ये messages Slack पर business side तक पहुँचते थे ताकि सबको पता रहे कि क्या deploy हो रहा है
  यह code changes से जुड़ा एक searchable release audit log भी था
  deployment process Jira ticket status भी transition कर देता था, इसलिए developers को बस ticket को main में merge करना होता था, और वह deploy भी हो जाता था और Jira में complete भी
  repetitive tasks के लिए tickets अपने-आप बनाने वाली छोटी scripts भी बहुत थीं
  यह सालों तक बहुत मज़बूती से चला, और बहुत संभव है कि आज भी चल रहा हो
  custom field naming convention कोई खास अच्छी नहीं थी, लेकिन अगर team Jira setup को control करती हो, तो सबके लिए एक ही मानक बनाए रखना मुश्किल नहीं था
  शुरू में मुझे Jira पसंद नहीं था, और बहुत पहले इसमें काफ़ी समस्याएँ थीं, लेकिन आजकल अगर setup सही हो तो यह इतना बुरा नहीं है
  अपनी कंपनी के लिए मैं इसे नहीं चुनूँगा, लेकिन developer, manager, end user और internal tools developer के रूप में इसे इस्तेमाल करने के अनुभव से कहूँ तो, एक बार यह configure होकर चलने लगे, तो आम तौर पर रास्ते का रोड़ा नहीं बनता
- “custom script से सब कुछ जोड़कर AI से Jira का सारा छोटा-मोटा काम कराओ” यह ऐसा लगता है जैसे Jira का फुलाव अभी काफ़ी नहीं था
  इसमें और text जोड़ दीजिए, फिर Jira somehow उस सारे text पर हर चीज़ को हमेशा auto-run करेगा, तो यह और धीमा ही होगा
  अगर आपकी कंपनी को heating चाहिए, तो Jira इस्तेमाल कीजिए
- बहुत पहले हम JetBrains YouTrack पर चले गए थे, और उसके API से हम इस तरह के काम करते हैं
  यह काफ़ी flexible है, और AI की वजह से यह और खुल गया है
- हमारी पूरी कंपनी लगभग Jira पर ही चलती है
  ज़्यादातर processes Jira पर निर्भर हैं, और कुछ खास transitions automation के लिए webhook चलाते हैं
  जैसे ही AI access मिला, मैंने सबसे पहले जो चीज़ों में से एक बनाई, वह Jira MCP थी
  अब मैं Jira को सीधे लगभग छूना ही नहीं चाहता, और Claude से Jira issues बनवाता हूँ, comments लिखवाता हूँ, subtasks बनवाता हूँ, issues link करवाता हूँ वगैरह
  पहले जब भी implementation का तरीका खोजना होता था और उसे tasks में तोड़ना पड़ता था, मुझे डर लगता था
  क्योंकि जितना बारीक बाँटते, उतने ज़्यादा Jira issues हर task के लिए बनाने पड़ते थे
  अब मैं बस सब कुछ एक file में लिख देता हूँ और large language model को Jira का छोटा-मोटा काम सौंप देता हूँ
जब मैं अपने पुराने कार्यस्थल पर वापस गया तो देखा कि वे अभी भी JIRA इस्तेमाल कर रहे थे
इंटरव्यू में मैंने स्वाभाविक रूप से कहा, “अच्छा JIRA? आप लोग अभी भी वह इस्तेमाल करते हैं? हाँ, मैं इस्तेमाल कर सकता हूँ”
मैं वास्तव में उसे इस्तेमाल कर सकता हूँ, लेकिन नया JIRA देखकर मुझे सचमुच झटका लगा
उसमें लगभग हज़ार छोटी-छोटी परेशानियाँ हैं, और सबसे खराब में से एक यह है कि जब आप टेक्स्ट को डबल-क्लिक करके चुनना चाहते हैं तो वह अचानक फ़ील्ड को edit mode में डाल देता है
मुझे जो याद था वह JIRA Server 4.0 था, और उसकी पुरानी याद यहाँ देखी जा सकती है: https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
ज़ूम इन करने पर हर issue में title, type, fix version, affected version वगैरह होते थे, और उसका ढाँचा सीधे comments तक जाता था। बहुत सरल था
- डबल-क्लिक से edit mode में चले जाने वाली बात बिल्कुल सही है
  यह बेहद चिढ़ाने वाला है। बुनियादी text manipulation तक ग़लत है
  लेकिन एक project manager ने कहा कि उसे यह पसंद है
  क्योंकि वह पूरे शब्द चुनने के लिए double-click drag इस्तेमाल नहीं करता
  हमेशा की तरह, जो लोग मुश्किल से कंप्यूटर चला पाते हैं उनकी सुविधा के लिए ज़्यादा दक्ष users को नीचे खींच लिया जाता है
- “JIRA? आप लोग अभी भी वह इस्तेमाल करते हैं?” जैसी प्रतिक्रिया अजीब लगती है
  मुझे लगा शायद मैं कुछ मिस कर गया, या किसी time hole में गिर गया
  समझ नहीं आता Jira के बारे में Visicalc की तरह क्यों बात की जा रही है
  मैं अभी IT कंपनी में काम नहीं करता, इसलिए हो सकता है पिछले 2 साल में कोई बड़ा बदलाव मिस कर दिया हो
- आप stock price और product के अच्छे user perception के बने रहने वाले दौर के बीच correlation ढूँढ सकते हैं
  4.x से 6.x में जाते समय, OFBiz के डगमगाते बक्सों और ऊपर-ऊपर से मिलते-जुलते लेकिन पूरी तरह अलग products की तरह, ढेर सारी छोटी असुविधाएँ भी साथ आईं
  वे engineers बहुत पहले जा चुके, और $280 per share भी साथ ले गए
- अब मुझे अपने काम में Jira या ऐसे tools इस्तेमाल नहीं करने पड़ते, इसलिए सच में जिज्ञासा है: सिर्फ developers नहीं, बल्कि पूरी project team के नज़रिये से कोई बेहतर alternative जिस पर सहमति हो, क्या ऐसा कुछ है?
- JIRA का वह version भी, अगर गलत configure हो जाए, तो आसानी से भयानक बन सकता था
  JIRA की मूल समस्या यह है कि उसे ठीक से configure करने की authority हमेशा कुछ ही लोगों के पास होती है, और वे या तो आलसी होते हैं, या उनके पास समय नहीं होता, या वे उसे रोज़ इस्तेमाल नहीं करते इसलिए परवाह नहीं करते
  बेशक समस्या सिर्फ वही नहीं है
  यह कल्पना से परे धीमा है, और इसमें ऐसे अजीब restrictions भी हैं जैसे एक issue दूसरे issue का parent नहीं बन सकता
JIRA बहुत धीमा है, और admins को शायद उसे सही तरह configure करना आता ही नहीं
सिर्फ इस्तेमाल करने भर से trauma हो गया है
- कोई कह सकता है कि यह tool की गलती नहीं है
  बस इस ग्रह पर एक भी ऐसा इंसान नहीं है जो इस tool को सही तरीके से configure कर सके
  tool को इंसानी अयोग्यता के लिए दोषी नहीं ठहराया जा सकता
  फिर यह सवाल कि इसे आखिर किसके लिए बनाया गया है, वह बिल्कुल अलग मुद्दा है, और अभी उस पर बात नहीं करनी चाहिए
- जो बात हमेशा अटकती है, वह है speed
  मूल रूप से ticket system, tickets के बीच relations और states रखने वाले database से ज़्यादा कुछ नहीं है
  हाँ, linked tickets, custom fields और plugins बहुत ज़्यादा हों तो complexity बहुत बढ़ सकती है
  फिर भी समझ नहीं आता कि साधारण text data और attachments संभालने वाली चीज़ इतनी असहनीय रूप से धीमी कैसे हो सकती है
आख़िरकार अब Jira में Doom खेला जा सकता है
- सही। Quake 3 Arena Multiplayer भी संभव है
https://mattrickard.com/accidentally-turing-complete
तो इससे समझ आता है कि कुछ Jira tasks के halt होंगे या नहीं यह तय क्यों नहीं किया जा सकता
- तो क्या यह “Jira में Doom चला सकते हैं” वाली श्रेणी में आता है?
  क्या Jira उन दानवों को मारने के लिए pump-action shotgun भी देता है जो इससे पैदा होते हैं?
इसके बजाय Azure Boards इस्तेमाल करके देखिए, आपको JIRA से प्यार हो जाएगा
क्योंकि ऐसी कोई software चीज़ नहीं जिसे Microsoft और खराब न बना सके
- मुझे हमेशा Gmail से नफ़रत रही है, और अब भी है, लेकिन पिछले साल नौकरी बदलने के बाद नई कंपनी Outlook इस्तेमाल करती है, तो मेरी राय बदल गई
  Outlook के प्रति अपनी घृणा को ठीक से व्यक्त करने के लिए शब्द ढूँढना मुश्किल है, और “नापसंद” तो शुरुआत भी नहीं है
  यह email पाने और भेजने जैसे सबसे बुनियादी कामों में भी जूझता है
  फ़ोन पर email notification आता है, ऐप खोलते हैं तो कुछ नहीं होता, नीचे खींचकर refresh करने पर भी कुछ नहीं होता
  आम तौर पर 1 से 15 मिनट बाद जाकर वह दिखता है
  Outlook में हर काम बेहद झंझटभरा है
  बहुत पहले Office 2003 के समय भी मैंने Outlook इस्तेमाल किया था, लेकिन याद नहीं कि यह इतना खराब था। समझ नहीं आता यह इतना पीछे कैसे चला गया
  Teams की तो बात ही शुरू नहीं करना चाहता। मुझे ठीक से पता भी नहीं कि वह program किस समस्या को हल करना चाहता है
  shared files OneDrive में हैं, Teams में भी हैं, और किसी वजह से Outlook में भी हैं
  मुझे कंप्यूटर backup files, लगभग 30GB के CloneZilla images, OneDrive/Teams/Outlook में ले जाने पड़े, जिसमें हमेशा लग गया, और Win11 चलाने वाले 6-core Ryzen laptop का fan लगातार पागलों की तरह घूमता रहा
  कैसे? क्यों?
सभी workflow और orchestration engines Turing-complete होते हैं
क्योंकि उनका उद्देश्य ही execution flow को automate करना है
- उनमें से कितने अनंत समय तक चल सकते हैं?
  या कोई इंसान उन्हें फिर से trigger करके जहाँ रुके थे वहाँ से आगे बढ़ा सकता है?
- मैं ऐसा नहीं मानता
  पहली बात, JIRA orchestration नहीं है
  दूसरी बात, workflow का काम किसी state को बाहरी जानकारी से जोड़ना और उन चीज़ों को आसानी से manipulate करने योग्य बनाना है
  Turing-complete होने के लिए triggers और rules, infinite counter जैसी कोई चीज़, दो stacks, bidirectional tape जैसी चीज़ें चाहिए
  साबित करो कि मैं ग़लत हूँ
मुझे Jira automation पसंद है
जब मैं किसी नई team में शामिल होता हूँ जो Jira इस्तेमाल करती है, तो मैं ऐसी automations सेट करता हूँ जो subtasks के story points अपने-आप जोड़कर parent task के story points भर दें, या अगर पर्याप्त refined properties न हों तो ticket को अपने-आप backlog में भेज दें
जैसे assignee, story points, priority, description वगैरह गायब हों
सिर्फ एक sprint के बाद team board काफ़ी व्यवस्थित हो जाता है
पता नहीं यह default क्यों नहीं है, लेकिन automation से इसे आसानी से ठीक किया जा सकता है
- किसी ticket को refined मानने के लिए assignee तय होना क्यों ज़रूरी है?
  assignee तो उस व्यक्ति को मिलना चाहिए जो वह काम उठाए, यह refinement stage का हिस्सा नहीं होना चाहिए

Jira ट्यूरिंग-पूर्ण है

Jira Automation से बनाया गया Minsky machine

execution के उदाहरण और सीमाएं

workflow और rules

initial values और result

Fibonacci configuration

संबंधित पढ़ाई

1 टिप्पणियां

Hacker News की राय