أحب أبدأ بشكرك أخ هادي الأحمد على مشروع MonthlyQuran وعلى فتح باب المساهمة فيه بطريقة واضحة ومشجّعة فعلًا للمطورين.
تجربتي مع المشروع كانت ممتعة ومُلهمة. أثناء تصفحي للـ Open Issues في GitHub، وجدت مهام واضحة لها أثر مباشر على تجربة المستخدم، فبدأت العمل على مساهمتين تقنيتين، ولله الحمد تم دمج الPR لكليهما.
المساهمة الأولى: دعم أحجام وحدات صفحات مرنة (Custom Page Unit Size)
ما قمتُ به فعليًا هو:
- إضافة خيار يسمح بتحديد حجم الوحدة بالصفحات (مثل 0.5، 1.5، 3.5) عند اختيار نوع الوحدة = صفحات.
- ربط حجم الوحدة بالخوارزمية عبر حساب رقم الصفحة الفعلي لكل خطوة باستخدام:
start_page + (itemNumber - 1) * unit_size
- تحديث القارئ ليدعم نطاقات صفحات متعددة وكسور الصفحات (مثل صفحة 1–4½) بدل افتراض صفحة واحدة فقط.
- توحيد العرض بحيث تظهر الوحدة للمستخدم كنطاق واضح، بينما يبقى النظام داخليًا يعمل بوحدات مجردة.
الهدف كان حل المشكلة بدون تعقيد الخوارزمية الأساسية، مع إعطاء مرونة كاملة في الواجهة وتجربة القراءة.
رابط ال PR : https://github.com/hadealahmad/MonthlyQuran/pull/14
المساهمة الثانية: تحسين تجربة خط التقدّم (المحطات 1–7):
ما تم تنفيذه عمليًا:
- جعل نقاط المحطات في خط التقدّم قابلة للنقر بدل كونها عنصرًا بصريًا فقط.
- عند النقر، يظهر صف مدمج يعرض:
- تاريخ المراجعة لتلك الخطوة
- زر “قراءة” للمهام غير المكتملة
- إنشاء مكوّن جديد وخفيف (createStepDetailRow) مخصص لهذا السياق بدل إعادة استخدام مكوّن المهمة الكامل.
- إضافة دعم كامل للوصول (Keyboard + aria attributes).
- التركيز هنا كان تحسين سرعة الوصول للمعلومة والفعل (Read) بدون إثقال واجهة خط التقدّم.
رابط ال PR : https://github.com/hadealahmad/MonthlyQuran/pull/15
أهم الدروس اللي خرجت فيها وأحب أشاركها مع أي مطوّر هنا على المجتمع لتحقيق استفادة عامة تدعم المشاريع التقنية عمومًا والقرآنية خصوصًا:
- البدء من الـ Issues يختصر فهم المشروع ويقودك لمساهمة ذات قيمة حقيقية.
- فصل الـ business logic عن الـ UI قرار تصميمي يسهّل التوسعة ويقلّل التعقيد مستقبلًا.
- اختيار حجم المكوّن مهم بقدر اختيار الخوارزمية نفسها.
التجربة أكدت لي أن المساهمة في المشاريع القرآنية المفتوحة ليست فقط أجرًا، بل أيضًا فرصة تقنية حقيقية للتعلّم والنمو. أنصح أي مطوّر مهتم أنه يخوض التجربة بدون تردد.
