الخلاصة

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

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

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

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

حساب غير مرتب قليلًا، وذاكرة أفضل

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

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

يكشف دليل الإدارة المرفق بالإصدار 2.16 عام 2002 عن مفاتيح هذه المشاركة. لكل منتج حصة للفرد، وحد أقصى لما يضعه الفرد على عطل واحد، وعتبة اختيارية تنقل البلاغ تلقائيًا من UNCONFIRMED، أي غير مؤكّد، إلى NEW، أي جديد. وضع حصة الفرد عند الصفر يعطّل التصويت؛ ووضع العتبة عند الصفر يعطّل الانتقال التلقائي. كانت رغبات الجمهور تمر عبر إعدادات يختارها المشرف.

صندوق الأصوات يحتاج إلى ورشة بجانبه

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

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