أرابيكا:الميدان/سياسات/2023/سبتمبر

إضافة صلاحيات إلى إداريي الواجهة

مشروع اقتراح بشأن إضافة صلاحيات إلى إداريي الواجهة
نوع المشروع: إضافة	حالة المشروع: مسحوب	تاريخ انتهاء النقاش: 2023-09-12
اسم المراقب: أحمد ناجي ^(ن)

بالإشارة إلى النقاش السابق في ميدان التقنية فأقترح إضافة هذه الفقرات في قسم الصلاحيات من سياسة «إدرايو الواجهة»:

editprotected:تعديل جميع الصفحات المحمية.
importupload: استيراد الصفحات من ملف مرفوع.
import:استيراد الصفحات من ويكيات أخرى.

وقد أوضحت كافة المبررات في النقاش المشار إليه آنفًا. حبيشان^(ن) 10:57، الثلاثاء 13 صفر 1445هـ (+3) 07:57، 29 أغسطس 2023 (ت ع م)

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

وبشكل عام: أنا ضد فكرة منح صلاحيات لأي مستخدم بشكل احتياطي تحت بند (تسهيل عمله أو قد يحتاج لها مستقبلاً) طالما ليس هناك حاجة ملحة وضرورية وعندما يحتاجها بالفعل نعطيها له، من غير المنطقي منح مفتاح المنزل لعامل الصيانة وهو لا يحتاج سوى العمل في غرفة واحدة فقط، المسألة ليس لها علاقة بالثقة بل بتنظيم الأمور وتنظيم المسئوليات، ولا أظن أنه من الضروري تضخيم الصلاحيات وتضخيم أعبائها بأكثر مما ينبغي المفروض التركيز على واجبات صلاحية إداري الواجهة وإذا كان المستخدم يريد صلاحية إضافية نعطيها له بشكل فردي وليس جماعي، وشكراً. --إبراهيـمـ ✪ (نقاش) 12:23، 29 أغسطس 2023 (ت ع م)

لكي تتضح الحاجة إلى الصلاحية فإنه لا بد من مقدمات:

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

Interaction of Wikipedia user groups and page protection levels
	Unregistered or newly registered	Confirmed or autoconfirmed	Extended confirmed	Template editor	Admin	Interface admin	Appropriate for (See also: Wikipedia:Protection policy)
No protection	normal editing						The vast majority of pages. This is the default protection level.
Pending changes	all users can edit Edits by unregistered or new editors (and any subsequent edits by anyone) are hidden from readers who are not logged in, until reviewed by a pending changes reviewer or admin. Logged-in editors see all edits, whether accepted or not.						Infrequently edited pages with high levels of vandalism, BLP violations, edit-warring, or other disruption from unregistered and new users.
Semi	cannot edit	normal editing					Pages that have been persistently vandalized by anonymous and registered users. Some highly visible templates and modules.
Extended confirmed	cannot edit		normal editing*				Specific topic areas authorized by ArbCom, pages where semi-protection has failed, or high-risk templates where template protection would be too restrictive.
Template	cannot edit			normal editing			High-risk or very-frequently used templates and modules. Some high-risk pages outside of template space.
Full	cannot edit				normal editing		Pages with persistent disruption from extended confirmed accounts. Critical templates and modules.
Interface	cannot edit					normal editing	Scripts, stylesheets, and similar objects central to operation of the site or that are in other editors' user spaces.

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

الواجهة منظومة مترابطة من:

العناصر التي تحمل خصائص وتصنيفات معينة (تعين في الصفحات والقوالب والوحدات).
وقواعد CSS (الافتراضية في البرنامج - المضمنة في ميدياويكي:common.css - المضمنة في صفحات CSS الأخرى المحملة من عبر templatestyles - الخاصة بالمستخدمين).
وكذلك برمجيات الجافاسكربت (الافتراضية في النظام - العامة في نطاق mediawiki - الخاصة في صفحات المستخدمين).

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

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

إذا كان الأمر كذلك فكيف تعاملت الويكيات الأخرى مع هذا الإشكال:

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

هذا بعد تتبع أهم الويكيات. وبعض الويكيات منحت صلاحية تعديل الصفحات المحمية لمن هم دون إداريي الواجهة مثل: التشيكية (المهندس)، الروسية (المهندس)، الفارسية (محرر القوالب)، الهندية (محرر القوالب)، النيبالية (محرر القوالب)، التركية (محرر الواجهة)، الأردية (المحرر).

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

فخلاصة الأمر أن هناك حاجة ومنافع من إضافة هذه الصلاحيات إلى إداريي الواجهة، وليس منها ضرر محتمل لذات الصلاحيات.--حبيشان^(ن) 10:57، الأربعاء 14 صفر 1445هـ (+3) 07:57، 30 أغسطس 2023 (ت ع م)

أتفق مع الزميل Ibrahim.ID، إن احتاج إي ادري واجهة أو حتي محرر لدية خبرة في تعامل مع صلاحيات مستورد يمكنه طلبه من الإداريين، بخصوص صلاحيات تعديل جميع الصفحات المحمية أعتقد يجب إعطاء إدري الوجهه صلاحيات تسمع له بتعديل صفحات ذات الحماية الكاملة (js وcss والوحدات والقوالب فقط). مع خالص التحية-- جرجس✵(راسِـلني) 11:09، 5 سبتمبر 2023 (ت ع م)

@ Gerges بالنسبة لتعديل الصفحات المحمية اقترح لنا معرف صلاحية في برنامج الميدياويكي يمكن أن تفي باقتراحك، حتى نعدل في المقترح. حبيشان^(ن) 21:25، الثلاثاء 20 صفر 1445هـ (+3) 18:25، 5 سبتمبر 2023 (ت ع م)

الحقيقة لا أعرف مغزى كل هذا التعليق الطويل من الزميل حبيشان والذي لم يجيب عن تساؤلاتي بشكل مباشر بل يسرد الكثير من الجوانب النظرية دون التطرق لصلب الموضوع، نحن نريد كلام على أرض الواقع، الكلام هنا على: الصفحة الرئيسية + عدة قوالب ووحداث محمية بشكل كامل ضمنياً للصفحة الرئيسية فقط، وهذه تمثل 1% من إجمالي الصفحات المتاحة لإداري الواجهة أي أننا لا نعيق جزء كبير من عمله ونرجوا ألا يتم تضخيم الأمور بشكل يشعرنا وكأننا نعيق عمل إداري الواجهة كلياً! وكما شرحت سلفاً هذه الصفحات لم يتم تعديلها على مدار سنوات طويلة ونادرة التعديلات (وكل شيء واضح في سجلات التاريخ يمكنكم التأكد)، افتراض الزميل حبيشان أن الميدياويكي يتغير كل يوم هو مجرد افتراض ربما لا يحدث، وأنا أقول هذا من منطلق خبرتي مع أعمال الواجهة منذ 10 سنوات ولم نشهد وجود العديد من التعديلات، أيضاً الزميل أغفل دور System admins و Global interface editors التابعين للميتا وهؤلاء يتدخلون بشكل عاجل في حاجة وجود مشاكل أو أخطاء عند التحديث، وطبعاً لو فرضنا جدلاً غياب جميع (إداريو الواجهة + إداري) أيضاً وهذا لا يحدث كثيراً سنجد في النهاية احتمالية تعديل هذه الصفحات يكاد يكون صفر في المئة، إذن ما جدوى الطلب؟ منح صلاحية بناءاً على أفتراض مستقبلي قد يحدث أو لا؟

حتى لو فرضنا جدلاً حدوث ذلك من السهل على أي بيروقراط منح صلاحية إداري مؤقتة، يجب أولاً أن يكون هناك حاجة لكي نطلب عليها الصلاحية وليس العكس، هل أنت كإداري واجهة واجهت صعوبة في تعديل صفحة معينة محمية بشكل كامل؟ أم أنك فقط تريد صلاحية التعديل على سبيل الاحتياط، الموضوع ليس له علاقة بالثقة كما أسلفت بل الفكرة هو ضرورة فصل الصلاحيات ولا يجوز منح الصلاحية هكذا تحت مبرر تسهيل عمل فلان فهذا ينطبق على كل المستخدمين، من قال أنه لن يكون هناك أضرار؟ اليوم نحن نثق بحبيشان ولكن هل كل من سيترشح كإداري واجهة سيكون مثله في المستقبل؟ نحن نختار المرشح لأنه شخص بارز في CSS /JS فقط لا داعي لتضخيم مسئوليات الصلاحية فوق طاقتها، ونقطة أخيرة: المقارنة مع الموسوعات الأخرى ليست حجة سليمة لأن كل موسوعة لها استقلاليتها وظروفها الخاصة وهم أيضاً لا يلتزمون بما نفعله، وكما قلت بنفسك ليس كل الموسوعات تنتهج نهج واحد لذلك لا داعي لتكرار استخدام هذه الحجة وأتمنى التركيز فقط على نقطة جدوي وأهمية (تعديل الصفحات المضمنة للصفحة الرئيسية)، وشكراً. --إبراهيـمـ ✪ (نقاش) 15:35، 5 سبتمبر 2023 (ت ع م)

@ Ibrahim.ID :

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

أولا هذه النسبة غير صحيحة، عدد الصفحات التي حميت لتضمنيها في الصفحة الرئيسية وقت كتابة هذه السطر 102 صفحة (وهذ الرقم غير ثابت يتغير أحيانا خلال اليوم) منها وحدات وقوالب مهمة مثل: wikidataIB ووحدات الاستشهاد ووحدات التاريخ الهجري ووحدات القرآن وأبيات الشعر وغيرها. بينما عدد ملفات الجافا سكربت المستعملة في mediawiki:Gadgets-definition هو 133 وملفات css عددها 43 فالمجموع: 176 وإذا أضفنا إليها ملفي common صارت 178 نسبة 102/178 تساوي 57% لا 1%.
ثانيًا: هذه الوحدات المذكورة ذات أهمية عالية جدًا لأنه يقل أن تخلو صفحة في نطاق المقالات منها، وأهميتها تعلو على أهمية 80% من الإضافات التي بعضها لا يستعملها سوى عشرات.

وكما شرحت سلفاً هذه الصفحات لم يتم تعديلها على مدار سنوات طويلة: مع أن هذا لا ينطبق على الوحدات التي ذكرتها آنفًا لأنها في تطوير دائم، فإن ما ذكرته أيضا منطبق بنسبة الضعف على أكثر الإضافات التي لم يحصل بعضها على تعديل من عشر سنوات! فهل يعني هذا أن نلغي صلاحية إداري الواجهة على الإضافات بنفس الدعوى.
ثم إن هذا الثبات ليس لخلوها من العيوب بل مليئة بها مثلا صفحة ميدياويكي:common.css فيها 84 قاعدة مع وسم "important" وهذا استعمال معيب راجع mw:Manual:Coding conventions/CSS#!importtant.
استغرب جدًا من قولك «فتراض الزميل حبيشان أن الميدياويكي يتغير كل يوم هو مجرد افتراض ربما لا يحدث»، مع أني قلت بالنص: «برنامج ميدياويكي الذي يدير موقع أرابيكا في تحديث دائم حيث يحدث أسبوعيًّا،» ولم أقل يوميًا ونشرات التحديث تصلنا في العادة في قسم أرابيكا:الميدان/تقنية/أخبار، ومن أراد التأكد من التحديث الأسبوعي فليفتح صفحة mw:MediaWiki_1.41/Roadmap.
الزميل أغفل دور System admins و Global interface editors التابعين للميتا: هل تتوقع منهم أن يحلوا مشاكل وحدة التقويم الهجري أو القرآن أو الأبيات وكلها مطورة محليًا أو وحدات الاستشهاد التي عدلت بكثافة من المجتمع العربي؟
هل أنت كإداري واجهة واجهت صعوبة في تعديل صفحة معينة محمية بشكل كامل؟: نعم نواجه هذا بشكل مستمر وبخاصة من تضمينات الصفحة الرئيسية.
المقترح موضوع في أرابيكا:الميدان/تقنية قبل أن أفكر بترشيح نفسي لإدارة الواجهة، فليس الباعث على المقترح هو طلب الصلاحية لنفسي.

حبيشان^(ن) 01:09، الأربعاء 21 صفر 1445هـ (+3) 22:09، 5 سبتمبر 2023 (ت ع م)

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

استخدام حدود أعلى في استعلامات API (apihighlimits)
تجاوز قائمتي العناوين أو أسماء المستخدمين السوداوين (tboverride)
تعديل الصفحات التي حمايتها "السماح للإداريين فقط" (editprotected)
تفعيل ميزة التحقق بخطوتين (oathauth-enable)
عدل طريقة محتوى صفحة (editcontentmodel)
غير متأثر بحدود المعدل (noratelimit)

وإن لم يمكن التعديل فأطلب سحب المقترح.--حبيشان^(ن) 23:18، الخميس 22 صفر 1445هـ (+3) 20:18، 7 سبتمبر 2023 (ت ع م)

مرحبًا أخي @حبيشان: لاستحداث صلاحية جديدة في الموسوعة لا بد من فتح نقاش في ميدان الاقتراحات، وإذا توافق المجتمع على الصلاحية وأُنشئت، نأتي إلى ميدان السياسات لوضع شروط الصلاحية. لذا أرى من الأفضل سحب المقترح، والسير في الخطوات التي ذكرتها، تحياتي لكم. أحمد ناجي ^راسلني 07:05، 8 سبتمبر 2023 (ت ع م)
@أحمد ناجي إذا اسحب المقترح. حبيشان^(ن) 10:48، الجمعة 23 صفر 1445هـ (+3) 07:48، 8 سبتمبر 2023 (ت ع م)
خلاصة: سُحب المقترح. تحياتي. أحمد ناجي ^راسلني 08:47، 8 سبتمبر 2023 (ت ع م)

هذا القسم منظور، ويمكن أرشفته.

إمكانية صرف التصويت لمقالة مرشحة كمقالة مختارة إلى مقالة جيدة

اقترح في التصويت على مقالة مختارة أن يكون فيه ثلاثة خيارات:

مع أنها مختارة
مع أنها جيدة
ضد

بحيث إذا فشلت المقالة في تحقيق نصاب تصويت المقالة مختارة، فإنه تجمع أصوات المصوتين على أنها مختارة مع المصوتين على أنها جيدة وتوسم بأنها جيدة إذا حققت نصاب المقالة الجيدة، لأنه بحسب النظام الحالي لابد أن تمر بمراحل الترشيح من جديد لوسمها كمقالة جيدة، أو أنها ترفض تمامًا من المحتوى المتميز، وهذا فيه إهدار للجهود والوقت. حبيشان^(ن) 00:20، الخميس 9 محرم 1445هـ (+3) 21:20، 26 يوليو 2023 (ت ع م)

@حبيشان: أتفق مع الاقتراح.

ولكن يجب إخطارُ المُصوِّتين ليُرى موقفهم من التَّصويت، حتَّى المُصوِّتين بضد؛ لأنَّه يُمكن أن يرى المُصوِّت بضد أنَّ المقالة تستحق أن تكون جيِّدة، وقد يرى أنَّها لا تستحق الوسم أصلًا. سيف القوضي ^راسلني 21:44، 5 أغسطس 2023 (ت ع م)

لم يخطر في بالي أن نستعمل هذا في التصويتات المفتوحة، كان اقتراحي للتصويتات الجديدة فقط، لكن اقتراحك جميل بأن يكون للتصويتات الجديدة والتصويتات المفتوحة مع إشعار المصوتين السابقين. حبيشان^(ن) 06:53، الأحد 19 محرم 1445هـ (+3) 03:53، 6 أغسطس 2023 (ت ع م)

تعليق: لا أعتقد بأن هُناك داعي لهذا التشتيت في التصويت، عندما تفشل المقالة للحصول على وسم مختارة، ببساطة يُمكن لصاحبها فتح ترشيح جديد مثلاً لوسمها كجيدة، وتمر عبر مراحل الترشيح مُجددًا، لا توجد مشكلة بذلك، وطالما خضعت لمراجعة الزملاء كمقالة مختارة وتجاوزها، أرى استثناءها من مراحل الترشيح مرة أخرى، ويُمكن إنشاء صفحة تصويت مباشرة. تحياتي.--فيصل ^{(راسلني)} 20:30، 8 أغسطس 2023 (ت ع م)
◀ فيصل فترة التصويت بحسب أرابيكا:معايير المقالات المختارة ثلاثة أشهر، وفترة المراجعة من 21 إلى 60 يوما، فأنت تؤيد تجاوز مرحلة المراجعة فقط والدخول في تصويت جديد (3 أشهر)؟! حبيشان^(ن) 10:00، الأربعاء 22 محرم 1445هـ (+3) 07:00، 9 أغسطس 2023 (ت ع م)
لا أتفق: عفوا حبيشان أعتقد أن مثل هذا القرار يجب أن يُتّخذ في مرحلة مراجعة الزملاء، شكرا. أبو هشام 21:14، 8 أغسطس 2023 (ت ع م)
الذي أفهمه من تعليقك الموافقة على المقترح إذا اتُخذ قرار به في مرحلة المراجعة، من الصعب التوصل إلى إلى توافق في مرحلة المراجعة على إضافة خيار المقالة الجيدة، إذ المرشح يرى أنها مستحقة لوسم مختارة بينما فقد يكون بعض المراجعين لا يرون ذلك، فما لم تكن هناك آلية واضحة لاتخاذ القرار، نجعل القرار بيد المصوتين. حبيشان^(ن) 10:05، الأربعاء 22 محرم 1445هـ (+3) 07:05، 9 أغسطس 2023 (ت ع م)
الفكرة الأساسية أن بعض المقالات تُرشح للمختارة وهي لا تبلغ إلا الجيدة، هذا واقع، و قد يحدث العكس أحياناً، يكون الترشيح لمقالة جيدة وهي تستحق أن تكون مختارة، ولا أدري كيف نتجنّبه؟ ربما بإضافة مهمة للمراجع في تفاصيل مراجعة الزملاء، يُذكر فيها صراحةً (هل درجة المقالة جيدة؟ أم مختارة؟) فينظر المُراجع في هذا السؤال وإذا تبين له إحدى الدرجتين فإنه يُمضيها وفقاً لدرجتها المستحقة لا وفقاً للترشيح.Abu aamir (نقاش) 16:33، 10 أغسطس 2023 (ت ع م)
تعليق: مرحبًا بالجميع. صراحةً أميل في هذه النقطة إلى معالجة استحقاقية المقالة لوسم الجيدة أم المختارة في مراجعة الزملاء قبل طرحها للتصويت، وهذا الأمر واقعي حيث إن تحديد استحقاقية المقالة لوسم المختارة أو الجيدة يتحقق بصورة أفضل عن طريق النقاش لا التصويت، وهذا الأمر قد حدث قبل ذلك مثلًا في مراجعة جاي فوكس التي شاركتُ أخي علاء في كتابتها، تحياتي للجميع. أحمد ناجي ^راسلني 22:40، 10 أغسطس 2023 (ت ع م)
تعليق: لا أميل لهذا الطرح، فأولاً يمكن بعد فش التصويت على كونها مختارة ترشيحها لتكون جيدة كما أسلف الزميل فيصل، وثانياً فخلال مراجعة الزملاء يجري نقاش على نوع الوسم ويستطيع المراجع من خلال الاتفاق بين الزملاء تغيير نوع الوسم. --عُمر (نقاش) 07:27، 12 أغسطس 2023 (ت ع م)
خلاصة: لا توافق حول المقترح.--فيصل ^{(راسلني)} 12:36، 12 سبتمبر 2023 (ت ع م)

هذا القسم منظور، ويمكن أرشفته.

اقتراح: سياسة منتظمة لتحديد موعد يوم أرابيكا وتحضيراته

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

يُقَام يوم أرابيكا العربية في السبت الأول من شهر يوليو كل عام (تاريخ إطلاق الموسوعة حسب مقالتها هو 9 يوليو، وبالتالي أقرب إلى بداية الشهر).

إضافةً إلى ذلك ولضمان مشاركة واسعة واستفادة أكبر من هذه الفعالية الرائعة، أقترح إضافة بنودٍ بسيطة للسياسة على شاكلة تشبه الآتي:

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

أُرحِّب بسماع أفكاركم وتعديلاتكم. يمكننا -للمناسبة- طلب منحة منتظمة من مؤسسة ويكيميديا للمساعدة في تنظيم أي نشاطات أو حملات إعلانية في حال وجود أفكار محدّدة للمجتمع، إذ يمكن لمجموعات المستخدمين مثل ويكيميديا بلاد الشام تقديم يد المساعدة في ذلك. يوم أرابيكا العربية مناسبةٌ عظيمةٌ والأجدر بنا أن نستغلَّها إلى أقصى قدرها وقدرتنا على الانتفاع منها --عباد (نقاش) 19:25، 16 يوليو 2023 (ت ع م).

@عباد ديرانية: شكراً على الطرح، فعلياً عقد اجتماع ودي غير رسمي دعت له الزميلة دنيا وحضره زملاء من مختلف الدول العربية، ومن جملة الأمور التي تحدثنا عنها يوم أرابيكا العربية. فعلياً طُرحت فكرة بدء التحضير لفعاليات هذا اليوم منذ بداية العام، واقترح أن نتعامل مع الموضوع كمشروع، ورشحنا الزملاء دنيا من مصر ولمى من العراق وحجاوي من فلسطين لإطلاق المشروع في يناير 2024، من بديهيات المشروع التواصل مع المجتمع باستخدام الاستبانات وقنوات التواصل للتوافق على ما يمكن عمله وكيف وتطلعاتهم وكل ما يتعلق بالفعالية، فكرة طلب منحة واردة جداً أيضاً. --Mervat (نقاش) 19:30، 16 يوليو 2023 (ت ع م)

مرحبًا ◀ Mervat شكرا لردك، أود فقط التعليق على الاجتماع الذي ذكرتيه والذي أعتقد أنه كان حصريًا (لم نرى منشورًا عنه في الميدان) وما أتفق عليه راجع لمن حضره (لا نعلم الطريقة التي اتبعت في دعوة حضوره وتنظيمه)، في حين كان من الأجدر أن يكون نابعًا من المجتمع العربي (هنا) وليس اجتماعا حصريًا فتصريحك بأنه من «مختلف الدول العربية» يُجانب الصواب فالدول العربية 22 دولة، غير أنني أجد أن اقتراح ◀ عباد ديرانية الأكثر وجاهة ويصب في اطار السياسات المتعارف عليها تحياتي عادل امبارك ^راسلني 15:21، 21 يوليو 2023 (ت ع م)

مرحبا @Nehaoua:، ذكرت في ردي أن الاجتماع كان ودياً ولم يعقد لنقاش موضوع يوم أرابيكا العربية، وإنما جاء الحديث عن الفعالية من جملة الأمور التي نوقشت بصفة غير رسمية، أما ذكر مختلف الدول العربية فالمقصود هو أن الفريق المأمول متنوع، وفي كل الأحوال لا يمكن تأسيس فريق إشرافي بـ22 فرداً. أما الطرح في الميدان، فأنت على صواب، الطرح وجب أن يكون في الميدان، لكن لم يحن وقت العمل الفعلي بعد، فنحن على بعد أشهر من تفعيل العمل في هكذا مشروع. إشارة للزميلة دنيا لمشاركة تعليقاتها هنا كونها صاحبة المبادرة للدعوة للقاء الودي (@دنيا: --Mervat (نقاش) 20:12، 21 يوليو 2023 (ت ع م)

مرحبًا @Nehaoua: وشكرًا لك @عباد ديرانية: على الطرح، كما أشارت الزميلة @Mervat: مشكورة بأنه عُقد اجتماع ودي، وددتُ هذا العام تنظيم ورشة صغيرة تحت إشراف مشروع محرر ويكيبيدي بمناسبة يوم أرابيكا العربية خاصة أنني نظمت لتلك المناسبة ورشات بالعامين السابقين ولم أحب أن تمر المناسبة هذا العام بلا نشاط لي أو لمشروع محرر ويكيبيدي، انضم عدد من المتطوعين لمجموعة واتس آب (منهم متطوعين جدد ومنهم قدامى، والزميل عادل يشرفنا به أيضًا)، اقترحت إحدى المتطوعين الجدد علي عقد اجتماع ودي بين محرري ويكيبيدي وقد استحسنتُ الفكرة صراحةً لأنني منذ فترة ونشاطي قليل لظروفي الخاصة واشتقت للنقاش مع الزملاء، شاركت رابط اللقاء على مجموعة الواتس آب وحاولت التواصل مع عدد من الزملاء (لكن نظرُا لضيق الوقت باعتبار يوم أرابيكا سيكون 15 لم أستطع التواصل مع الكثيرين، حتى أن بعض الزملاء أخبرتهم عن الاجتماع بنفس يومه عصرًا)، لم يكن مرتب الحديث بأمور معينة باللقاء، فقط أسئلة لتسيير الحوار ومشاركة الخبرات مثل: "كيف كانت بدايتك بأرابيكا؟"، لكن تحمس الزملاء واستغلوا تجمعنا باقتراح أنشطة مستقبلية يستفيد منها المجتمع العربي، خاصة أن الشكوى كانت عامة بتأخر التجهيز ليوم أرابيكا العربية هذا العام، من ضمن الأفكار الإيجابية التي طرحها الزملاء تثبيت موعد اجتماع ويكيبيدي شهري لجميع أعضاء المجتمع للنقاش والخروج بأفكار تفيد المجتمع (لكن لم يُبادر أحد بأخذ زمام الأمر حتى الآن حسب علمي)، والفكرة الأخرى كانت اقتراح فريق يبدأ الإعداد ليوم أرابيكا العربية العشرون وهم: الزميلة لُمى والزميل محمد حجاوي وأنا، وثلاثتنا تحمَّس للفكرة وسنبدأ التخطيط لها بإذن الله، وددنا الإعلان عن ذلك بعد نهاية يوم أرابيكا العربية التاسع عشر، ومن ثم عقد لقاءات مع المجتمع لمناقشة أفكاره المتنوعة، وسنستعين بأفكار الزميل عباد المطروحة أعلاه وأفكار الزملاء باللقاء ونعرضها على المجتمع لمناقشتها. عذرًا على الإطالة لكن رغبت بتوضيح الفكرة كاملة حتى لا يُساء فَهم أي شيء. -- دُنـيا ^{راسِلني} 18:18، 22 يوليو 2023 (ت ع م)

مرحباً دنيا

سأتولى مسألة عقد الاجتماع الشهري، وإن شاء الله يكون الاجتماع الأول بيوم أرابيكا العربية 29 يوليو 2023. Michel Bakni (نقاش) 23:33، 22 يوليو 2023 (ت ع م)

تعليق: الزملاء الكرام @عباد ديرانية، Mervat، Michel Bakni، دنيا، وNehaoua: طبعًا أنا متفق حول تحديد يوم ثابت، حتى يكون هذا اليوم معروف سنويًا، ويكسب صيت وسمعة، هذا أمر مهم. عمومًا، هذه فقط إشارة لكم حتى لا يؤرشف النقاش دون فائدة، أرى بأن يجب إنشاء مسودة سياسة جديدة، وإتباع آلية إقرار السياسات، مع وضع مراقب وغيرها. تحياتي لكم.--فيصل ^{(راسلني)} 20:28، 8 أغسطس 2023 (ت ع م)
مرحبا @Michel Bakni:، هل يمكن وضع خلاصة لهذا الموضوع؟ شكرا لك. Dr-Taher (نقاش) 05:34، 26 سبتمبر 2023 (ت ع م)

خلاصة: لا يوجد نقاط خلافية، أرجو من الزملاء المشاركين بالنقاش صياغة سياسة واعتمادها باستعمال آلية إقرار السياسات.--Michel Bakni (نقاش) 06:28، 26 سبتمبر 2023 (ت ع م)

هذا القسم منظور، ويمكن أرشفته.

أين يكون التنبيه على حذف الصفحات البرمجية (وحدات، js، json، css)

نصت أرابيكا:سياسة الحذف#تعليمات الحذف على أن قالب الحذف يوضع في رأس الصفحة المقصودة، وذلك لا إشكال فيه إذا كان محتوى الصفحة هو نص ويكي، مع أنه من الأفضل أن يوضع قالب الحذف في صفحات القوالب بين وسمي noinclude حتى لا يظهر في الصفحات التي ضمنت القالب، وكذلك التصنيف. بقي الصفحات التي لا تقبل نص ويكي وهي وحدات لوا في نطاق وحدة، وصفحات js في نطاق المستخدم، وcss وjson في نطاق (قالب، وحدة، مستخدم)، أين يوضع قالب الحذف، هناك خياران في نظري:

صفحة النقاش: وعيبها:
- التصنيف يظهر صفحة النقاش وليس الصفحة المقصودة.
- لا يظهر القالب لمن يفتح الصفحة.
الصفحة الفرعية /شرح، وليس فيها العيوب المتقدمة ولكن:
- لا يظهر التعديل بإدارج القالب للمراقبين للصفحة.

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

ولأن هذه المسألة متعلقة بسياسة الحذف فتحت نقاشها هنا، فنطب من الأخوة التوافق على شيء حتى ينفذ في الإضافات وينص عليه في السياسة. حبيشان^(ن) 22:51، الجمعة 24 محرم 1445هـ (+3) 19:51، 11 أغسطس 2023 (ت ع م)

@حبيشان: اقتراح جيد ولكن هذه القوالب مجرد شكليات من باب التنظيم والتنسيق لتنبيه الإداريين، من الممكن بدلاً من قالب الشطب التواصل مباشرة مع أحد الإداريين في صفحة نقاشه أو إخطار الإداريين وأنا من رأيي ان هذه أسرع طريقة لأن التنبيه يصلنا مباشرة كذلك الأمر لا يستغرق وقت لأن الإداري لن يحتاج لوقت للفحص كما نفعل مع المقالات، أيضاً هذه الصفحات التقنية غالباً من يتعامل معها محررين ذو ثقة والتعامل معها يكون أسرع. --إبراهيـمـ ✪ (نقاش) 17:53، 19 سبتمبر 2023 (ت ع م)

خلاصة: يكون التنبيه على حذف الصفحات البرمجية (وحدات، js، json، css) في صفحة إخطار الإداريين/أخرى مع ضرورة توضيح سبب طلب الحذف. شكرا لكم.--Dr-Taher (نقاش) 05:38، 26 سبتمبر 2023 (ت ع م)

هذا القسم منظور، ويمكن أرشفته.