Partkeepr: ميتا: عدد كبير جدًا من المشكلات المفتوحة

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

لذلك نقوم في الأساس بإنشاء "تراكم" بحكم الأمر الواقع ...

نوعا ما. لكن ، نعم ، هذه هي الفكرة الأساسية.

Drachenkaetzchen ، هل أنت منفتح على إضافة اثنين منا إلى المشروع حتى نتمكن من تقديم بعض النظام إلى المشكلات؟

سأكون على استعداد للمساعدة هنا ، إذا رغبت في ذلك.

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

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

حسنًا christianlupus لقد أضفتك كعضو في Triage إلى هذا المستودع.
baradhili هل أنت مهتم أيضًا بالمساعدة في هذا؟

فيما يلي وصف لإمكانيات هذا: https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization

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

dromer نعم من فضلك

dromer شكرا على الإضافة.

الاقتراح الأول هو إضافة تصنيف needs-triage وإعداد قاعدة لوضع كل إصدار جديد و PR في هذا التصنيف.
السبب: يرى المراسل أن الفرز ضروري / سيتم القيام به. علاوة على ذلك يمكننا الفرز (لاحقًا) لمثل هذه القضايا. ربما يجب أن نفكر في وضع كل قضية تحت هذا التصنيف من أجل معرفة ما تم فعله بالفعل وما الذي يحتاج إلى الاهتمام.

بالإضافة إلى ذلك: أقترح أيضًا التسميات التالية:

• meta : يستخدم للمشكلات التي لا تتعلق بالكود نفسه ولكن الريبو والويكي ومعايير البرمجة وما شابه.
• help-requested : يستخدم للإشارة إلى أن هناك مشكلة تبحث عن المساعدة أثناء الإعداد والاستخدام وما إلى ذلك. قد يكون من الأفضل دفع هذا إلى منتدى بدلاً من الاحتفاظ به كمشكلة هنا على github.

يبدو جيدًا .. على الرغم من أنني أقترح ألا نضع كل شيء تحت needs-triage لأننا سننتهي ببساطة إلى ما نحن فيه الآن :) .. أقترح أيضًا backlog ، next-release و roadmap بمجرد أن نحصل على الأشياء قيد المراجعة

عندما بدأت في تصنيف بعض المشكلات الآن ، وجدت صعوبة في وضع تسميات عليها ما لم يتم تحديدها بوضوح (على الأقل لجزء منها).

@ christianlupus كيف تريد تنسيق الفرز؟ أنا في UTC + 8

christianlupus يبدو أننا قد نحتاج إلى علامة أخرى "move-to-wiki"

@ christianlupus كيف تريد تنسيق الفرز؟ أنا في UTC + 8

baradhili أنا في UTC + 1 (برلين).
كنت أعطي بعض المشكلات بعض الملصقات وحدثًا هامًا عند الاقتضاء. ومع ذلك ، فقد حان الوقت لي للذهاب إلى العمل الآن. لذلك سوف أتوقف الآن.

هل لديك أي اقتراحات جيدة حول التنسيق؟ شخص واحد في الصباح شخص واحد في المساء لتجنب الاصطدامات؟ ما هو الوقت المفضل لديك للعمل عليه؟

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

christianlupus يبدو أننا قد نحتاج إلى علامة أخرى "move-to-wiki"

نعم ، يبدو أن هذا هو الحال.

christianlupus أعمل على حل مشكلات قديمة bug في الوقت الحالي .. أعتقد أنه يمكنني

dromer إذا قدمنا ​​لك قائمة

أوه ، هل هذا شيء علي أن أفعله؟

اسمحوا لي أن أعرف وسأبحث في إضافة المزيد.

christianlupus أعمل على حل مشكلات قديمة bug في الوقت الحالي .. أعتقد أنه يمكنني

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

ربما نرغب في الإبلاغ عن المشكلات المعقدة باستخدام علامة kinda حتى يمكن للآخر إلقاء نظرة وإبداء الرأي ..

نعم ، أعتقد أن هذه فكرة جيدة. ماذا عن complex-triage ؟

أوه ، هل هذا شيء علي أن أفعله؟

اسمحوا لي أن أعرف وسأبحث في إضافة المزيد.

يمكننا فقط إرفاق تسميات ومعالم للمشكلات. لكن لا يمكننا إضافة تسميات جديدة إلى قائمة العلامات الصالحة. لذا ، نعم ، نطلب منك إضافة الملصقات ذات الصلة.

baradhili لذا ليس لدينا هذه القائمة من الملصقات الجديدة (يرجى تصحيح لي):

• meta
• help-requested
• move-to-wiki
• complex-triage

حول الملصقات في الوقت المناسب ( backlog ، roadmap ، next-release ) أعتقد أنه من الأفضل اكتشاف هذا من خلال المعالم ، ألا تعتقد ذلك؟ يجب أيضًا تنسيق ذلك مع أي شخص يقدم رمزًا إلى الريبو.

سوف أقوم بتحديث هذا التعليق بمجرد ظهور الحاجة إلى تسميات جديدة. موافق مع ذلك؟ إذا كانت الإجابة بنعم ، فلا تتردد في سؤال الطبال عن ذلك.

تضمين التغريدة
هل يمكن أن يكون لدينا إعداد التسميات التالية؟

• meta
• help-requested
• move-to-wiki
• complex-triage
• security-issue

شكرا

baradhili حاولت تنظيم الملصقات في ملف MD قليلاً. لقد أضفتك كمتعاون حتى تتمكن من تحرير الملف.

هل أنت موافق على التعاريف بقدر ما كتبتها؟

الامور جيدة!توثيق!

في الثلاثاء 14 كانون الثاني (يناير) 2020 الساعة 19:36 ، كتب Christian [email protected] :

baradhili https://github.com/baradhili حاولت تنظيم الملصقات
في ملف MD
https://github.com/christianlupus/Test-PK-Pages/wiki/Issue-Labels a
قليل. لقد أضفتك كمتعاون حتى تتمكن من تحرير الملف.

هل أنت موافق على التعاريف بقدر ما كتبتها؟

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/partkeepr/PartKeepr/issues/1066؟email_source=notifications&email_token=AAFC2FCNL4V3QXSEUTKI6HTQ5WPTFA5CNFSM4KF76JRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW34
أو إلغاء الاشتراك
https://github.com/notifications/unsubscribe-auth/AAFC2FEBIIB6JH6OJENT7GLQ5WPTFANCNFSM4KF76JRA
.

-
بريت واتسون
مخرج
إدارة تكنولوجيا المعلومات المؤقتة Pty Ltd T / A TICM
الهاتف المحمول: +61 (0) 41 33 03840
البريد الإلكتروني: [email protected]
"محتويات إرسال البريد الإلكتروني هذا مخصصة فقط للاسم المحدد
المستلم (المستلمون) ، قد يكونون سريين ، وقد يكونون مميزين أو غير ذلك
محمي من الإفشاء للمصلحة العامة. الاستخدام والتكاثر
الكشف عن أو توزيع محتويات هذا البريد الإلكتروني المرسلة عن طريق
يحظر أي شخص آخر غير المستلم (المستلمين) المحدد. إذا لم تكن
يرجى إبلاغ المرسل على الفور باسم مستلم محدد ".

build system الواضح أن

سأضيف قائمتك baradhili وآمل أن
في الوقت الحالي ، أعتقد أنه لا بأس من وجود تصنيفات "أكثر من اللازم" بدلاً من وجود "عدد قليل جدًا". يمكننا دائمًا إزالة / تجاهل بعض التصنيفات.

أي ألوان معينة تريد ربطها بهم؟ :)

حسنًا ، بعد فوات الأوان ، ذهبت مع الألوان الافتراضية في الوقت الحالي: د

dromer هل يمكن أن نحصل على علامة فارقة لـ 1.5.0؟

christianlupus سأستخدم 1 - Ready للأشياء التي تظهر / يُزعم أنها تم إصلاحها ، ولكنها تحتاج إلى اختبار

dromer في وقت لاحق .. أدركت أنه يمكنني التعامل مع الأشياء التي تبدو وكأنها بحاجة إلى القيام بها "قريبًا" Must Have
أنهى christianlupus Bug .. يعمل الآن على حل المشكلات القديمة بدون أي إنجاز

أزلت تسميات مثل Will be closed soon! و Feedback Needed بمجرد إغلاق المشكلة. هل هذا جيد لسير العمل المشترك لدينا؟

dromer هل يمكنني الحصول على علامة إضافية .. low-hanging ؟ أرى مشكلات من وقت لآخر يجب أن تكون إصلاحات سهلة

christianlupus نعم .. ويجب أن أعود

يبدو أن github يوفر بعض "الخطافات" الآلية إذا كنت تستخدم العلامة good first issue بدلاً من ذلك:

تسمية المشاكل وسحب الطلبات للمساهمين الجدد

الآن ، سيساعد GitHub المساهمين المحتملين لأول مرة في اكتشاف المشكلات المصنفة بـ good first issue

فهل أسميها ذلك بدلاً من ذلك؟
ستظهر المشكلات المتعلقة بهذه العلامة في بعض النظرات العامة الأخرى التي من المفترض أن تشجع الأشخاص على المشاركة.

مثل على https://github.com/partkeepr/PartKeepr/contribute

يعمل لدي! :)

baradhili لقد

christianlupus نعم .. وجدت أنه يمكنني تحمل حوالي 20/25 مشكلة يوميًا .. بعد ذلك أصبح عقلي مقليًا ...
سوف أركض إليه هذا الصباح ..

dromer الخطوات التالية ربما يتعين علينا البدء في تحديد الأولويات .. والأهم من ذلك .. التعيين إلى devs .. هل لدينا أي مطورين؟

baradhili لقد قمت للتو بإرسال بريد إلكتروني إلى مجال ticm الخاص بك. هل يمكنك التحقق من حسابك من فضلك؟

هل لدينا أي مطورين؟
حسنًا ... إذا فعلنا ذلك ، فلن يكون لدينا هذا التراكم :)

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

حسنًا يا رفاق .. لدينا الآن قائمة مشكلات بها جميع المشكلات المخصصة لمرحلة رئيسية وتم إغلاق الكثير منها
أعتقد أن تركيزنا الآن هو تطوير شخص ما :) للأسف لدي مواد غير غذائية حول ExtJS و Symfony لذا لا يمكنني المساعدة ...

والخيارات

1. نحصل على راعٍ ونستخدم المستقلين على guru.com أو stackexchange
2. نحاول أن نجد بعض أنفسنا
3. ؟

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

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

Boldie مرحبًا سفين ، سابق إنذار .. لقد تغيرت الأمور كثيرًا في المشروع في الآونة الأخيرة ونحن حريصون جدًا على بناء ثقة المجتمع - _ خاصة المطورين _

راجع للشغل - أفترض أن وظيفة الطباعة الخاصة بك تقوم بالطباعة بالجملة؟ ما هو ضروري لجعلها تعمل مرة أخرى؟

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

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

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

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

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

لذلك أسألك: هل عملت على الكود وهل لديك خبرة في التبعيات ذات الصلة؟

راجع للشغل - أفترض أن وظيفة الطباعة الخاصة بك تقوم بالطباعة بالجملة؟ ما هو ضروري لجعلها تعمل مرة أخرى؟

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

راجع للشغل - أفترض أن وظيفة الطباعة الخاصة بك تقوم بالطباعة بالجملة؟ ما هو ضروري لجعلها تعمل مرة أخرى؟
تتكون من جزئين:

• الطباعة المجمعة لمواقع التخزين / الأجزاء إلى ملف pdf
• طباعة جزء واحد (للملصقات)

الأول كان متكاملًا بدرجة عالية ، ولكنه يضيف أيضًا بعض التبعيات الإشكالية. ربما تم تنفيذ الثانية بشكل أفضل مرة أخرى باستخدام REST API اليوم. لا يزال يتم تعقبه في واحدة من 200 مشكلة مفتوحة :)

لقد ألقيت نظرة على الكود: لدي بعض المشاكل حول كيفية عمل هذه الأشياء حقًا. يبدو أن إطار العمل يستخدم نوعًا من أدوات التوصيل الفضفاضة التي يصعب متابعتها. ربما يقول خبير يستخدم هذا الإطار شيئًا مختلفًا (معظم اليوم ، لدي اتصال بـ C ++ وأحيانًا python مع django). لقد تذكرت للتو أنه كان من الصعب أيضًا معرفة كيفية إضافة بعض الأشياء لأنني أجريت أول تطبيق لي. المشكلة كما أراها هي قيادة هذا المشروع من عرض فردي إلى حد ما إلى مشروع يحركه المجتمع. لسوء الحظ ، أنا الشخص الخطأ للمساعدة في مشكلة التبعية ، لكنني أوافق ، يجب أن يكون هذا هو أول شيء يجب حله من أجل تقليل القسم الفني.

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

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

@ بولدي فكرة جيدة! dromerDrachenkaetzchen هل يستطيع أحد الوصول إلى صفحة الويب الرئيسية؟

christianlupus هل هناك قائمة هنا أو في عرض المعالم التي يجب القيام بها بعد ذلك؟ أعتقد أن أحد الأشياء الأولى هو الترقية إلى Symhony4 # 1083؟

Boldie نعم ، كان هناك عمل تم إنجازه لقضايا الأولويات. انظر هذه القائمة:

https://github.com/partkeepr/PartKeepr/issues؟q=is٪3Aopen+is٪3Aissue+label٪3A٪22Must+Have٪22

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

هل هناك طريقة للتواصل مع المجتمع؟
نحن مع عدد من المستخدمين في قناة #partkeepr irc على irc.freenode.net
هناك أيضًا مجموعات Google (العامة والخاصة) ، لكنني أعتقد أن أداة تعقب المشكلات + IRC هي أفضل رهان لك للتحدث مع الأشخاص حول PartKeepr في الوقت الحالي (من حيث النشاط).

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

تم توثيق سبب اضطراري إلى إزالة الوظيفة هنا: https://github.com/partkeepr/PartKeepr/issues/622

إذا شعرت بأنك تعرضت للركل في الأسنان ، فأنا آسف ، ولكن هذا ما كان عليه الحال في ذلك الوقت.

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

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

إذا لم يكن هذا هو شعوري بالمسؤولية ، لكنت أغلقت الموقع وكل شيء آخر منذ عامين.

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

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

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

إذا لم يكن هذا هو شعوري بالمسؤولية ، لكنت أغلقت الموقع وكل شيء آخر منذ عامين.

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

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

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

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

شكرا @ بولدي

christianlupusdromer أنا أفكر أننا يمكن إغلاق هذا واحد الآن أن الأمور تسير مرة أخرى ...!

نقطة أخرى يجب مناقشتها: نظرًا للتغييرات في 1091 ، سيتم إرفاق بعض العلامات في كل الإصدارات الجديدة. هل نريد أن يكون لدينا مؤشر على عدم إجراء أي مراجعة بشرية هنا؟

بصرف النظر عن هذا ، فأنا موافق على إغلاق هذه القضية الآن.

كيف يختلف ما فعلناه في المراجعة البشرية؟ :)

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

باختصار: هل نريد need-triage أو ما شابه ذلك للإشارة.

هل يمكننا إضافة التصنيف needs-triage تلقائيًا ضمن نظام قوالب جيثب؟

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

لقد فتحت للتو # 1097 بخصوص نظام القوالب المشكلة. إذا لم تكن التسمية needs-triage مطلوبة ، أقترح إزالة الالتزام الفردي.

يغلق هذا الآن