Pods: تسميات جيثب

~ "يحتاج إلى سجل التغيير" حيث يمكن أن يكون التصنيف قادرًا على الانتقال. لقد كنت أجعل تحديثات سجل التغيير جزءًا من عملية الدمج ولم أستخدم تلك التسمية قصيرة العمر
منتهي

لم يكن لدي الوقت الكافي لاستخدام مشط ذو أسنان رفيعة ، لكنني لا أرى أي شيء صارخًا على الفور في المقشدة الأولى. قد أجد بعض التعديلات والإغفالات والحذف على مسار ثابت ولكن غرائزي ستكون بمثابة تحسن كبير على نظام الملصقات الحالي كما هو مقترح.

"التصحيح" هو أحد الأساليب التي لم أستخدمها مطلقًا في سير العمل الخاص بي ، حيث يبدو لي أنه لا لزوم له. إذا كانت عبارة عن علاقات عامة ، فهي عبارة عن رقعة. لكن @ sc0ttkclark استخدم هذه التسمية بشكل تقليدي ، لذلك قد يكون لها بعض قيمة سير العمل بالنسبة له.

سيكون ~ Component: Multi-site إضافة جيدة ، وهذه منطقة أخرى مثل REST API ، والقوالب التي قد تكون مفيدة لبدء وضع العلامات لأغراض التصفية. ~

منتهي

التركيز: التوافق مع الإصدارات السابقة
التركيز: التوافق / الاستنكار
التركيز: التوافق

بالنسبة إلى هؤلاء الثلاثة ، ربما يتم تنقيتها:

Focus: Backward Compatibility
Focus: Deprecation
Focus: Third Party Compatibility

تحرير: يتم ذلك

إلى جانب تلك الأشياء الصغيرة حتى الآن ، سأذهب جميعًا في هذا الأمر. التصنيف أفضل بكثير وأود استخدامه على الرغم من 2.7.7.

أريد الحصول على إبهام صريح من jimtrue و @ sc0ttkclark أيضًا ، أولاً.

ما الفرق بين Discussion و Team Discussion ؟ هل يمكن استبدالها بـ Needs: Developer Feedback ؟

ما هو Integration ؟

ها هي المرة الثانية. بعض الإضافات / التغييرات الجديدة. يمكن إسقاط العلامات التي تحمل علامات استفهام رئيسية إذا لم يتم استخدامها:

Closed: Could not reproduce
Closed: Duplicate
Closed: Invalid
Closed: Out of scope
Closed: Won't Fix

Component: CSS
Component: docs.pods.io
Component: DFV
Component: Front-end Forms
Component: Multisite
Component: Pods Templates/Magic Tags
Component: REST API
Component: support.pods.io
Component: UI
Component: Unit Testing
Component: WP Admin

Focus: Accessibility
Focus: Backward Compatibility
Focus: Deprecation
Focus: Third-Party Compatibility
Focus: I18n
? Focus: Integration
Focus: Performance

? Keyword: Discussion
Keyword: Focus
Keyword: Forums
Keyword: Friends of Pods Priority
Keyword: Good First Issue
Keyword: Has Bounty
? Keyword: Patch: Manually Merged
? Keyword: Patch
Keyword: Plugin Material
Keyword: Puntable
Keyword: Release
Keyword: Support
? Keyword: Team Discussion
Keyword: Tools
Keyword: VIP

Needs: Developer Feedback
Needs: Research
Needs: Tasklist
Needs: Test(s)
Needs: User Feedback
Needs: Verification/Reproduction
Needs: Votes

Priority: Blocker

Type: Bug
Type: Code Standards
Type: Inline Documentation
Type: Enhancement
Type: Feature
Type: Refactor
? Type: Regression

Status: Fixed / Needs Testing
Status: Help Wanted
Status: Hold
Status: In progress
Status: Pulled for Review
Status: Ready for merge
Status: Ready for review
Status: Researched
Status: Unit Tested
Status: Verified/Reproduced

ما الفرق بين المناقشة ومناقشة الفريق؟ هل يمكن استبدالها بالاحتياجات: ملاحظات المطور؟

ليس كثيرًا ، ستكون المناقشة مفتوحة للعالم وستكون مناقشة الفريق داخلية. لا أعتقد أننا بحاجة إلى أن تكون تسمية مناقشة عامة واحدة دقيقة للغاية (ربما كان التكرار غير مقصود). تُستخدم ملاحظات Dev بشكل عام كحالة ، وعادةً ما تكون بطاقة معلقة لتعليقات المستخدمين وتلقي التعليقات المذكورة.

ما هو التكامل؟

في الأساس ، يتم تقديم الطلبات التي تتضمن التكامل مع المكونات الإضافية والمكتبات والموضوعات الأخرى وما إلى ذلك. أفترض أن الأخطاء المتعلقة بالتكامل الحالي قد تندرج تحت هذه المظلة ولكن غالبًا ما تكون أكثر ملاءمة باعتبارها "توافق" بمجرد أن يكون لدينا تكامل. (لذا من المحتمل أن يكون التكامل نوعًا على الرغم من أنه ربما يكون أكثر منطقية في التركيز كما فعلت)

لست متأكدًا من أن قسم "الاحتياجات:" أفضل ... لقد أحببت فكرة هؤلاء كجزء من "الحالة:" حيث أعتقد أن هذا غالبًا ما يتم استخدامه.

تحرير: تم معالجة هذا كله

~ أعتقد أن الكلمات الرئيسية التالية قد تكون في الواقع النوع: الإصدار ، والدعم ، والأدوات. ~

~ هذه تبدو كأنواع من التذاكر لم يتم وصفها بشكل جيد من قبل أي من الآخرين. ~

منتهي

أيضًا ، من أجل التمرير ، أتساءل عما إذا كان يجب علينا الاحتفاظ بالقائمة في الرسالة الأولية محدثة بدلاً من نشر إصدارات جديدة أثناء التنقل؟

منتهي.

تعجبني فكرة هذا:

الاحتياجات: ملاحظات المطور
الاحتياجات: البحث
الاحتياجات: قائمة المهام
الاحتياجات: الاختبار (الاختبارات)
الاحتياجات: ملاحظات المستخدم
الاحتياجات: التحقق / الاستنساخ
الاحتياجات: الأصوات

لكن "ملاحظات المستخدم" و "التحقق / الاستنساخ" هي في الحقيقة "حالة / سير عمل" كما هو موضح أعلاه

يجب أن يتم تقليص حالة سير العمل بشكل مثالي وصولاً إلى الحارات في المشروع. بالنظر إلى قائمة الملصقات هذه ، لم يكن لدي أي فكرة أن لدينا الكثير ، لكنني أعتقد أنكم أنتم يا رفاق أنشأتوا مجموعة أخرى.

لا يجب أن يكون support.pods.io و docs.pods.io هنا على الإطلاق (لدينا مستودعات لهذين الموقعين) ، إلا إذا كنا نخطط لاستخدام GitHub لتحديثات الدعم والتوثيق. إذا كنا سنقوم بذلك (وهو ما أعمل عليه جميعًا) ، فسنضيف بادئة لـ Docs: و Support: وننشئ مشروعين في GitHub في هذا المستودع للدعم والتوثيق. نظرًا لأن مشكلة الدعم قد تتحول أحيانًا إلى تحسين / ميزة فعلية للشفرة أو إصلاح خطأ ، فمن المنطقي بالنسبة لنا استخدام نفس الواجهة. بالتأكيد سيكون لدينا المزيد ، لكننا سنتأكد أيضًا من حصولنا بالضبط على ما نحتاجه لمشاكل الدعم وتحديثات الوثائق.

نظرت في هذا ، وأود أن أرى التغييرات التالية:

• النوع : أضف Support & Docs Update (إزالة Support من Keyword )
• المكون : لسنا بحاجة إلى support.pods.i o أو doc.pods.io في Component . لهذين الريبو مشاريعهم الخاصة. يجب أن يكون المكون بالكامل لمنطقة تركيز Pods Core.
• الأولوية : انقل Focus من Keyword إلى Priority . Blocker جيد طالما أننا نعرف السبب ، والذي يجب أن يأتي من الاحتياجات .

لذلك إذا اتبعت هذا بشكل صحيح ، فيجب أن يحتوي كل شيء على:
النوع : يحدد نوع التذكرة.
الحالة : تحدد مكانها في سير العمل. مناقشة قليلا على ما وضع يجب أن تكون 'محظور' أو 'تودو' أو 'عقد' إذا كنا بحاجة رأيك أو التأكيد / الاستنساخ. لست متأكدًا من حالة طلب الميزة / التحسين حيث تكون الاحتياجات هي الأصوات. ربما يتبع هؤلاء نفس التنسيق للوحة Kanban النموذجية وحالتهم هي BackLog حتى يتم العمل بنشاط. يشير Blocker إلى أنه لا يمكن تشغيله حتى يتم التعامل مع الاحتياجات.
المكون : يحدد منطقة Pods Core للميزة / التحسين / الخطأ
الكلمات الرئيسية والتركيز فقط لمزيد من التوضيح؟

لقد قمت بإزالة WaffleBot لذلك لا يجب إضافة هذه الحالات تلقائيًا بعد الآن.

يشير Blocker إلى أنه لا يمكن تشغيله حتى يتم التعامل مع الاحتياجات.

هذه حالة لا نستخدم فيها تسمية بنفس النوايا. لقد استخدمت دائمًا Blocker (وأعتقد أن Scott أيضًا) للمشكلات التي تمنع إصدارًا (أو ربما تذكرة أخرى) ويجب القيام بها ؛ لا يمكن رميها.

لا يوجد سبب في سير العمل لي لوضع علامة على شيء ما على أنه يحتفظ بشيء ما عبر "Blocker" ... يجب أن تشير تسميات الحالة الحالية إلى ذلك. لست بحاجة إلى "أحتاج إلى تعليقات المستخدم" بالإضافة إلى "أداة الحظر" لأن أول واحد يخبرني بالفعل أنه يحظر ولماذا.

تصويتي هو أننا نستخدمه بهذه الطريقة ونحتفظ به ضمن "الأولوية: *" لأنه وصف مثالي بالنسبة لي.

~ أعتقد أن "التركيز" يجب أن ينتقل أيضًا من الكلمات الرئيسية إلى الأولوية. ~ ترك الكلمات الرئيسية

تعجبني فكرة هذا:

الاحتياجات: ملاحظات المطور
الاحتياجات: البحث
الاحتياجات: قائمة المهام
الاحتياجات: الاختبار (الاختبارات)
الاحتياجات: ملاحظات المستخدم
الاحتياجات: التحقق / الاستنساخ
الاحتياجات: الأصوات

هذه هي حالات التذاكر بشكل أساسي بالنسبة لي ، لذا أقترح الاحتفاظ بها هناك في الوقت الحالي. إذا كان الطول هو مصدر القلق ، فقد نختصر بعضًا منها ("الحالة: تحتاج إلى Dev FB" ، "الحالة: Need Verification / Repro").

أعتقد أن "قائمة المهام تحتاج" يمكن أن تذهب. لا أعتقد أن ذلك يحدث بما يكفي لتبرير التسمية. لست متأكدًا من أنني استخدمته على الإطلاق ، نادرًا إذا كان الأمر كذلك. ربما نفس الشيء بالنسبة "لاختبارات الاحتياجات". كل ما تبقى منها يناسبني تمامًا ضمن "الحالة: *".

أيضًا ، القائمة تتشكل بشكل جيد بالنسبة لي ، ربما ينبغي أن نناقش نظام الألوان.

زوجان آخران يمكن قصهما من "الحالات" جنبًا إلى جنب مع "قائمة المهام المطلوبة":

• ~ "تم السحب للمراجعة" ربما يكون مجرد تكرار غير مقصود لـ "جاهز للمراجعة" ~ تركه
• "الوحدة التي تم اختبارها" ليست حالة (ليس على الأقل بعد) ، فهي متنوعة أكثر ... لذا من المحتمل أن يتم نقلها إلى الكلمات الرئيسية؟

هذا يترك قائمة الحالة تبدو جيدة بالنسبة لي.

"تم السحب للمراجعة" على الأرجح مجرد تكرار غير مقصود لـ "جاهز للمراجعة"

تعارض. إذا قمت بإنشاء علاقات عامة ، فعندها عندما تكون جاهزة ، سأضيف جاهز للمراجعة. ولكن قد لا يكون لديك الوقت لإجراء هذه المراجعة حتى وقت لاحق - ولكن بحلول ذلك الوقت ، لم يكن سكوت متأكدًا مما إذا كنت قد بدأت المراجعة أم لا. باختصار ، هناك مجموعتان مختلفتان من الأشخاص يضيفان جاهزًا للمراجعة وسحبًا للمراجعة.

ربما نفس الشيء بالنسبة "لاختبارات الاحتياجات".

من أجل الرغبة في المزيد من تغطية الكود (على الرغم من أنني لم أبحث شخصيًا في هذا المجال كثيرًا) ، يمكن أن تكون هذه التسمية للقول إن "الإصلاح جيد ، لكننا نرغب في رؤية اختبارات الوحدة تغطي الحواف / التحقق إصلاح الخلل المحدد بحيث لا يتم إدخال أي انحدار ".

أعتقد أن "التركيز" يجب أن ينتقل أيضًا من الكلمات الرئيسية إلى الأولوية.

ستكون الأولويات عمومًا - منخفضة ، متوسطة ، عالية ، حرجة ، مانعة - لها دلالات مختلفة (في ذهني على الأقل) للتركيز. تسمية Keyword: Focus ليس لها أي صلة بمفردها ما لم يكن هناك حدث رئيسي لتحديد الإصدار الذي يمثل المشكلة موضع تركيز _for_. في حين أن الأولوية لا تتضمن سياق ، بقدر ما تنطبق على المشروع ككل. لا أعتقد بالضرورة أن إضافة الأولويات الأخرى فكرة جيدة ، لكن بالمقابل لا أعتقد أن التركيز يمثل أولوية. ربما ما نحاول قوله هو أن "هذه التذكرة تمثل حدثًا مميزًا - إنها لعبة رائعة يجب أن تصرخ بشأنها في الإصدار التالي" ، وإذا كان الأمر كذلك ، فقد يكون من الأفضل استخدام كلمة مختلفة للتركيز للإشارة إلى النية.

يشير Blocker إلى أنه لا يمكن تشغيله حتى يتم التعامل مع الاحتياجات.

أنا أتفق مع Phil هنا - لقد فهمت أن الأمر يعني أن المشكلة التي تحمل هذه التسمية هي مانع للإصدار _. ربما يكون تفسير جيم أكثر ملاءمة لتصنيف Status: Is Blocked أو ما شابه ، على الرغم من أن Needs: * سيشير إلى نفس الشيء.

راجع للشغل ، هل من المقبول حذف القائمة المؤقتة هنا: # 5016 (تعليق)؟

pglewis انطلق وقم بإزالة (أو إخفاء في <details>...</details> كمرجع تاريخي) كل ما تريد.

يجب ألا يكون support.pods.io و docs.pods.io هنا على الإطلاق

كان هذا أنا من إضافتهم بسبب عدم اليقين بشأن علامة "تحسين المستندات" الحالية (مقابل المستندات: مضمنة) - يمكن إزالتها إذا تم التعامل معها في مكان آخر.

قد يكون من الأفضل كتابة تحسين محرّر المستندات كـ "مستندات: مضمن" "محرر مستندات: أمثلة" محرر مستندات: تلميحات أدوات "وهذا النوع من الأشياء. ما لم نتعامل مع سير عمل التوثيق (أي الوثائق المكتوبة في موقع docs.pods.io) في GitHub ، فلا يوجد سبب لذلك هنا. أي تحسينات في المستندات داخل الكود الخاص بنا تعني المستندات _in_ الكود الخاص بنا أو تتم إدارتها داخل الكود الخاص بنا أو مثل الملف التمهيدي الذي يتم تحليله ودفعه إلى مستودع البرنامج المساعد WordPress.org.

يعجبني Status: Is Blocked لأنه مفيد للغاية ، ولكن إذا فعلت شيئًا من هذا القبيل ، فإنه يتطلب: * أيضًا

كما قلت ، كل شيء يحصل على Type و Status . إلى أن نقوم بإدارة مشروع Agile بالكامل باستخدام GitHub ، لا يلزم تحديد الأولويات هناك ويتم تمثيلها بشكل أفضل من خلال وحدات العمل المطلوبة لإنجاز "القصة". لقد استخدمنا التركيز دائمًا للتمييز بين العناصر في مئات المشكلات التي يجب التركيز عليها في إصدار الصيانة التالي.

أفكاري الوحيدة هي فيما يتعلق بعلامات UI / CSS ، لأن تلك هي أكثر ما أتعامل معه ... يبدو أنه ربما مجرد إزالة CSS كمكون والاعتماد على واجهة المستخدم فقط هو الأكثر منطقية بالنسبة لي. لست متأكدًا مما إذا كان لديك أي أفكار هناك ، ولكن CSS هي النتيجة ، وليس الشيء الملموس الذي يحتاج إلى الإصلاح ... إذا كان ذلك منطقيًا. ستكون واجهة المستخدم هي الشيء الملموس الذي يجب العمل عليه أو تحسينه ، وستكون css هي النتيجة أو كيفية إصلاحها. وإلا فأنا أحب ذلك 👍

أفكاري الوحيدة هي فيما يتعلق بعلامات UI / CSS ، لأن تلك هي أكثر ما أتعامل معه ... يبدو أنه ربما مجرد إزالة CSS كمكون والاعتماد على واجهة المستخدم فقط هو الأكثر منطقية بالنسبة لي. لست متأكدًا مما إذا كان لديك أي أفكار هناك ، ولكن CSS هي النتيجة ، وليس الشيء الملموس الذي يحتاج إلى الإصلاح ... إذا كان ذلك منطقيًا. ستكون واجهة المستخدم هي الشيء الملموس الذي يجب العمل عليه أو تحسينه ، وستكون css هي النتيجة أو كيفية إصلاحها.

نعم ، هناك صقل يجب القيام به هناك. لقد استخدمت ملصق CSS في الغالب كإشارة Bat لك و / أو Jory للتصفية نظرًا لأنك كنت أفضل اللاعبين في هذا الاتجاه.

سأصوت لمغادرة CSS و UI كما هو مقترح في الوقت الحالي ولكن يمكننا بالتأكيد مواصلة تحسينها بعد المرحلة الأولى.

RE: يحتاج إلى اختبارات

من أجل الرغبة في المزيد من تغطية الكود (على الرغم من أنني لم أبحث شخصيًا في هذا المجال كثيرًا) ، يمكن أن تكون هذه التسمية للقول إن "الإصلاح جيد ، لكننا نرغب في رؤية اختبارات الوحدة تغطي الحواف / التحقق إصلاح الخلل المحدد بحيث لا يتم إدخال أي انحدار ".

الحقيقة هي أننا بحاجة إلى مواكبة إصلاحات الصيانة ، والعمل على فرع تحرير ، والحاجز الذي يحول دون كتابة اختبارات جديدة مرتفع إلى حد ما حتى بالنسبة للأشياء البسيطة. يمكننا ترك الملصق هناك ولكن ليس من المحتمل أن يتم استخدامه كثيرًا حتى يتم إجراء المزيد من إعادة البناء ، ونقدم اختبارات وحدة فعلية ، و / أو لدينا المزيد من الموارد لتخصيصها.

سيكون "النوع: الاختبارات" إضافة جيدة على الرغم من أن الاختبارات المضافة الآن من المحتمل أن تكون أفضل مثل أزواج المشكلات / العلاقات العامة الخاصة بهم.

تعجبني الحالة: محظورة لأنها مفيدة للغاية ، ولكن إذا فعلت شيئًا من هذا القبيل ، فإنه يتطلب: * أيضًا

أنا بخير لتركها ، لكنني في الأساس حالة تتبع واحدة ولم أحتج مطلقًا لوضع علامة على أي شيء "محظور" كحالة. أي شيء يكون هذا الاتجاه الغامض الذي صادفته يتم تغطيته بشكل أفضل من خلال "القابضة".

وفي حالة المساعدة في توضيح أي شيء ، فهذا هو سير العمل النموذجي الذي أستخدمه في خطأ متوسط:

• الفرز: التصفية غير الصالحة ، الدعم ، الميزة / التحسين ؛ تعيين نوع الخطأ
• عادةً تنتقل الحالة على الفور إلى "بحاجة إلى التحقق / إعادة المحاولة"
• قد يتنقل ذهابًا وإيابًا بين "يحتاج إلى تعليقات المستخدم" و "يحتاج إلى تعليقات المطورين" خلال العمر الافتراضي
• تم التحقق منه / مستنسخ
• يحتاج البحث: الآن بعد أن عرفنا كيفية تحقيق ذلك اكتشف وفهم السبب
• تم البحث: ربما أنا الوحيد الذي يستخدم هذا. تم إجراء إشارات غوص عميق في مرحلة ما وربما لدي تفاصيل داخلية مخزنة في رأسي
• ثابت / يحتاج إلى اختبار

تعارض. إذا قمت بإنشاء علاقات عامة ، فعندها عندما تكون جاهزة ، سأضيف جاهز للمراجعة. ولكن قد لا يكون لديك الوقت لإجراء هذه المراجعة حتى وقت لاحق - ولكن بحلول ذلك الوقت ، لم يكن سكوت متأكدًا مما إذا كنت قد بدأت المراجعة أم لا. باختصار ، هناك مجموعتان مختلفتان من الأشخاص يضيفان جاهزًا للمراجعة وسحبًا للمراجعة.

أعتقد أن تصنيف Hold كان تاريخيًا أفضل من Pulled for Review في تلك الحالات.

لمعلوماتك ، في الماضي ، استخدمت Blocker للإشارة إلى مشكلة تمنع إصدارًا.

يمكننا إزالة "التصحيح" ، لقد بدأت باستخدام ذلك عندما كان لدى GitHub المزيد من المربك لتجربة المستخدم بين العلاقات العامة والمشكلات ، كان من الأسهل رؤية عرض "الإصدار" مع التصحيحات بشكل أساسي للعودة إلى الأشياء الخاصة بأشياء التغيير. نحن لا نحتاجها.

هل القائمة الواردة في وصف المشكلة الأصلي محدثة بالتغييرات التي ناقشناها جميعًا؟

هل القائمة الواردة في وصف المشكلة الأصلي محدثة بالتغييرات التي ناقشناها جميعًا؟

ربما ليس تمامًا ، فلا تتردد في تحسين بعضها إذا كنت تريد ذلك. سأمر بذلك بمجرد أن يكون لدينا إبهام كامل لأعلى ومشط لأي شيء قررنا أنه لم يتم تحديثه.

مهما قررنا هنا ، نحتاج إلى التقديم على جميع مستودعات Pods الأخرى الخاصة بنا باستخدام أداة مثل https://github.com/dwyl/labels لمزامنتها.

نقل "الانحدار" من النوع إلى الكلمات الرئيسية. لا يزال الخطأ نوعًا من مشكلات الانحدار.

تم تنفيذ هذا إلى حد كبير الآن. بعض الأشياء المتنوعة التي علقتها للتو ضمن "الكلمات الرئيسية" في الوقت الحالي.

الألوان هي الشيء الرئيسي الذي يجب القيام به في هذه المرحلة.

؟ مغلق: غير صالح

أود أن أقترح الاحتفاظ بهذا واحدًا على الأقل ، ربما لن يتم إصلاحه أيضًا. إنها قرارات قياسية إلى حد ما على أجهزة تتبع الأخطاء الأخرى.

الألوان هي الشيء الرئيسي الذي يجب القيام به في هذه المرحلة.

تعتبر الألوان ثانوية في هذه المرحلة - قم بتنفيذ الملصقات ، وحدد نظام الألوان لاحقًا.

أود أن أقترح الاحتفاظ بهذه الصورة [غير صالحة] على الأقل ، وربما لن يتم إصلاحها أيضًا. إنها قرارات قياسية إلى حد ما على أجهزة تتبع الأخطاء الأخرى.

سأضيف غير صالح ، لقد وضعت علامة عليه كتذكير لأنه لم يكن لدينا بالفعل.

"لن تصلح" هي واحدة من تلك التي أكره نبرة صوتها. بالإضافة إلى موقفي هو أنه يجب أن يكون لدينا تصنيف مع سبب محدد أفضل لعدم إصلاح شيء من "لن يتم إصلاحه".

تعتبر الألوان ثانوية في هذه المرحلة - قم بتنفيذ الملصقات ، وحدد نظام الألوان لاحقًا.

يتم تنفيذ التسميات إلى حد كبير.

هل نحتاج إلى "Type: GitHub" أو شيء مشابه؟ هذه القضية ليس لها نوع.

Type: Project ؟

ماذا لو استخدمنا "اترك كما هو" بدلاً من "لن يتم الإصلاح" أو شيء من هذا القبيل؟

ماذا لو استخدمنا "اترك كما هو" بدلاً من "لن يتم الإصلاح" أو شيء من هذا القبيل؟

إنه موقف غير مألوف ، لذا فقد قطعناه كل هذا الوقت دون الحاجة إلى شيء من هذا القبيل. أصوت لأنتظر إضافة أي شيء هناك حتى يظهر مثال محدد.

أيضًا ، لقد اتخذت بعض قرارات الألوان التعسفية لبعض المجموعات. لم يتم وضع أي شيء على الحجر هناك.

أعتقد أنه يمكننا على الأرجح إغلاق هذه المشكلة في هذه المرحلة ومناقشة أي تحسينات أخرى عبر Slack.

What if instead of "Won't Fix" we used "Leave as is" or something like that?

إنه موقف غير مألوف ، لذا فقد قطعناه كل هذا الوقت دون الحاجة إلى شيء من هذا القبيل. أصوت لأنتظر إضافة أي شيء هناك حتى يظهر مثال محدد.

أنا موافق. ليس كل ما يحتاجه WordPress الأساسية يحتاج إلى تكرار

أنا موافق. ليس كل ما يحتاجه WordPress الأساسية يحتاج إلى تكرار

إنها أيضًا إحدى التسميات الافتراضية عند إعداد ريبو جديد على GH - راجع https://github.com/GaryJones/daterange/labels الذي يحتوي على الملصقات الافتراضية.

I agree. Not everything that WordPress core does needs to be duplicated

إنها أيضًا إحدى التسميات الافتراضية عند إعداد ريبو جديد على GH - راجع https://github.com/GaryJones/daterange/labels الذي يحتوي على الملصقات الافتراضية.

لا أتذكر متى أصبحت علامة افتراضية لـ GitHub ، لكنها كانت دائمًا علامة فظيعة لإرفاقها بتذكرة من مساهم متطوع. لقد رأيت عددًا قليلاً جدًا من المشكلات على GitHub مع هذه العلامة ، ولكن في عالم WordPress ، تتم تغطية معظم تذاكر الإصلاح العادي بمشكلة أخرى ، أو تحتاج إلى مزيد من المعلومات لتبرير الإصلاح ، أو فقط آمل ألا يعود أحد يشكو (غالبًا ما يحدث) .

سوف تتمسك بكرهتي. سؤالي الفوري حول "لن يتم الإصلاح" هو "لماذا نرفض إصلاح شيء ما؟" وإذا أعطاني أحدهم إجابة موجزة جيدة على ذلك على التذكرة ، فسأقول _that_ هو ما يجب أن يقرأه الملصق بدلاً من "لن يتم إصلاحه".

أعتقد أن Out of Scope هو إجابة أفضل على أي حال. لن يُصلح فقط يعني ضمنيًا ويقدم "لا شيء" للشخص الذي يفتح المشكلة.

ربما يمكن أن يسير في الاتجاه - لا تتردد في إرسال "حل" لكن الفريق ليس لديه الموارد الكافية للقيام بذلك: D ربما يكون لدى شخص ما فكرة عن اختصار قصير لها ^^

قد تكون حالة الاستخدام عبارة عن خطأ أو انتهاك CS في بعض الميزات ، وهذا يعني إعادة كتابتها بالجملة وإصدارها في الإصدار التالي على أي حال.

لا تتردد في تركها خارجا مع ذلك.