Information: فترة مراجعة كود العلاقات العامة

تم إنشاؤها على ٢٠ فبراير ٢٠١٩  ·  12تعليقات  ·  مصدر: solid-archive/information

عندما أنشأنا العملية في البداية ، في رأيي ، كانت فترة المراجعة لمدة أسبوعين لتغييرات الحوكمة ، وهو الشاغل الرئيسي لهذا المستودع.

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

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

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

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

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

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

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

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

التعليق الأكثر فائدة

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

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

يجب عمومًا مراجعة ملفات PR من قبل شخص (أشخاص) على دراية بالشيء (الأشياء) التي يتم تغييرها - سواء أكان هذا رمزًا أم لا. يبدو من المعقول أن تقول شيئًا مثل "w OR ((x و / أو y) AND z) ستراجع جميع العلاقات العامة لهذا الريبو / الملف / أيا كان" - الإطار الزمني الذي قد تختلف فيه المراجعات باختلاف عبء عمل المراجع (المراجعين) في الوقت الحالي بالإضافة إلى هدف العلاقات العامة!

يجب ملاحظة التغييرات التي يُحتمل أن تكون محل نزاع - من أي نوع - على هذا النحو من قبل هؤلاء المراجعين ، الذين ينبغي الوثوق بهم ليطلبوا بعد ذلك مراجعة أوسع ، ومن المحتمل أن تشمل "المسؤولين الأعلى" من أي نوع.

ال 12 كومينتر

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

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

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

بأسرع ما يمكن؟ لذا من الأفضل أن تندمج فورًا بعد فتح طلب سحب أو إصدار؟ هل نحتاج إلى نافذة للحوار؟

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

لذلك ، لا أتفق تمامًا مع megoth ، أنه لا يمكننا ببساطة جعل العملية تنطبق على الكود ، حيث توجد تغييرات في التعليمات البرمجية مثيرة للجدل.

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

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

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

يجب عمومًا مراجعة ملفات PR من قبل شخص (أشخاص) على دراية بالشيء (الأشياء) التي يتم تغييرها - سواء أكان هذا رمزًا أم لا. يبدو من المعقول أن تقول شيئًا مثل "w OR ((x و / أو y) AND z) ستراجع جميع العلاقات العامة لهذا الريبو / الملف / أيا كان" - الإطار الزمني الذي قد تختلف فيه المراجعات باختلاف عبء عمل المراجع (المراجعين) في الوقت الحالي بالإضافة إلى هدف العلاقات العامة!

يجب ملاحظة التغييرات التي يُحتمل أن تكون محل نزاع - من أي نوع - على هذا النحو من قبل هؤلاء المراجعين ، الذين ينبغي الوثوق بهم ليطلبوا بعد ذلك مراجعة أوسع ، ومن المحتمل أن تشمل "المسؤولين الأعلى" من أي نوع.

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

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

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

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

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

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

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

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

أردت فقط تضمين الملاحظات من محادثة اجتماع دعم المجتمع. تم تقديم هذه النقاط من قبل أشخاص مختلفين داخل فريق Solid:

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

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

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

  • هل يمكننا التفريق بين المستودعات؟ إذا كان الأمر كذلك ، فكيف؟

  • هل الرمز مختلف عن القواعد؟ يؤثر خادم Node Solid على المجتمع كما يفعل الريبو المجتمعي والمواصفات الصلبة. فكيف نفرق؟ من الصعب تقييم ما سيكون له تأثير مجتمعي ، خاصةً عندما لا يتمكن المتخصصون في إجراء هذا التقييم من الوصول إلى المعلومات لأنها ليست بلغة يمكنهم تفسيرها.
  • الخادم الصلب هو جزء معياري من البرامج له تأثير هائل على المجتمع ، لذلك فإن قرارات الكود لها تأثير كبير.
  • طلبات السحب الفردية عبارة عن أجزاء صغيرة من التغييرات ، لا تحتوي على تلك الخاصية. إنهم موجودون هناك فقط لجعل التغييرات تدريجية لف عقولنا حولها. ليس مثل التغيير المجتمعي لأنهما ليسا متماثلين من حيث النوعية والكمية.
  • يجب أن يكون لدى اتفاقيات إعادة الشراء الخاصة بالمواصفات الثلاثة وإعادة الشراء للمجتمع عمليات أكثر صرامة على سبيل المثال مع فترة مراجعة دنيا محددة ومراجع مخصص. المواصفات لها تأثير معياري كبير. طريقة جيدة للتمييز بين اتفاقيات إعادة الشراء من خلال التأثير المعياري الذي يمكن أن يكون لها بشكل عام. الريبو المجتمعي والمواصفات الصلبة في تلك الفئة. لذلك سيكون من الجيد أن يكون لديك دمج شفاف.
  • يمكن أن يكون لديك مجموعة قاعدة مختلطة لخادم node-solid-server تقول إذا كان التغيير ينحرف عن المواصفات ، فإنه يحتاج إلى وقت مراجعة أطول. الحالات التي ننفذ فيها المواصفات في الكود والتي تخرج عن المواصفات مهمة أيضًا للحصول على عملية.

  • لم يتم توثيق سير العمل والخطوات.

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

    • نحن بحاجة إلى بناء أشياء مقبولة وبالتالي يجب أن تكون مفهومة من قبل الجميع.

TallTed هل لديك أي أفكار حول محضر الاجتماع في التعليق السابق؟

كطريقة للمضي قدمًا ، أقترح ما يلي:

تتطلب طلبات السحب والمشكلات المرتبطة بعمليات إعادة الشراء التالية أن تكون مفتوحة لمدة ثلاثة أيام على الأقل:
https://github.com/solid/solid-spec
https://github.com/solid/web-access-control-spec
https://github.com/solid/webid-oidc-spec
https://github.com/solid/community

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

أي اعتراضات؟

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

أحب هذا الحل أيضًا: smile_cat: دعنا نكتب المنطق في مكان ما أيضًا ، حتى يفهم الناس تفكيرنا وراءه

kjetilk نعم ، سأضيف ملاحظة إلى https://github.com/solid/community/pull/44

megoth ok سيشمل وصفًا موجزًا ​​في الملف التمهيدي لريبو المجتمع

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

Mitzi-Laszlo picture Mitzi-Laszlo  ·  26تعليقات

eduardoinnorway picture eduardoinnorway  ·  3تعليقات

RubenVerborgh picture RubenVerborgh  ·  23تعليقات

christopherreay picture christopherreay  ·  49تعليقات

Mitzi-Laszlo picture Mitzi-Laszlo  ·  6تعليقات