Gitea: प्रति प्रोजेक्ट SCRUM बैकलॉग/स्प्रिंट बैकलॉग

क्या आप कृपया बता सकते हैं कि आप विशेष रूप से कौन सी सुविधाएँ चाहते हैं?

SCRUM में आपके पास मूल रूप से एक उत्पाद-बैकलॉग होता है, जिसमें उपयोगकर्ता कहानियां होती हैं, जिन्हें प्राथमिकता या कुछ पूर्वनिर्धारित मान द्वारा क्रमबद्ध किया जाता है।
प्रत्येक उपयोगकर्ता कहानी में प्राथमिकता को मापने के लिए एक शीर्षक, विवरण और शायद मूल्य के लिए एक नाम होता है (अधिक या कम "मुद्दों" की तरह, लेकिन प्राथमिकता के आधार पर क्रमबद्ध) और साथ ही उस प्राथमिकता वाले क्षेत्र में।
साथ ही एक फ़ील्ड, जो इंगित कर सकती है कि उपयोगकर्ता-कहानी लागू की गई थी, हटा दी गई थी (कुछ मुद्दों के कारण, समाप्त नहीं हुई या अधिक विवरण की आवश्यकता है)

प्रत्येक स्प्रिंट (समय की परिभाषित अवधि) में देव उत्पाद-बैकलॉग से कुछ उपयोगकर्ता कहानियां लेते हैं और उन्हें अपने स्प्रिंट-बैकलॉग में जोड़ते हैं, जिसमें पी-बैकलॉग के अलावा अन्य (शायद वैकल्पिक) विचार होते हैं कि डेवलपर्स कैसे हल करना चाहते हैं विशिष्ट समस्या, जो उनकी चुनी हुई उपयोगकर्ता-कहानी द्वारा वर्णित है। प्रत्येक डेवलपर हर दूसरे डेवलपर की निर्दिष्ट उपयोगकर्ता कहानी देख सकता है, लेकिन इसे संपादित नहीं कर सकता (शायद केवल उस पर टिप्पणी करें)
देवों को केवल अपने स्वयं के समाधान नोट्स को संशोधित करने में सक्षम होना चाहिए, लेकिन उपयोगकर्ता कहानी का विवरण/शीर्षक नहीं, इस प्रकार कम से कम दो भूमिकाओं की आवश्यकता (उत्पाद स्वामी और डेवलपर (अनन्य नहीं))
क्या देव -1 ने अपनी निर्दिष्ट उपयोगकर्ता कहानियों को समाप्त कर दिया है, वह एक और देव -2 को अपनी (अन्य देव -2) उपयोगकर्ता कहानी को देव -1 (ठीक है, इस बिंदु पर चर्चा के लिए खुला) सौंपने के लिए कह सकता है।

क्या स्प्रिंट समाप्त हो गया है, जिसका अर्थ है कि समय समाप्त हो गया है, समाप्त उपयोगकर्ता कहानियों का किसी प्रकार का अवलोकन हो सकता है और अधूरी भी।
इन उपयोगकर्ता कहानियों को दो चरणों से गुजरना होगा।
समाप्त लोगों को दोनों चरणों से गुजरना होगा, एक है स्प्रिंट समीक्षा (उदाहरण के लिए ग्राहक को पूर्ण सुधार दिखाना) (केवल समाप्त उपयोगकर्ता कहानियां)।
दूसरा चरण स्प्रिंट पूर्वव्यापी होगा, जहां देव टीम इस बात पर एक नज़र डालती है कि क्या समाप्त हो गया था और विशेष रूप से, इस प्रक्रिया में क्या अच्छा था, और यह भी कि कौन सी उपयोगकर्ता कहानियां समाप्त नहीं हुई थीं और क्यों नहीं (उन्हें उत्पाद बैकलॉग में ले जाना)
(हो सकता है कि कुछ "बुलेटिन बोर्ड" "हो गया" की परिभाषा के बारे में जानकारी के साथ, जिसका अर्थ है कि उपयोगकर्ता की कहानी को कब किया जाए और कुछ प्रक्रिया अनुकूलन सामग्री पर विचार किया जाए)

एक नया स्प्रिंट शुरू करने के लिए कुछ कार्यक्षमता और शायद सामान्य समस्या प्रणाली के आधार पर, उत्पाद स्वामी इन सुझावों को ले सकता है और उन्हें उपयोगकर्ता कहानियों में परिवर्तित कर सकता है, प्राथमिकता, अधिक विस्तृत विवरण आदि जोड़ सकता है।

मुझे नहीं पता कि मौजूदा समस्या प्रणाली का उपयोग करने के लिए बेहतर क्या होगा और इसे उत्पाद के मालिक के लिए इनपुट के रूप में उपयोग करने के लिए या सामान्य समस्या प्रणाली को छोड़कर, विशेष रूप से स्क्रम सामग्री का उपयोग करने के लिए और स्क्रम सामग्री को स्वयं के मुद्दे के रूप में देखें। प्रणाली।

टीएलडीआर :डी
सामान्य तौर पर दो भूमिकाएँ होने की आवश्यकता होती है, एक उत्पाद स्वामी (डिफ़ॉल्ट परियोजना स्वामी द्वारा पहले उत्पाद / परियोजना स्वामी द्वारा भूमिकाएँ बदलने की संभावना के साथ) और दूसरी डेवलपर होती है।
इसके अलावा एक स्प्रिंट की आवश्यकता होती है, जिसमें एक परिभाषित (उत्पाद स्वामी?) अवधि और स्प्रिंट को किक करने के लिए कुछ तंत्र होता है। स्प्रिंट बैकलॉग में कुछ भी नहीं होने पर स्प्रिंट को मारना कोई मतलब नहीं है, इस प्रकार एक स्प्रिंट बैकलॉग की आवश्यकता जिसमें असाइन (?) (हो सकता है कि सभी देव असाइनमेंट बदल सकते हैं) उपयोगकर्ता कहानियां, जिन्हें बदला नहीं जा सकता, लेकिन टिप्पणी की गई उप टिप्पणियों के साथ एक चिपचिपा टिप्पणी?)
उपयोगकर्ता कहानी की स्थिति को अधूरा से समाप्त करने के लिए प्रत्येक डेवलपर को सक्षम होना चाहिए (केवल एक स्प्रिंट के भीतर? या जब भी वह प्रसन्न होता है?)
जब स्प्रिंट समाप्त हो जाता है, तो "इश्यू ट्रैकर" की स्थिति को अपने राज्य को समीक्षा चरण में बदलना चाहिए, केवल समाप्त उपयोगकर्ता कहानियां दिखा रहा है (और केवल चिपचिपा डेवलपर टिप्पणी? कोई टिप्पणी नहीं? सभी टिप्पणियां?)। (हमें किन राज्यों की आवश्यकता होनी चाहिए? : सुझाव: योजना, स्प्रिंट, समीक्षा, पूर्वव्यापी)
तब उत्पाद स्वामी (?) राज्य को पूर्वव्यापी में बदलने में सक्षम होना चाहिए, जहां शायद "बुलेटिन बोर्ड" सुझावों, पैटर्न, अच्छी प्रथाओं, बुरी प्रथाओं आदि के साथ-साथ सभी, समाप्त और अधूरी उपयोगकर्ता कहानियों के साथ फिर से दिखना चाहिए।
इस चरण के बाद उत्पाद स्वामी (?) को अगले चरण में योजना बनाने में सक्षम होना चाहिए, जहां अधूरी उपयोगकर्ता कहानियों को उत्पाद बैकलॉग पर वापस जाना चाहिए (?) लोगों पर उंगली उठाएँ, जब बाद में कोई बग मिल जाए)।
और नियोजन चरण में देव टीम उपयोगकर्ता कहानियों को फिर से अपने स्प्रिंट बैकलॉग में जोड़ सकती है।
और इस कदम के बाद किसी तरह स्प्रिंट को बंद करने की जरूरत है, शायद उत्पाद मालिक द्वारा।

चर्चा करने में मज़ा लें (मुझे आशा है)

उपयोगकर्ता कहानियों में सामान्य समस्या ट्रैकर में सभी गुण भी हो सकते हैं, उदाहरण के लिए टैग और इसी तरह।

यह पहले से ही #८०५ में चर्चा की गई थी। व्यक्तिगत रूप से, मुझे लगता है कि टीमों का वर्कफ़्लो बहुत भिन्न हो सकता है, और इस कारण से हमारे पास गिटहब या गिटलैब या बिटबकेट के स्क्रम सिस्टम के समान कोई "प्रोजेक्ट" सुविधा नहीं होनी चाहिए। मुझे नहीं लगता कि कोई भी व्यवहार्य एक आकार-फिट-सभी है, लेकिन छोटी परियोजनाओं के लिए मुद्दे एक अच्छा समझौता है जहां कोई उम्मीद कर सकता है कि बड़ी मात्रा में चीजों का ट्रैक न हो।

जहां तक ​​मेरा संबंध है, गीता को अपने आप में गिटहब/लैब-शैली के मुद्दों पर टिके रहना चाहिए और केवल एपीआई और वेबहुक का उपयोग करके उनसे निपटने के लिए उपकरण प्रदान करना चाहिए, या लोगों को बाहरी समस्या ट्रैकर्स (कुछ ऐसा जो हमारे पास पहले से है!) का उपयोग करने की अनुमति देना चाहिए।

@ jxsl13 मैं आपको https://github.com/opf/openproject सुझा सकता हूं जो गीता के साथ काम कर सकता है। यह एकाधिक वर्कफ़्लो का समर्थन करता है और आप इसे अपने टिकट/इश्यू मैनेजर के रूप में उपयोग करने के लिए gita सेट कर सकते हैं (gita में url सेट करके)

@sapk धन्यवाद, काफी आशाजनक लग रहा है

@sapk मैंने ओपन-प्रोजेक्ट स्थापित किया है और गीता में टिकट/इश्यू मैनेजर बदल दिया है, लेकिन मेरा एक सवाल है, क्या ओपन-प्रोजेक्ट और गीता के बीच कोई संबंध है? या ओपनप्रोजेक्ट से केवल गीता लिंक?

मेरा प्रश्न इसलिए है क्योंकि मुझे नहीं पता कि मेरे गिटिया मुद्दों को ओपनप्रोजेक्ट कार्य (गीता का कोड, गिटिया और ओपनप्रोजेक्ट में समान संख्या में समस्या) के साथ संबंध बनाने का कोई तरीका है या नहीं।

आपके जवाब का धन्यवाद!

एपीआई के माध्यम से ओपनप्रोजेक्ट और गिटिया के बीच अधिक कसकर लिंक करना संभव हो सकता है, लेकिन मैं किसी को भी नहीं जानता कि जैसा किया गया है (और शायद गिटिया या ओपनप्रोजेक्ट कोड में कुछ समायोजन की आवश्यकता है)।
मैं इसका उपयोग ज्यादातर उन्नत परियोजना प्रबंधन करने के लिए करता हूं, जो कि gita में होस्ट किए गए कोड से अलग है।

मुझे लेबल से बाहर स्क्रम/कानबन "बोर्ड" बनाने और उन्हें एक अलग दृश्य में बदलने की अनुमति देने के गिटलैब दृष्टिकोण को पसंद है ... वास्तव में कुछ भी नहीं बदलता है, यह सिर्फ एक अलग दृश्य है, लेकिन एक बहुत ही उपयोगी आईएमएचओ है।

कुछ टीमों के लिए एक ही उपकरण पर एक एकीकृत बोर्ड होने के कारण समस्याएँ पैदा होती हैं। Gitlab या Github जैसे बोर्डों का होना वास्तव में उपयोगी होगा। मैं गीता एकीकृत बोर्ड/प्रोजेक्ट टैब के विचार के साथ सोच रहा था, और मैंने विचार का एक प्रोटोटाइप बनाया, यह गिटलैब दृष्टिकोण पर आधारित है:

यह वास्तव में काम नहीं कर रहा है, यह सिर्फ निश्चित डेटा है, लेकिन मुझे लगता है कि दृश्य कुछ इसी तरह का होना चाहिए। कोड यहाँ है:
https://github.com/rudineirk/gitea/blob/projects-board/templates/repo/issue/list.tmpl

कुछ जो गायब है वह है गिटलैब की तरह बोर्ड बनाने/चयन करने का दृश्य। कई टीमों के लिए बोर्ड बनाने में सक्षम होना वास्तव में उपयोगी होगा।

@rudineirk क्या आप इस पर काम करने में सक्षम थे?

मैं भी ऐसा होते देखना चाहता हूँ! यह कई छोटी टीमों को सीधे और मुख्य रूप से बाहरी के साथ संघर्ष करने के बजाय सीधे और मुख्य रूप से गीता के साथ काम करने में सक्षम बनाता है और संभवतः टैगा.
बाहरी उपकरणों के साथ मुद्दों को जोड़ने जैसी चीजें आदि संभव नहीं हैं, यह इस दृष्टिकोण का एक बड़ा बोनस है! (मुद्दे/टिकट में इसे प्रदर्शित करने के लिए अपनी प्रतिबद्धता में केवल समस्या आईडी का उल्लेख करने में सक्षम होना बहुत अच्छा है :)

मुझे इस सुविधा के बारे में वास्तव में दिलचस्पी है क्योंकि हमारी टीम वर्तमान में https://taiga.io/ का उपयोग कर रही है, लेकिन वास्तविक मूल्य कानबन/स्क्रम योजना कार्यक्षमता के साथ एक एकीकृत समस्या ट्रैकर होना है।

मुझे लगता है कि गिटहब कार्यान्वयन से सीखने के लिए बहुत सी चीजें हैं जो मूल रूप से गीता की तरह शुरू हुईं। उनका कार्यान्वयन इतना सामान्य है कि उपयोगकर्ता इसे स्क्रम और कानबन दोनों के लिए उपयोग कर सकते हैं, यहां तक ​​​​कि यह नहीं पता कि स्प्रिंट क्या है। यदि लोग कॉलम को परिभाषित कर सकते हैं और कार्ड को ड्रैग एंड ड्रॉप कर सकते हैं तो वे इसके साथ योजना बनाने का एक तरीका खोज लेंगे।

यहां मेरा समझौता है कि कानबन शैली के बोर्ड उत्कृष्ट होंगे। किसी ने अभी तक ज़ेनहब का उल्लेख नहीं किया है, जो जीथब के "ओवर द टॉप" में से कई सुविधाएँ (और अधिक) प्रदान करता है।

यहां वे चीजें हैं जो मुझे लगता है कि वास्तव में उपयोगी होंगी:

• मुद्दों के बारे में कानबन दृश्य - यह दृश्य लगभग पूरी तरह से एक यूआई होगा, कॉलम में किसी मुद्दे के कॉलम और ऑर्डर को ट्रैक करने के लिए शायद कुछ डीबी इंटरैक्शन की आवश्यकता होगी)
• गैंट चार्ट - गीता पहले से ही नियत तारीखों और निर्भरता के साथ-साथ मील के पत्थर भी प्रदान करता है, जिसका अर्थ है कि गैंट चार्ट बनाने के लिए सभी डेटा हैं, मुझे लगता है कि यह वास्तव में सहायक सुविधा होगी। मत्स्यस्त्री या रिएक्ट Google चार्ट जैसे पुस्तकालय हैं जो उचित एकीकरण लागत के लिए प्रतीत होते हैं। ध्यान दें कि #7405 इसके लिए भी मददगार होगा।
• संगठन के मील के पत्थर - इसे लागू करना शायद सबसे आसान है, लेकिन जिस तरह हमारे पास गीता के शीर्ष पर "मुद्दे" ( /issues ) फीचर है, उसी तरह एक माइलस्टोन फीचर अच्छा होगा। दूसरे शब्दों में, अगर मैं उन सभी मील के पत्थर देख सकता हूं जिनसे मैं संबंधित हूं तो यह वास्तव में अच्छा होगा। वर्तमान में, मैं केवल एक ही प्रोजेक्ट में मील के पत्थर देख सकता हूं।

निस्संदेह, उनमें से प्रत्येक अपने आप में एक विशेषता होगी। हो सकता है कि इस संयुक्त धागे को अलग-अलग विशेषताओं/घटकों में विभाजित करने की आवश्यकता हो?

संपादित करें: कोई व्यक्ति https://github.com/funktechno/git-kanban-enhanced-chrome-extension पर gita के लिए क्रोम प्लगइन जैसे ज़ेनहब पर काम कर रहा है।

@adelowo की यहां एक शाखा है जिसे लोग जांचना चाहेंगे। वह जो हैक कर रहा है, उसके लिए मैं काफी आशान्वित हूं।

एक इंस्टेंस को होस्ट करने की सादगी को देखते हुए मुझे और अधिक पीएम टाइप टूल्स को गीता में अपना रास्ता बनाना अच्छा लगेगा, हालांकि मुझे अगले साल या उससे भी ज्यादा समय में गीता में वर्कबोर्ड करने में सक्षम होने के लिए बेहद खुशी होगी। मुझे लगता है कि अगर लोग पीएम के सामान को जोर से मारना चाहते हैं तो वे अभी टैगा या विकल्प की ओर रुख कर सकते हैं और _खुश हो सकते हैं।

हाँ, अंतर यहाँ देखा जा सकता है https://github.com/go-gitea/gitea/compare/master...adelowo :kanban_board?expand=1

@adelowo जब हम एक पीआर देख सकते थे?

लगभग 8-10 दिनों में

@adelowo मुझे 500 मिल गया अगर यह _localhost/user/project_ /projects (आपके मेनू द्वारा) प्राप्त करने का प्रयास करता है:

2019/09/12 10:30:44 ...ers/repo/projects.go:62:Projects() [E] GetProjects: no such table: project

ऐसा लगता है कि डेटाबेस बूटस्ट्रैप अभी तक काम नहीं करता है @ संस्करण e7cf2b77afe50b5818c52405364faf3c914b9e63

यह अजीब है कि पलायन वहां हैं। क्या आप gitea migrate चला सकते हैं?

https://github.com/adelowo/gita/blob/kanban_board/models/migrations/v95.go

कुछ खास नहीं दिखा:

2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column email_notifications_preference db default is ''enabled'', struct default is 'enabled'
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column passwd_hash_algo db default is ''pbkdf2'', struct default is 'pbkdf2'
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column diff_view_style db default is '''', struct default is ''
2019/09/12 16:15:08 models/models.go:181:NewEngine() [W] Table user Column theme db default is '''', struct default is ''

परंतु:

# sqlite3 data/gitea.db .schema | grep proj
CREATE TABLE `repository` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `owner_id` INTEGER NULL, `lower_name` TEXT NOT NULL, `name` TEXT NOT NULL, `description` TEXT NULL, `website` TEXT NULL, `original_url` TEXT NULL, `default_branch` TEXT NULL, `num_watches` INTEGER NULL, `num_stars` INTEGER NULL, `num_forks` INTEGER NULL, `num_issues` INTEGER NULL, `num_closed_issues` INTEGER NULL, `num_pulls` INTEGER NULL, `num_closed_pulls` INTEGER NULL, `num_milestones` INTEGER DEFAULT 0 NOT NULL, `num_closed_milestones` INTEGER DEFAULT 0 NOT NULL, `num_projects` INTEGER DEFAULT 0 NOT NULL, `num_closed_projects` INTEGER DEFAULT 0 NOT NULL, `is_private` INTEGER NULL, `is_empty` INTEGER NULL, `is_archived` INTEGER NULL, `is_mirror` INTEGER NULL, `is_fork` INTEGER DEFAULT 0 NOT NULL, `fork_id` INTEGER NULL, `size` INTEGER DEFAULT 0 NOT NULL, `is_fsck_enabled` INTEGER DEFAULT 1 NOT NULL, `close_issues_via_commit_in_any_branch` INTEGER DEFAULT 0 NOT NULL, `topics` TEXT NULL, `avatar` TEXT NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL);
CREATE TABLE `issue` (`id` INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, `repo_id` INTEGER NULL, `index` INTEGER NULL, `poster_id` INTEGER NULL, `original_author` TEXT NULL, `original_author_id` INTEGER NULL, `name` TEXT NULL, `content` TEXT NULL, `milestone_id` INTEGER NULL, `project_id` INTEGER NULL, `priority` INTEGER NULL, `is_closed` INTEGER NULL, `is_pull` INTEGER NULL, `num_comments` INTEGER NULL, `ref` TEXT NULL, `deadline_unix` INTEGER NULL, `created_unix` INTEGER NULL, `updated_unix` INTEGER NULL, `closed_unix` INTEGER NULL, `is_locked` INTEGER DEFAULT 0 NOT NULL);
CREATE INDEX `IDX_issue_project_id` ON `issue` (`project_id`);

@genofire क्या आप फिर से देख सकते हैं? मैंने इसे https://github.com/adelowo/gitea/commit/812f256cdeed312877787b383279c30c5cda9a4f में ठीक किया

मेरे लिए काम करता है, thx - यहाँ कुछ छोटे मुद्दे:

उच्च प्रियो:

• [] बोर्डों के बीच मुद्दों को स्थानांतरित करें
• [x] वर्तमान अंक में परियोजना जोड़ें
• [x] प्रोजेक्ट देखें

- [x] प्रोजेक्ट बनाएं

मध्यम प्रियो:

• [] प्रोजेक्ट आइकन (एटीएम वही मर्जरक्वेट)
• [] प्रोजेक्ट देखने के दौरान समस्या पैदा करें
• [ ] इश्यू बनाने के दौरान प्रोजेक्ट का चयन करें

कम प्रियो:

• [] बोर्ड का नाम बदलें
• [] बोर्ड जोड़ें
• [] बोर्ड हटा दें
• [] बोर्ड ले जाएँ
• [ ] खोज के बगल में Label | Milestone ड्रॉप करें
• [] उन्हें प्रोजेक्ट में जोड़ने के लिए समस्या की खोज करें (अप्रयुक्त)

हालांकि मुद्दों को बोर्डों में स्थानांतरित किया जा सकता है।

इस सूची के लिए धन्यवाद। समस्या बनाते समय अब ​​प्रोजेक्ट का चयन किया जा सकता है। कृपया नवीनतम खींचें

https://github.com/go-gitea/gitea/commit/c55d44e0233f46094fbebd33feac82e5072e1ba7

मैंने https://github.com/go-gitea/gitea/pull/8346 पर एक पीआर सबमिट किया है

हालांकि मुद्दों को बोर्डों में स्थानांतरित किया जा सकता है।

संग्रहीत नहीं होता है, एक पुनः लोड इसे Uncategorized रीसेट करता है

समस्या बनाते समय अब ​​प्रोजेक्ट का चयन किया जा सकता है।

परियोजना की सूची नहीं दिखाता

हम्म, मैं फिर से देख लूंगा। आइए फीचर चर्चा को पीआर पर ले जाएं ताकि यह सब एक ही स्थान पर हो।

धन्यवाद

शून्य मूल्य टिप्पणी: ऐसा होने की प्रतीक्षा नहीं कर सकता, :शिपिट: :रॉकेट: :चार_पत्ती_क्लोवर:

कृपया #8346 प्रयास करने में मदद करें और अधिक सलाह दें।

क्या इस मुद्दे पर कोई अपडेट है? (पिछली पोस्ट को एक महीना हो गया है।)

संपादित करें: मुझे नहीं पता था कि कुछ लोग (जैसे @storrgie) अपने काम में दिलचस्पी रखने वाले लोगों से नाराज हो सकते हैं। मेरा मतलब किसी को ठेस पहुंचाना नहीं था।

@tinxx आप या तो:

• पीआर का निर्माण करें जो ऊपर से जुड़ा हुआ है और वास्तविक पीआर में प्रतिक्रिया प्रदान करता है
• लोगों को इस पर काम करने के लिए वित्तीय रूप से प्रेरित करने का एक तरीका खोजें (उदाहरण के लिए दान के लिए सीधे @adelowo से संपर्क करें या इस पर अधिक नज़र पाने के लिए

जब आप आर्थिक या बौद्धिक रूप से योगदान नहीं दे रहे हैं, तो आप काम करने के लिए चिल्लाते नहीं हैं, यह खुले स्रोत में जहरीला है।

Jetbrains ने हाल ही में YouTrack का नया संस्करण gitea इंटरग्रेशन के साथ जारी किया है

@adelowo कोई खबर?

इस बीच एक और सुझाव: कनबोर्ड

यह वास्तव में एक आंख कैंडी नहीं है (बॉक्स से बाहर) लेकिन यह तेज़ है और बहुत उपयोगी होने के लिए पर्याप्त सुविधाएं प्रदान करता है।

पूछने वाले: कृपया पीआर पर एक नज़र डालें। ऐसा लगता है कि यह बहुत दूर नहीं है: पलक:

हाँ @gsantner । बस कुछ UI सुधार बाकी हैं। जो मुझे इस सप्ताहांत में मिलनी चाहिए

@adelowo यह कब उपलब्ध होगा इस पर कोई खबर?

@zuhairamahdi इसे 1.12.0 में रिलीज़ करने की योजना है। अधिक के लिए #8346 पीआर देखें।

क्या मल्टीबल प्रोजेक्ट्स और/या बोर्ड्स पर कोई दिलचस्पी है?

https://github.com/go-gita/gitea/pull/8346#issuecomment -617175388

मुझे लेबल से बाहर स्क्रम/कानबन "बोर्ड" बनाने और उन्हें एक अलग दृश्य में बदलने की अनुमति देने के गिटलैब दृष्टिकोण को पसंद है ... वास्तव में कुछ भी नहीं बदलता है, यह सिर्फ एक अलग दृश्य है, लेकिन एक बहुत ही उपयोगी आईएमएचओ है।

मुझे यह सुविधा भी याद आ रही है। यदि आप किसी समस्या के लेबल को अलग-अलग लेन/प्रोजेक्ट बोर्डों में ले जाने पर अपडेट हो जाते हैं तो यह बहुत अच्छा होगा। प्रतिबद्ध संदेशों (यानी Fixes #1 ) में कार्रवाई योग्य संदर्भों द्वारा लेबल बदलना और इस प्रकार लेन के बीच मुद्दों को स्थानांतरित करना भी उपयोगी होगा।

@0xC4N1 कृपया एक नया अंक भेजें, मुझे लगता है कि हम इस सुविधा में और सुधार कर सकते हैं।