المحتوى عن 'إدارة المشاريع'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

  • التخطيط وسير العمل
  • التمويل
  • فريق العمل
  • دراسة حالات
  • نصائح وإرشادات
  • التعامل مع العملاء
  • التعهيد الخارجي
  • مقالات عامة
  • التجارة الإلكترونية

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
  • HTML5
  • CSS
    • Sass
    • إطار عمل Bootstrap
  • SQL
  • سي شارب #C
    • منصة Xamarin
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • سير العمل
    • Git
  • صناعة الألعاب
    • Unity3D
  • مقالات عامّة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • مقالات عامّة

التصنيفات

  • خواديم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • استسراع النمو
  • المبيعات

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 6 نتائج

  1. عندما تصون مستودعًا لمشروع مفتوح المصدر، فأنت تأخذ راية القائد، فلو كنتَ مؤسس أحد المشاريع التي أطلقتها للعموم ليستخدموها ويشاركوا فيها، أو كنت تعمل في فريقٍ وكنت تصون جانبًا من جوانب المشروع، فأنت تقدم خدمةً مهمةً إلى مجتمع التطوير. وعلى الرغم من أنَّ المساهمات في المشاريع مفتوحة المصدر تكون عادةً عبر طلبيات pull وهي أمرٌ بالغ الأهمية للحفاظ على جودة البرمجيات وفائدتها للمستخدمين النهائيين، لكن المساهمين في المشروع ليس لهم نفس تأثير من يقوم بصيانته ويبلور الشكل العام للمشروع؛ فالصائنون يشاركون في صلب تطوير المشاريع مفتوحة المصدر، إذ يديرون المشروع وينظموه يوميًا ويطوروه، ويتفاعلون مع المستخدمين ويوفرون المعلومات اللازمة للمساهمين. سنستعرض في هذا المقال بعض التلميحات عن صيانة المستودعات العامة للمشاريع مفتوحة المصدر. فالمسؤولون عن المشاريع مفتوحة المصدر عليهم مسؤوليات كبيرة تقنية وغير تقنية، والعمل كصائن للمشروع يعطي الفرصة للتعلم من الآخرين، وأخذ خبرة في إدارة المشاريع، ويسمح بمراقبة مراحل نمو المشروع وكيف أصبح المستخدمون العاديون مساهمين فعالين فيه. اكتب توثيقًا مفيدًا سيزيد التوثيق سهل الفهم (والذي سيؤدي إلى جعل البرنامج سهل الاستخدام) من قاعدة مستخدميك، ويساعد في تحويل المستخدمين إلى مساهمين في مشروعك. عندما تفكر بالشيفرات التي تكتبها أثناء تطويرك للمشروع، وتكتب بعض الملاحظات الجانبية لتساعدك في دمج مختلف أجزاء مشروعك مع بعضها بعضًا، فسيسهل عليك البدء بكتابة التوثيق أثناء عملية التطوير؛ أو ربما تقرر أن تكتب التوثيق قبل برمجة التطبيق، متبعًا بذلك منهجية «التطوير الموجه بالتوثيق» (documentation-driven development) التي تقول أنَّ عليك كتابة توثيق ميزات المشروع أولًا ثم برمجة تلك الميزات اعتمادًا على توثيقها. هنالك بضعة ملفات عليك وضعها في المجلد الرئيسي لمشروعك بجانب الشيفرات وهي: - ملف README.md الذي يوفر ملخصًا عن المشروع وأهدافه. - ملف CONTRIBUTING.md الذي يحتوي على تعليمات المساهمة في المشروع. - رخصة مشروعك، والتي ستشجِّع الناس على المساهمة في موقعك، أرجو أن تراجع مقالة كيف تختار رخصة مفتوحة المصدر لبرامجك. قد يأخذ التوثيق أشكالًا عدِّة، لذا عليك أن تضع نوعية المستخدمين المحتملين ومجال المشروع في الحسبان، فمن الممكن أن يأتي التوثيق بمختلف الأشكال ويكون موجهًا نحو فئات مختلفة من مستخدمي المشروع. قد تقرر استخدام شكل أو أكثر من الأشكال الآتية اعتمادًا على مجال عملك: دليل عام لتعريف المستخدمين بالمشروع الدروس التعليمية لعرض مختلف حالات الاستخدام الأسئلة الشائعة (FAQ) للإجابة عن أكثر التساؤلات شيوعًا بين المستخدمين مقالات عن استكشاف الأخطاء التي قد يواجهها المستخدمون وكيفية إصلاحها مرجع للواجهة البرمجية (API) للتطبيق تسمح للمستخدمين معرفة معلومات عن الواجهة البرمجية بسرعة ملاحظات الإصدار (release notes) التي تُذكَر فيها العلل المعروفة والتغييرات التي حدثت في كل إصدار الميزات المستقبلية لتتبع وشرح ما هي الميزات التي ستأتي في إصدارات مستقبلية. تسجيل مقطع فيديو لتعريف المستخدمين بمشروعك عبر الوسائط المتعددة. قد تلائم بعض أشكال التوثيق السابقة مشروعك أكثر من غيرها، لكن توفير أكثر من شكل للتوثيق سيساعد مستخدمي مشروعك أن يفهموا كيف يتفاعلون معك فهمًا أعمق. عليك عند كتابة التوثيق أو تسجيل مقطع فيديو أن تكون واضحًا قدر الإمكان، ومن الأفضل ألّا تكون عندك افتراضات مسبقة عن القدرات التقنية لمستخدمي مشروعك، ومن الأفضل أن تتبع منهجية Top-Down عند تأليف التوثيق، أي أن تشرح بداية الأمر ما الذي تفعله البرمجية بشكل عام (مثلًا: أتمتة أمور إدارة النظام، أو بناء موقع إلكتروني …إلخ.) قبل التعمق في التفاصيل. وصحيحٌ أنَّ اللغة الإنكليزية هي اللغة الرائدة في عالم التقنية، لكن أبقِ في ذهنك مَن هم المستخدمون المتوقعون وما هي لغتهم الأم؛ فاللغة الإنكليزية هي خيارٌ جيدٌ إذا كانت لديك قاعدة مستخدمين واسعة ومن مختلف البلدان، لكن ضع في بالك أنَّ عدد كبيرًا ممن سيقرؤون توثيقك لا تكون اللغة الإنكليزية هي لغتهم الأم، لذا حاول استخدام لغة سهلة لا تُسبِّب لبسًا عند القراء، وإذا كان مشروعك موجّه لمنطقة أو لغة معيّنة مثل برنامج للتعرف على الكلام العربي فأنصحك حينئذٍ أن توفر التوثيق باللغة العربية. حاول أن تكتب التوثيق كما لو كنتَ تكتب لأحد المساهمين الجدد الذين يريدون أن يطلعوا على حالة المشروع، فلا تنسَ أنَّك تريد أن يتحول المستخدمون العاديون إلى مساهمين. تنظيم «القضايا» القضايا (issues) هي طريقةٌ تستعمل لتتبع أو التبليغ عن العلل، أو لطلب ميزات جديدة لتضاف إلى البرنامج. توفِّر خدمات استضافة مستودعات المشاريع مفتوحة المصدر مثل GitHub و GitLab و Bitbucket طرائق لتتبع القضايا التي تُنشِئها وتسمح للمستخدمين بإنشائها. فمن المتوقع عند إطلاق مشروعك مفتوح المصدر أن تُفتَح عدِّة قضايا من قِبل مجتمع المستخدمين، لذا سيمثِّل تنظيم ووضع أولويات لهذه القضايا أمرًا مهمًا لتبيان خارطة الطريق لما عليك فعله للمشروع مستقبلًا. ولأنَّ أي مستخدم يستطيع أن يفتح قضية، فلن تكون جميع القضايا لتبليغ العلل أو لطلب الميزات، فقد تأتيك أسئلة عبرها، أو قد تأتي طلبات لتحسينات صغيرة على واجهة المستخدم مثلًا. فمن الأفضل تنظيم هذه القضايا في أفضل شكل ممكن ومحاولة التواصل مع المستخدمين الذين أنشؤوها. يجب أن تمثِّل القضايا مهامًا محددة عليك تنفيذها برمجيًا، لذا عليك تنظيمها حسب أهميتها. يجب أن يكون هنالك حدود للوقت والعمل الذي تنفقه أنت أو المساهمون في المشروع للقضايا المفتوحة فيه، ويمكنكم التعاون على اتخاذ القرارات والخروج بخطة قابلة للتنفيذ، وعندما تعلم أنَّك غير قادر على حل مشكلة معيّنة في الإطار الزمني المتاح لك، فيمكنك التعليق عليها وإخبار المستخدم أنَّك قرأت المشكلة وستفعل ما بوسعك تجاهها، وقد تستطيع أن تخبره بالوقت المتوقع للنظر في أمر هذه المشكلة مرةً أخرى. أما لطلبات الميزات أو التحسينات، فيمكنك أن تسأل الشخص الذي أنشأ القضية إن كان يستطيع المساهمة في الشيفرة لتطبيق هذه الميزة، يمكنك توجيه المستخدمين إلى ملف CONTRIBUTORS.md أو إلى أيّة صفحات أخرى من التوثيق. ولأن الأسئلة لا تمثِّل عادةً مهامًا محدَّدة، فالتعليق على السؤال لتوجيه المستخدم بلباقة إلى صفحة التوثيق هو خيارٌ ممتاز لإبقاء تفاعلك مع المستخدم احترافيًا ولطيفًا؛ وإذا لم يحتوي التوثيق على جوابٍ لهذا السؤال فحان الوقت لإضافة التوثيق الملائم، وتعبِّر عن شكرك للمستخدم لأنه دلّك على موضع النقص في التوثيق. إذا كنتَ تستقبل عددًا كبيرًا من الأسئلة عبر القضايا، فربما تفكر بإنشاء صفحة الأسئلة الشائعة (FAQ) في التوثيق، أو صفحات ويكي أو منتدى لتتيح للآخرين المساعدة والمشاركة في الإجابة عن الأسئلة. وفي كل مرة يبلِّغ فيها أحد المستخدمين عن مشكلة، فحاول أن تكون لطيفًا معه قدر الإمكان، فتفاعل المستخدمين معك يعني أنَّ المشروع قد أعجبهم ويريدون جعله أفضل. محاولة تنظيم القضايا ستجعل مشروعك محدثًا دومًا وسيشعر المستخدمون أنهم يأثرون فيه، لذا احذف القضايا التي تقع خارج نطاق مشروعك أو القضايا القديمة، وضع أولويات للبقية لكي يكون تقدمك في المشروع مستمرًا. حفِّز المساهمين كلما رحّبتَ بالمساهمين الجدد وكافأتهم على جهودهم لوجدت أنَّك تحفِّز مساهمين جدد ليشاركوا في مشروعك، ولكي تجذب المساهمين إلى المشروع فاحرص على تضمين ملف CONTRIBUTING.md في المجلد الرئيسي لمستودعك، وإشارة إلى ذاك الملف في README.md. إذا أردتَ كتابة ملف جيد للمساهمين الجدد فيجب أن يتضمن كيفية بدء العمل على المشروع كمطوِّر، فقد تكتب دليلًا يوضح ذلك خطوةً بخطوة، أو قائمةً من الأمور التي يجب على المطورين اتباعها وتنفيذها، شارحًا كيف يمكن أن يدمجوا الشيفرة التي كتبوها بشيفرة المشروع عبر طلبية pull. إضافةً إلى توثيق كيفية المساهمة في المشروع، فلا تنسَ أن تبقي شيفرات المشروع منظمة وسهلة القراءة، فإذا كانت الشيفرة سهلة الفهم وفيها تعليقات كثيرة تشرح ما تفعله وطريقة استخدامها موحدة ومتناسقة مع بعضها بعضًا فسيساهم ذلك في تحفيز المساهمين المحتملين على المشاركة في المشروع. أقترح أيضًا أن تبقي على قائمة بالمساهمين، فيمكنك أن تجذب المساهمين عبر إضافتهم إلى القائمة بغض النظر عن حجم مشاركتهم (حتى تصحيح الأخطاء اللغوية هو مشاركة ومساهمة فعالة في المشروع، ويمكن أن تؤدي إلى مزيدٍ من المساهمات مستقبلًا). وهذا يعني أنَّك تقدِّر عمل المساهمين في المشروع وتشير إليهم أمام جميع مستخدمي مشروعك، مما يحمِّس بقية المستخدمين على المشاركة. ابنِ مجتمعًا حول مشروعك بتمكين مستخدميك عبر التوثيق وبالتجاوب مع القضايا وبتحفيزهم للمشاركة، فأنت في طريقك لبناء مجتمع حول مشروعك المفتوح المصدر، فالمستخدمون السعيدون بتجاوبك معهم والذين تعدُّهم على أنهم مساهمون سيحاولون الترويج مشروعك ما استطاعوا. إضافةً إلى ما سبق، يمكنك الترويج لمشروعك بمختلف السبل: التدوين تسجيل ونشر فيديوهات تعريفية إنشاء قائمة بريدية النشاط على مواقع التواصل الاجتماعي التعاون مع المشاريع الشبيهة أو المتعلقة بمشروعك والترويج لها. عليك أن تُناسِب ترويجك للمشروع مع مجاله وعدد أعضاء الفريق الفعالين والمساهمين الذين يعملون معك. فعندما ينمو المجتمع حول مشروعك، فيمكنك أن توفِّر مساحة أكبر للمساهمين والمستخدمين والقائمين على المشروع ليتفاعلوا، بعض تلك الخيارات تتضمن: برمجيات الويكي التي توفِّر توثيقًا مصانًا من المجتمع المنتديات لمناقشة الميزات المحتملة وللإجابة على الأسئلة قائمة بريدية للتفاعل مع المجتمع عبر البريد الإلكتروني ضع ببالك قاعدة مستخدمي مشروعك ومجاله بما في ذلك عدد الأشخاص القائمين عليه والموارد المتاحة لك قبل أن تتوسّع في المجالات السابقة، واستشر مجتمعك عن الخيار الأفضل قبل الإقدام عليه. وأهم من ذلك كله أن تكون لطيفًا معهم وتريهم أنَّك تهتم بهم عبر تفاعلك معهم، أعلمُ أنَّ الاتسام بصفة اللباقة طوال الوقت ليس أمرًا سهلًا، لكن ستؤتي أُكلها على المدى البعيد. الخلاصة يلعب صائن المستودع دورًا مهمًا في مجتمع البرمجيات مفتوحة المصدر الكبير. وصحيحٌ أنَّ هذا الدور يأخذ وقتًا وعملًا كبيرًا، لكن الخبرة التي تكتسبها خلال هذا العمل ستفيدك كمطوِّر وكمساهم، ولا تنسَ أنَّ الصائن اللطيف واللبق سيساعد في دفع عجلة تطوير المشروع الذي يهتم لأجله. ترجمة –وبتصرّف– للمقال Maintaining Open-Source Software Projects لصاحبته Lisa Tagliaferri. حقوق الصورة البارزة محفوظة لـ Freepik
  2. بدأنا في الدرس السابق الحديث عن برنامج إدارة المشاريع Trello، انطلاقًا من إنشاء حساب جديد مرورًا بالخطوات الأولى في إضافة وإدارة كلًا من الألواح، القوائم، والبطاقات. كما عرضنا نموذجًا بسيطًا لإدارة العمل بين فريق صغير مكوّن من مترجمين، مدققين، وناشرين في موقع إلكتروني. نتناول في هذا الدرس خصائص البطاقات في البرنامج وكيفية التعامل معها. يُمثَّل المشروع في Trello بشكل رئيسي من خلال البطاقات والتي تُعتبر "وحدة العمل" الأساسية. تُفصل البطاقات من نفس النوع إلى "قوائم" داخل اللوح الخاص بمشروعك. فإذا كنتَ تدير موقعًا لنشر الدروس، فإنّ البطاقة ستمثّل أشياءً مثل: فكرة للكتابة، مادة للترجمة، مناسبة قادمة إلخ.. بينما ستكون القوائم التي تتضمنها: أفكار للكتابة، مواد للترجمة، مناسبات قادمة لتغطيتها. الهيكل العام للبطاقة لنلقي نظرة على مكونات البطاقة ضمن Trello: في الأعلى يوجد لدينا أولًا "عنوان البطاقة" أو اسمها؛ والذي ينبغي أن يكون واضحًا ومعبرًا بحيث يسهل معرفة ما تتضمنه البطاقة بمجرد قراءة عنوانها. أسفل العنوان نجد رابطًا باسم "Edit the description" وهو يتيح إمكانية إدراج وصف للبطاقة يشرح وظيفتها، أو محتواها، وأيّة تفاصيل أخرى من المهم أن تكون حاضرة دومًا عند التعامل معها. تعرض البطاقة بعد ذلك الملفات المُرفقة بها "Attachments" مرتبة تنازليًا (من الأحدث إلى الأقدم). يُتيح Trello إمكانية استعراض محتويات بعض أنواع المرفقات مباشرة ضمن المتصفح دون الحاجة إلى تحميلها (كالصور، الملفات النصيّة، وملفات مايكروسوفت أوفيس). وأخيرًا هناك صندوق إضافة التعليقات "Add Comment" والذي يتيح لأعضاء الفريق التفاعل مع البطاقة وإمكانية إدراج مرفقات جديدة، تضمين بطاقات أخرى، أو حتى إضافة إشارة Mention لشخص برسم رمز @ متبوعًا باسمه. بعد إضافة تعليق جديد على البطاقة يظهر أسفله رابط يشير للتاريخ والوقت الذي أُضيف فيه التعليق: يمكن نسخ هذا الرابط لمشاركة التعليق بشكل مُباشر. تُرتّب جميع التعليقات والتفاعلات على البطاقة تنازليًا (حسب التاريخ) في القسم الأخير منها تحت اسم "Activity". خيارات الإضافة في القسم الأيمن من البطاقة لدينا مجموعتان من الأوامر، أولها خيارات الإضافة Add وهي على خمسة أنواع: الأعضاء Members أولًا إضافة أعضاء Members إلى البطاقة بهدف الإشارة إلى صلتهم بها أو وظيفتهم ضمنها. عند إضافة عضو جديد إلى البطاقة فإنه يشترك بها تلقائيًا، وهذا يعني تلقيه إشعارات عند: إضافة تعليق، إضافة أو تعديل تاريخ الاستحقاق الخاص بالبطاقة، نقلها أو أرشفتها. يُضاف شخص جديد من خلال النقر على زر Members وكتابة الأحرف الأولى من اسمه، ثم الضغط على صورة معرّفه. هناك طريقة أخرى تتمثل بفتح القائمة الرئيسية للوح (بالنقر على زر Show Menu في الجانب الأيمن من المنصة وإلى الأعلى) حيث ستظهر الصور الشخصية لأعضاء الفريق، ومن هنا يمكن سحب وإفلات صورة عضو ما إلى إحدى البطاقات لإضافته إليها مباشرةً. كذلك يمكن أثناء مرور مؤشر الفأرة فوق البطاقة، الضغط من لوحة المفاتيح على الزر a لإظهار قائمة إضافة أعضاء إلى البطاقة. الملصقات Labels ثانيًا إضافة ملصقات labels، والتي تُستخدم لتصنيف البطاقات لونيًا بدلالة يحددها المستخدم، ما يُسهّل عملية فرزها والتعامل معها بصريًا. يتيح تريلو عشرة ألوان للاختيار وإمكانية تحديد دلالة لكلٍ منها. يُمكن للبطاقة الواحدة أن تحمل عدّة ملصقات معًا. كما يُمكن استخدام اختصار لوحة المفاتيح "l" (الحرف الصغير من L) أثناء مرور مؤشر الفأرة فوق البطاقة لإظهار قائمة إضافة الملصقات. لحذف مُلصق ما يكفي النقر عليه مُجددًا. قوائم الفحص Checklist ثالثًا إضافة قائمة فحص checklist، وهي طريقة فعّالة لتجزئة وتفصيل المهام الثانوية المطلوب إنجازها لتحقيق المهمة الأساسية التي تُمثلها البطاقة. بعد الضغط على زر checklist سيظهر مربع عائم لتسمية القائمة الجديدة، أدخل اسمًا أو أبقِ الاسم الافتراضي واضغط Enter، ستلاحظ ظهور قسم جديد ضمن مكونات البطاقة بذات الاسم مع مربع يُتيح إضافة العناصر إلى قائمة checklist. عند إنجاز أحد العناصر اضغط بزر الفأرة الأيمن على المربع المجاور له كي يتم احتسابه، وسيُعبّر عن ذلك بتقدّم مؤشر أزرق يُمثّل النسبة المئوية المُنجزة من إجمالي الهدف. إذا كنت ترغب باستيراد قائمة مكتوبة سابقًا من ملف نصيّ أو من جدول بيانات spreadsheet فيمكنك فعل ذلك ببساطة، عن طريق نسخ القائمة ثم لصقها في مربع إدخال العنصر والضغط على الزر Enter، سيعمل Trello على فصل كل سطر كعنصر مستقل بشكل تلقائي. من خلال السحب والإفلات يمكن إعادة ترتيب القائمة في أي وقت. كما يمكن بالنقر على أحد العناصر ثم الضغط على الرابط Convert to Card تحويله إلى بطاقة منفصلة ضمن نفس القائمة. تاريخ الاستحقاق Due date رابعًا إضافة تاريخ الاستحقاق due date وهو اليوم والوقت الذي تُصبح فيه المهمة مُستحقة للتسليم. إذا كان التاريخ المُحدد أبعد من 24 ساعة فإنه يظهر على البطاقة بلون رمادي فاتح، وإذا كان خلال الـ 24 ساعة القادمة فإنه يظهر بلون أصفر، بينما يظهر بلون أحمر عندما يحين موعد الاستحقاق ويظل التنبيه لمدّة 24 ساعة. كما يمكن تعيين تاريخ الاستحقاق عن طريق الضغط على زر لوحة المفاتيح "d" أثناء مرور مؤشر الفأرة فوق البطاقة المطلوبة. المرفقات Attachments خامسًا إضافة مرفقات Attachments إلى البطاقة، والذي يستقبل الملفات من ثلاثة مصادر رئيسية: جهازك الحاسوب ( لا يمكن رفع الملفات من الهاتف في حال كنتَ تتصفح موقع Trello من خلاله). حساباتك في مواقع التخزين السحابي (مثل Dropbox، Google Drive، Box وغيرها). إضافة رابط لملف على الشبكة. مع ملاحظة أن رفع ملف من جهازك يعني إنشاء نسخة ثانية عنه ضمن Trello، بينما إرفاق ملف من خدمة سحابية يقتصر على مشاركة رابط الملف الأصلي. يدعم كلًا من متصفحي Chrome وَ Safari إمكانية سحب وإفلات المرفقات من مدير الملفات إلى البطاقة لتُرفع مباشرةً إليها. الحسابات المجانية في Trello محدودة بحجم 10 ميغابايت للملف الواحد، بينما يُسمح بـ 250 ميغابايت للحسابات المدفوعة. لكن لا يوجد قيود على عدد الملفات التي يُمكن رفعها. خيارات الإجراء أسفل خيارات الإضافة السابقة يوجد لدينا خيارات الإجراء Actions وهي على أربعة أنواع: أولًا نقل البطاقة Move إلى لوح آخر أو إلى قائمة أخرى ضمن نفس اللوح، أو حتى تعديل موضعها ضمن نفس القائمة. للقيام بذلك ما عليك سوى تحديد الخيارات المطلوبة من القوائم المنسدلة التي يتيحها هذا الخيار ثم الضغط على الزر الأخضر Move. ثانيًا نسخ البطاقة Copy وهو يشبه الخيار السابق إلا أنه يُنشئ نسخة أخرى من البطاقة في الموضع الجديد محافظًا على وجودها ضمن موقعها الأصلي. ثالثًا الاشتراك بالبطاقة Subscribe لتلقي الإشعارات كما سبق شرحه. رابعًا أرشفة البطاقة Archive وذلك عندما يُنتهى منها. لا يجب حذف البطاقات في Trello (إلا في حالات نادرة) لإتاحة إمكانية العودة لأية تفاصيل لازمة عند حدوث مشاكل أو ما شابه. يمكن استخدام خاصيّة البحث في Trello للعثور على البطاقات المؤرشفة (أو غير المؤرشفة، حيث يتم البحث في جميع الألواح الخاصة بك). كما يمكن من القائمة الرئيسية للوح Show Menu الضغط على More ثم Archived Items لمشاهدة البطاقات المؤرشفة مع إمكانية إعادتها إلى اللوح عبر زر Send to Board.
  3. يُعتبر Trello أحد تطبيقات الوِب الشهيرة لإدارة المشاريع، بدأتها شركة Fog Creek Software عام 2011 (وهي ذاتها الشركة التي أطلقت Stack Overflow) قبل أن يتحوّل الموقع إلى شركة مستقلّة عام 2014، يتضمن التطبيق حزمتين للاشتراك، الأولى مجانية وتتضمن المميزات الأساسية لاستخدام الموقع، والثانية مدفوعة لفرق العمل. يستخدم Trello نموذجًا يُدعى kanban لإدارة المشاريع، والذي أشاعت شركة تويتا استخدامه في الثمانينيات. تُمثَّل المشاريع وفق هذا النموذج على شكل ألواح boards والتي تتضمن قوائم lists (مُشابهة لقوائم المهام task lists)، تتضمن القوائم بدورها بطاقات cards (تُمثّل المهام). ويُفترض بهذه البطاقات أن تنتقل من قائمة إلى أخرى (عبر السحب والإفلات) مُعبّرة عن سير العمل قُدمًا إلى الأمام. يُمكن استخدام Trello بأشكال كثيرة ومتنوعة، بما في ذلك إدارة المشاريع البرمجية، التخطيط للتدوين، العمل على كتاب، إدارة مكاتب المحاماة، العمل على مجلات الحائط المدرسية إلخ، كما يتكامل مع عدد من الخدمات الشائعة مثل البريد الإلكتروني، IFTTT، Slack وغيرها من وسائل التواصل والتنظيم، مما يجعل Trello مكانًا ملائمًا لربط كل شيء مع بعضه ومتابعة سير العمل. نبدأ في درس اليوم الخطوات الأولى مع البرنامج من قبيل إنشاء حساب، تصميم اللوح الأول والتعرف على المزايا الرئيسية وسنتطرق في دروس لاحقة إلى تفاصيل ومواضيع متقدّمة في العمل على Trello. إنشاء حساب يمكن إنشاء حساب في Trello بسهولة عبر التوجّه إلى الصفحة الرئيسية للموقع ثم الضغط على SingUP، الخانات المطلوبة ثلاثة فقط: اسمك، البريد الإلكتروني، وكلمة المرور: بعد ذلك ستنتقل إلى الصفحة الرئيسية في Trello والتي تعرض الألواح boards الخاصّة بمشاريعك، مبدئيًا لن تتضمن هذه الصفحة سوى لوح واحد ترحيبي يُدعى Welcome Board والذي يشمل الكثير من الأمثلة والخصائص التي يمكن تنفيذها باستخدام Trello. إنشاء لوح جديد New Board لنُنشئ لوحًا جديد باسم "أكاديمية حسوب" عبر الضغط على المربع الرمادي Create new board، ثمة خياران مُتاحان عند الإنشاء، الأول هو اسم اللوح، والثاني هو مجموعة العمل التي سنشارك اللوح معها، ولأننا لم ننشئ مجموعات عمل فسنترك هذا الخيار none ونضغط على Create: إنشاء القوائم بعد إنشاء اللوح ينقلنا Trello إلى داخله، وتظهر قائمة جانبية باسم Menu لنغلقها الآن ونُركّز على الزاوية اليُسرى حيث ينتظرنا إنشاء القائمة الأولى، سوف أكتب "مواد للترجمة" وأضغط على Enter، سأنشئ قائمتين إضافيتين "مواد للتدقيق" و "مواد جاهزة للنشر"، الآن يفترض أن يبدو اللوح على الشكل التالي: تُمثّل هذه القوائم سير عملي في أكاديمية حسوب. لنبدأ مع قائمة "مواد للترجمة"؛ تحتوي هذه القائمة على المقالات التي أنوي ترجمتها، هذا يشابه قائمة To Do والتي تتضمن الأعمال التي يتوجّب عليّ تنفيذها. إضافة مهام إلى القوائم لنبدأ بإضافة بطاقة/مهمة إلى القائمة عن الطريق النقر على زر Add a card، سيظهر مربع نصيّ صغير قابل للكتابة، سأضع هنا عنوان إحدى المقالات التي يتوجب عليّ ترجمتها، ثم أضغط على Enter لأرى المهمة قد أضيفت إلى القائمة. بعد ذلك سأضغط عليها بزر الفأرة الأيمن لتُفتح نافذة تفاصيل البطاقة والتي سنتطرق لاحقًا لإدارتها بالتفصيل. ما يهمني الآن في البطاقة هو إرفاقها مع رابط المقال كي يسهل عليّ الوصول للأصل الإنكليزي عندما أبدأ بالعمل، لذا أنسخ الرابط وأضعه في خانة Add Comment ثم أضغط Enter. سيُضاف في الأعلى مربع جديد باسم Attachments والعنصر الأول (والوحيد حاليًا) في المرفقات هو رابط المادة الأصل. انتهيت الآن من إضافة المهمة الأولى، أغلق البطاقة بالضغط على Esc من لوحة المفاتيح أو الضغط على رمز الإغلاق أعلى يمين نافذة إدارة البطاقة. سأتابع بالطريقة عينها مع باقي المقالات التي يجب عليّ ترجمتها، ليصبح اللوح مشابهًا لما يلي: بهذا الأسلوب تكون لديّ صورة دقيقة عن كمية المواد التي عليّ تنفيذها، وسيكون سهلًا متابعة سير عمل العديد من الأعضاء في فريق واحد. في البداية ستكون المقالات ضمن قائمة "مواد للترجمة" مع رابط الأصل لكل منها، لنفترض أنني أنهيت ترجمة المقال الأول، أعود الآن إلى Trello وأضغط على البطاقة الخاصّة به، ومن مربع Add Comment أختار رمز المشبك (الأول من اليسار) لإرفاق النصّ المترجم مع البطاقة، كما في الصورة التالية: الخطوة التالية هي سحب البطاقة من قائمة "مواد للترجمة" وإفلاتها ضمن قائمة "مواد للتدقيق"، سأضغط عليها مُجددًا ومن صندوق إضافة تعليق أختار رمز الإشارة (الثاني من اليسار) لإضافة إشارة mention إلى المُدقّق، كي يصله إشعار بوجود مادة جديدة تحتاج إلى تدقيق، كما هو موضح في الصورة: المُدقق بدوره سيحصل على نسخة من الترجمة مع رابط الأصل، وبعد التنقيح سيرفع نسخة جديدة من الملف، وسينقل بطاقة المقال من قائمة "مواد للتدقيق" إلى قائمة "مواد للنشر"، وعبر الضغط على البطاقة هناك يمكنه إضافة إشارة mention إلى مسؤول النشر في الموقع كي يستلم المادة ويجدولها للنشر. هذه صورة مختصرة ومُبسطة عن أسلوب Trello لإدارة سير العمل وتتبعه، وتسهيل التعاون بين فريق العمل. كيف تنشئ مجموعة عمل؟ حتّى تستطيع إدارة العمل مع الفريق الخاص بك أنت بحاجة إلى إنشاء مجموعة عمل أولًا؛ ثم إنشاء لوح مشترك جديد خاص بالمجموعة. للقيام بذلك اضغط على إشارة الإضافة + أعلى ويسار الموقع، لتظهر لدينا ثلاثة خيارات: الأول لإنشاء لوح جديد، الثاني لإنشاء مجموعة عمل شخصية، أما الخيار الثالث فهو لإنشاء مجموعة عمل تجارية وهذا الخيار يحتاج إلى اشتراك في الخطة المدفوعة لدى الموقع. لذا سننتقي الخيار الثاني ثم نكتب اسمًا للفريق ونضغط على Create: سينقلنا الموقع بعدها إلى المساحة الخاصة بمجموعة العمل والتي تتضمن أربع علامات تبويب: الأولى Boards لإنشاء وإدارة ألواح العمل الخاصة بهذه المجموعة. الثانية الأعضاء Members من هنا يمكنك البحث عن الآخرين عبر أسمائهم على Trello أو عبر عنوان بريدهم الإلكتروني، في حال لم يكن الشخص مُسجلًا لدى الموقع فسيظهر أسفل اسمه زر Send بدلًا من Add لإرسال دعوة بريدية له للاشتراك. علامة التبويب الثالثة Settings تتضمن عدّة خيارات، يمكننا تعديل واحد منها فقط والباقي تحتاج إلى الاشتراك المدفوع، الخيار هو Visibility ويُعبّر عن مستوى خصوصيّة مجموعة العمل، حيث لدينا خيارين: الأوّل خاص Private، وهنا تكون رؤية المجموعة وإمكانية العمل ضمنها محصورة بمن تدعوه لها. الثاني عام Public، حيث يمكن لأي شخص لديه رابط المجموعة تصفح جميع تفاصيلها، كما يمكن لمحركات البحث مثل Google فهرسة محتواها، لكن فقط الأعضاء المدعوون يمكنهم العمل ضمنها. أما ثالث الخيارات Business class فهو مخصص بمزايا إضافية للخطة المدفوعة. نصائح عامة استخدم عناوين واضحة وكاملة لوصف البطاقات. أول ما تقوم به بعد إنشاء البطاقة هو كتابة المزيد من التفاصيل بداخلها، وإرفاق الروابط والملفات اللازمة للعمل. تابع سير العمل بنقل البطاقة من قائمة إلى أخرى كما هو مخطط له، الالتزام بهذا النظام سيجلب فوائد تنظيمية عديدة تظهر مع الوقت. لا تحذف البطاقات بعد انتهاء العمل بل أنشئ قائمة باسم «أرشيف» واحفظ فيها جميع الأعمال المنتهية، قد تلزم هذه البطاقات لاحقًا في حال حدوث خلل أو ما شابه. يمكنك استخدام Trello كلوح لإدارة المهام الشخصية حتى لو لم يكن لديك فريق عمل. ادخل صباحًا إلى Trello وراجع جميع المهام التي يتوجّب عليك تنفيذها وتفحّص إلى أين وصل سير العمل. سنتابع في دروس قادمة شرح المزيد من التفاصيل والاستخدامات عن تطبيق Trello.
  4. هل سبق لك وأن اتّصلت بإحدى الشّركات الكبيرة ( كمزوّد خدمة الإنترنت الخاص بك، أحد شركات بطاقات الائتمان، أو paypal) لتطلب المساعدة في حلّ مشكلةٍ ما ؟ في البداية تسمع صوتًا لطيفًا آليًّا يخبرك أنّك عميلُ الشركة العزيز الذي يهمّهم رضاه. ثم يسألك ذلك الصّوت عن المشكلة التي تواجهها, فتقول مثلًا "أواجه مشكلة في الاتصال بالإنترنت". فيرد عليك "عذرًا. 'وجه شكل الإنترنت' خيار خير صحيح". تضغط على الرقم 0 لعدّة مرّات، ثمّ تجرّب الضغط على (*) لعدّة مرّات لكنّ الصوت الآليّ الوَدود يخبرك مجددًا أنّها خياراتٌ غير صالحة. تقول الآن بصوتٍ مرهق "أرغب في الحديث إلى الدعم الفني". فيرد عليك الصوتُ الآلي "'راغب الحدث الفني' خيار غير صحيح". تفكّر في ترك التعامل مع هذه الشركة، لكنّك تخشى أن تتعرّض لتجربةٍ أسوأ من هذه مع شركةٍ أخرى فتتراجع عن هذا القرار. وبعد أن تفقد الأمل، تقوم بالبحث حلٍ لمشكلتك في جوجل، أو تطلب المساعدة على أحد مواقع التواصل الاجتماعي. هذا النوع من التجارب هو ما يخطر ببال روّاد الأعمال عندما يفكّرون في أَتمتَة (automate) شيءٍ من أعمالهم/مهامّهم: التواصل مع العملاء بطريقةٍ آليّةٌ مصطنعةٌ لا تُرضيهم أو تساعدهم. لكن المثال الذي ذُكر أعلاه مثالٌ على القيام بالأتمتَة (automation) بطريقةٍ خاطئةٍ بالكامل (إلا إذا كان هدفُك هو إغاظة العميل وخسارة رضاه، في هذه الحالة أقترح عليك أن تحاكي هذا المثال بالضّبط). في الواقع، أقوم بأتمتة معظم مهام مشاريعي التّجارية. ليس لديّ خيارٌ آخر، فأنا أُدير أعمالي كمستقل، إضافة إلى 4 كورسات، مدوّنتين صوتيّتين، بعض قوائم البريد الإلكتروني وأكثر- في الوقت نفسه، بنفسي وبدون مساعدةٍ من أحد. لكن على عكس المثال السّابق، أؤتمت أعمالي بشكل لا يسبب إزعاجًا لأي من زبائني. عندما تسجّل في القائمة البريديّة على سبيل المثال، سيتم الترحيب بك برسالةٍ تعبّر لك عن امتناني في قالبٍ جاهز فيه اسمُك. ستعرفُ أنّني لم أكتب هذه الرسالة خصيصًا لك أنت، لكنك لن تنزعج أيضًا من ذلك – كما أتمنى- لأنني قمتُ بأتمتَة تلك الرسالة. وفقًا للدراسات فإنّ 75% من الناس يتوقّعون تلقّي رسالةً ترحيبية عندما يشتركون في نشرةٍ (newsletter) عبر البريد الإلكتروني. ومن وجهة نظر تسويقيّة، تزيد الرسائل الترحيبية العائدات بنسبة 320% أكثر من الرسائل الدعائيّة الأخرى. يقوم أغلب النّاس بأتمتة رسائل الترحيب بمشتركي قوائمهم البريدية الجدد دونَ أي يعوا أنهم في طور عمليّة الأتمتة بالفعل. إذا قمت بأتمتة تلك الرسائل الترحيبيّة بشكلٍ صحيحٍ يتّسق مع هويّتك وهويّة شركتك وبطريقةٍ تُرضي العميل، فسيعود ذلك عليك وعلى نشاطك التّجاري بعائدٍ إيجابي. تعمل الأتمتة بصفتها امتدادًا لهويّتك وهويّة شركتك. ولذلك، فإنها يجب أن تكون بطريقتك الخاصّة وبنبرتك المميّزة، وليس كما تقوم به بعض الشّركات الكبيرة: " عميلُنا العزيز، من فضلك انتظر لمئتين دقيقة حتى تتلقّى ردًا جاهزًا مقَولبًا وغير مفيد". يمكنك أيضًا -بجانب الرسائل الترحيبية- أن تقوم بأتمتة رسائل ذات محتوى مسلٍّ كقصصٍ ممتعة أو شيء من هذا القبيل. قمت بأتمتة معظم مهام عملية تهيئة المستخدمين الجدد للعملاء الجدد في موقعي الخاص بتصميم مواقع الويب. وقد وفّر ذلك عليّ ساعاتٍ من العمل أسبوعيًّا ولم يؤثّر سلبًا -ولو بنسبةٍ بسيطة- على نسبة العملاء المُحتملين الذين قاموا بتوظيفي. باستخدام أدواتٍ مثل Zapier، تستطيع أن تقوم بالأتمتة بذكاءٍ وسهولة، ومن دون الحاجة لكتابة أي سطر برمجي. أستخدمُ Zapier مثلًا لإرسال رسالة أوتوماتيكيًّا كلما فشلت عملية الدّفع مُقابل أحد الكورسات التي أبيعها. هذا يحدث لعدّة مرّات في الأسبوع، لكنّني إن لم أفعل شيئًا حيال فشل تلك التحويلات، سأقوم بخسارة الكثير من أرباحي. ولذلك بدلًا من عدم فعل شيء حيال فشل الحوالات البنكيّة وتمنّي أن يحاول العميل الدفع مرّةً أخرى، أستخدمُ Zapier لأرسل له رسالةً مفادُها أنّه لم يكن الخطأ خطأه، مع بعض التعليمات التي تشرح كيفية الدفع باستخدام وسائل أخرى. تُرسل الرسالة في غضون ثواني من فشل التحويل. تُرسَل من عنوان بريدي الإلكتروني وتُكتب بنفس الطريقة التي أكتب بها الرسائل الشخصية (بدون أحرف كبيرة، بأسلوبي، وبتوقيعي الاعتيادي). ليس عليهم أن يتواصلوا معي مباشرةً لطلب المساعدة، وليس عليهم أن ينتظروني حتى أستيقظ (إذا كانوا يحاولون الدّفع الساعة الثالثة بعد منتصف الليل). يتم التواصل معهم على الفور برسالةٍ لطيفة مع بعض الخطوات البسيطة لحل المشكلة. ربّما تتفاجأ عندما تعلم أنّ هذه الرّسالة لها معدّل نجاح يبلغ 96%. أستخدمُ أيضًا قائمتي البريديّة لأتمتة كل ما يتعلّق بالكورسات التي أقدّمها. قيامي بذلك يسمح لي بإدارة عدد من الكورسات المختلفة مع العديد من الطّلاب في الوقت نفسه. أقدّم خيار فترة التجربة المجّانيّة في معظم كورساتي. فإذا كنت مهتمًا، يمكنك الحصول على بعض الدروس المجّانية عن طريق تسجيل بريدك الإلكتروني. أبدأ عن طريق الأتمتة بواسطة MailChimp في إرسال الرسائل أو الدروس مباشرةً - فينال العميل ما سجّل للحصول عليه على الفور وأرسله له المزيد من العيّنات المجّانيّة والمعلومات بشكلٍ يومي. أستخدم MailChimp أيضًا لاستثناء الطلّاب الذين قاموا بالتسجيل في الكورس والدّفع من الرسائل المؤتمتة التي تحتوي دروسًا مجّانية. مما يعني أنه إذا اشتريت الكورس في فترة التجربة المجّانية (التي تُرسل فيها رسائل مؤتمَتة) سوف تتوقف عن تلقّي تلك الرسائل على الفور. لقد قمتٓ للتوّ بشراء محتوى الكورس على كل حال، لذلك لست بحاجةٍ لتكدّس صندوق بريدك الإلكتروني بالرسائل التي تقدّم لك المحتوى المجّاني. ثم أقوم بإضافة العملاء الذين قاموا بشراء محتوى الكورس لقائمة بريدية أخرى (قائمة ما بعد الشراء). وهذا له عدّة فوائد: أن أريهم كيفية استعمال أدوات الكورس. أن أعلّمهم كيفية الوصول لكل المميزات والدروس التي يحتويها. أن أخبرهم عن كيفية الوصول لأقصى استفادة من محتويات الكورس عدد المشتركين في دوراتي 4000 طالب نٓشِط تقريبًا، وتأتيني رسالةٌ واحدةٌ فقط أسبوعيًا لطلب الدعم/المساعدة، وذلك لأنني أقوم بأتمتَة رسائل البريد الإلكتروني التي تشرح هذه الأمور. معظم الرسائل المؤتمتة التي أرسلها للعملاء بعد الشّراء تحتوي على آلية للتغذية الراجعة ، وذلك لأعرف ما هو رأي العملاء بالكورس الذي اشتروه، للتأكد من أنهم يستفيدون من الكورس بشكلٍ كامل ولأرى ما هي العوائد الإيجابيّة التي حصلوا عليها منه ( وهذه طريقةٌ رائعةٌ للحصول على شهادات التوصية testimonials وقصص النجاح ). يمكنك أيضًا أن تقوم بأتمتة ما يتعلّق بالتغذية الراجعة Feedback بشكلٍ مستقل باستخدام أدوات مثل Typeform لطرح الأسئلة وجمع الإجابات. الإمكانيّات والفوائد التي يمكنك الحصول عليها من أتمتة قائمتك البريدية والشؤون الأخرى في شركتك كثيرةٌ جدًا. وإذا استعملتَ الأتمتة بطريقةٍ صحيحة، فسيسعدُ عملاؤك لعنايتك بهم وباهتمامك الذي يحمل صٓبغةً شخصيّة، حتى وإن كان ذلك بطريقةٍ مؤتمتة. لا تنهج نَهج الشركات الكبيرة -التي تفشل غابًا في العناية بعملائها- في الأتمتة. يمكنك أن تستعمل الأتمتة لتكون امتدادًا لأسلوبك الشخصي المتفرّد ولكي تفيد وتساعد العملاء الذين يريدون ويحتاجون أن يتواصلوا معك ( حتى إن أرادوا ذلك في الساعة الثالثة صباحًا). ترجمة -وبتصرف- للمقال Make automation great again لصاحبه PAUL JARVIS. حقوق الصورة البارزة: Designed by Freepik.
  5. وأخيرا اقتنعت بفلسفة المصادر المفتوحة، أو أنك أخيرا وجدت الوقت للمُساهمة في أحدها، وربما ما دفعك إلى الأمر هو استفادتك من مشروع مفتوح المصدر وأردت أن ترد الجميل بالمساهمة فيه بدورك، لكن لا تدري كيف تقوم بذلك؟ الأمر بسيط، كل ما تحتاجه هو جهاز محلي يكون Git مُنصبا عليه، حساب على Github وبعض الوقت، ومن ثم اتباع بضع خُطوات بسيطة. تجدر الإشارة إلى أنك لا تحتاج إلى أن تكون مُبرمجا للمُساهمة في المشاريع مفتوحة المصدر، يُمكنك المُساهمة في إنشاء أو تحسين توثيق المشروع، حيث يُعتبر التوثيق الجيد أحد أهم عوامل نجاح المشاريع مفتوحة المصدر، وانتشار بعضها على حساب الآخر. لنفرض أن المشروع الذي تود المُساهمة فيه هو "git – الدّليل البسيط". 1. قم باستنساخ المشروع إلى حسابك الخاص وذلك بالنقر على زر Fork الموجود في الزاوية العُلوية اليُمنى لصفحة المشروع. هذه العملية من شأنها أن تُنشئ نُسخة مُطابقة للمُستودع الأصلي على حسابك على Github. 2. بعد ذلك قم باستنساخ هذا المُستودع الجديد على جهازك المحلي. ادخل إلى المجلد الذي تود استنساخ المُجلد فيه (cd path/to/folder) وقم بتنفيذ الأمر git clone متبوعا بعُنوان المُستودع. ستجد العُنوان أسفل القائمة اليُمنى في صفحة المُستودع. بالنسبة لي سيكون الأمر على النحو التالي: git clone https://github.com/djug/simple-guide.git 3. الآن وبعد أن حصلت على هذه النُسخة، قم بإدخال التعديلات التي ترغب فيها واحفظ تلك التعديلات. قبل أن نقوم بإيداع تلك التعديلات، يُنصح دائما التحقق من حالة المُستودع، وإن تم أخذ التعديلات بالحسبان أو إن قمنا بتعديل ملف لم نكن نرغب في تعديله، حيث يكفي أن ننفذ الأمر git status لمعرفة حالة المُستودع (النسخة المحلية): git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: index.ar.html4. تبدو الأمور طبيعية. لنقم بإرسال التغييرات إلى منطقة الإدراج: git add .ومن ثم إيداعها (commit): git commit -m "Your commit Message Here"بطبيعة الحال ستحتاج إلى وضع وصف مُناسب للتغييرات التي قمت بها. بإمكانك أيضا تنفيذ الأمر commit لوحده من دون أية رسائل: git commitوسيقوم git بفتح مُحرر النصوص المُفضل لديك لكتابة الوصف (في حال ما إذا قمت بتحديد اسم هذا المُحرر في إعدادات git). سنحتاج الآن إلى إرسال هذه التغييرات إلى المُستودع (الشخصي وليس مُستودع المشروع الذي نشارك فيه) على Github عبر تنفيذ الأمر: git push origin masterسيطلب منك Git اسم المُستخدم الخاص بك على Github وكلمة السر، وبمُجرد أن يتم التحقق منهما سيتم دفع التغييرات إلى مُستودعك الخاص. 5. الآن لو عدنا إلى صفحة المُستودع الشخصي على Github سيظهر لنا تاريخ آخر تحديث للملفات المُعدلة ووصف له. وكل ما نحتاج إلى فعله الآن هو إرسال "طلب سحب" pull request -أي سحب التغيرات- إلى المُستودع الأصلي للمشروع وذلك بالنقر على الزر الأخضر الذي يظهر في الزاوية العُلوية اليُمنى للمُستودع ستظهر لك صفحة لتلخص من جديد التغييرات التي تمت 6. الخطوة الأخيرة هي النقر على زر Create Pull request، إضافة أية تعليقات ترغب فيها على الطلب، ومن ثم النقر على زر Send pull request: ستصل صاحب المشروع رسالة بخصوص التغييرات التي قمت بها، وفي حال قبولها سيصلك إشعار بها وستظهر تغييراتك على المستودع الأصلي: هذا كل ما في الأمر. أنت الآن بطريق… أقصد مُشارك في مشاريع مفتوحة المصدر بشكل رسمي. نصائح عامة لدى المساهمة في المشاريعاجعل نص الإيداع commit معبّرا أو ملخصا للتغيرات التي قمت بها، لا تجعله مبهما أو عاما.افصل طلبات السحب "pull request" حسب الغرض، أو اجعل لكل تغير تقترحه في branch لوحده حسب الغرض، مثال: لا ترسل طلب سحب يحتوي تغيرات مرئية في الـ html و css وفيه أيضا ترجمة النصوص إلى العربية، هكذا تصعب المهمة على من يقوم بعملية الدمج في حال كان يريد قبول الترجمة لكنه غير راض عن التغيرات التي طرأت في الـ html/css. في هذه الحالة سيكون من الأنسب:طلب سحب للتغيرات المرئية لوحده.طلب سحب آخر للملفات الترجمة إلى العربية.في حال كانت مساهمتك تحل علة ما تم التبليغ عنها في قسم الـ issues في مستودع المشروع على github، أو لها علاقة به، فإنه يمكنك الإشارة إلى تلك العلة في نص الإيداع فقط بوضع رقم العلة مسبوقا بعلامة #، مثال:git commit -m "fix for some bug (issue #23)"ستلاحظ عند زيارة واجهة Github أن الرقم 23# في نص الإيداع، قد أصبح رابطا يحول مباشرة إلى صفحة تلك العلة. في حال قمت بعمل Fork وساهمت في المشروع، وأردت مرة أخرى أن تساهم في ذاك المشروع مجددا، فلا تنس أن تجعل مستودعك الشخصي من ذاك المشروع محدّثا، يعني اجلب التغيرات الجديدة التي طرأت على المستودع الأصلي، قبل المساهمة مجددا وعمل أي commit أو pull request، هذا يخفض من نسبة التعارض conflicts، ويسهّل عليك وعلى القائمين على المشروع عمليات الدمج، قد تكون التغيرات التي قمت بها، قد قام بها آخر، أو ربما تم حذف الملف الذي تعمل عليه أصلا من المشروع الأصلي، فيضيع جهدك هباءا منثورا.من المحبذ أيضا، استعمال صيغة الأمر في نص الإيداع، مثال، استعمل "add something to file x" عوض "adding|added something to file x".
  6. كما سبق ذكره فإن أحد أهم الاختلافات ما بين Git وأنظمة إدارة النُسخ هو الطريقة التي ينظر ويتعامل فيها Git مع البيانات. مبدئيا تقوم أغلب أنظمة إدارة النُسخ بحفظ البيانات على شكل قائمة من التغيرات التي طرأت على الملفات. هذه الأنظمة (CVS, Subversion، Perforce، Bazaar وهلم جرا) تنظر إلى البيانات التي تقوم بإدارتها على أساس أنها ملفات إضافة إلى التغييرات الحاصلة في كل ملف مع مرور الوقت، مثلما هو مُوضح في الشكل 1. الشكل 1: تقوم مُعظم الأنظمة بحفظ البيانات على هيئة الاختلافات الطارئة عليها مُقارنة بنسخة أولية من الملف. لا يتعامل Git مع البيانات على هذا النحو، بل يعتبر البيانات مجموعة من اللقطات Snapshots لنظام ملفات مُصغر. كل مرة تقوم فيها بإيداع البيانات (commit) أو تحفظ حالة مشروعك باستخدام Git، فإن ما يقوم به النظام هو التقاط صورة لما هي عليه الملفات في تلك اللحظة ويحفظها. ولجعل هذه الآلية فعالة فإنه لا يتم حفظ صور أخرى لنفس الملف ما إذا لم يتم إحداث تغييرات على الملف، بل يتم فقط الربط على الصورة السابقة. ينظر Git إلى البيانات التي يحفظها مثلما هو مُبين في الشكل 2. الشكل 2: يلتقط Git صورا على المشروع مع مرور الوقت. يُعتبر هذه الاختلاف في مبدأ العمل جوهريا، حيث يُعيد Git بشكل جذري تعريف كامل المفاهيم المُتعلقة بإدارة النُسخ التي توارثتها باقي الأنظمة عن الأنظمة التي سبقتها. هذا الاختلاف في مبدأ العمل يجعل Git أقرب ما يكون من نظام ملفات مُصغر منه إلى أنظمة إدارة النُسخ التقليدية، وهو ما مكّن من بناء أدوات في غاية القوة اعتمادا عليه. سنقوم باستعراض الفوائد المُترتبة عن مبدأ عمل Git المُختلف عن باقي الأنظمة لدى الحديث عن تفريعات Git في مقال لاحق. أغلب العمليات تتم بشكل محلي أغلب العمليات التي يقوم بها Git تحتاج فقط إلى ملفات محلية ليتم تنفيذها وذلك من دون الحاجة إلى أية بيانات من خواديم بعيدة. هذه الخاصية تُعطي الانطباع بأن Git سريع جدا مُقارنة بغيره من أنظمة إدارة النُسخ نظرا لكون كامل ملفات وتاريخ المشروع الذي تعمل عليه مُتوفرة بشكل محلي على خلاف باقي الأنظمة التي تحتاج إلى الاتصال بأجهزة وخواديم أخرى. فعلى سبيل المثال فحتى ولو احتجت إلى إلقاء نظرة على تاريخ المشروع أو مقارنة نسخ قديمة منه فإنك لن تحتاج إلى الاتصال بخادوم بعيد للقيام بذلك حيث يقوم Git بقراءته والاحتفاظ به كاملا على جهازك المحلي. هذه الخاصية تسمح لك أيضا بمواصلة العمل على مشروعك حتى ولو لم يكن لديك اتصال إنترنت، حيث يُمكنك إيداع البيانات commit في انتظار أن يكون بمقدورك الاتصال بالإنترنت من جديد. على باقي أنظمة إدارة الإصدارات، مواصلة العمل لدى انقطاع الإنترنت هو إما أمر مُستحيل أو معقد جدا. على نظام Perforce لا يُمكن القيام بأي شيء ما لم تكن مُتصلا بالخادوم الذي يدار عليه المشروع، أما Subversion وCVS فيسمحان لك بتحرير الملفات لكن لا يُمكن إدراج التغييرات ما لم تكن متصلا بخادوم مشروعك. قد لا تبدو هذه الخاصية مُهمة جدا لكن تأثيرها كبير. المحافظة على سلامة الملفات يتم التحقق من الملفات عبر عمليات checksum قبل حفظها، ومن ثم يتم استخدام ناتج هذه العملية (Cheksum) كمُعرف للملفات، يعني ذلك بأنه يستحيل تغيير مُحتوى ملف أو مُجلد من دون أن يعلم Git بذلك. هذه الخاصية هي إحدى الخواص التي بُني عليها Git والتي يعتمد عليها في الطبقات السُفلى من النظام، كما أنها جزء لا يتجزأ من المبادئ الأساسية التي بُني عليها. بفضل هذه الخاصية فإنه من غير المُمكن أن تفقد أية بيانات لدى نقلها أو أن يُصاب ملف ما بالعطب من دون أن يكون هناك لدى Git علم مُسبق بالأمر. يُطلق على الآلية التي يعتمد عليها Git للتحقق من الملفات اسم SHA-1 hash، تنتج عنها سلسلة نصية مُتكونة من 40 محرف ستعشري (الأرقام من 0 إلى 9 والحروف من a إلى f) ويتم حسابها اعتمادا على مُحتوى الملف أو المُجلد. سلاسل SHA-1 hash تكون مُشابهة للسلسلة التالية: 24b9da6552252987aa493b52f8696cd6d3b00373 لدى استخدامك لنظام Git ستشاهد هذه السلاسل في كل مكان بحكم أنه يتم استخدامها كثيرا حيث أن Git يحفظ كل شيء اعتمادًا على Hash مُحتوى كل ملف وليس اعتمادًا على أسمائها. لا يقوم Git عادة سوى بإضافة بيانات أغلب العمليات التي تقوم بها على Git تقوم بإضافة بيانات إضافية إلى قاعدة بيانات Git. من الصعب جدا أن تجعل النظام يقوم بعمليات لا يُمكن التراجع عنها أو حذف بيانات لا يُمكن استرجاعها. لدى استخدام باقي أنظمة إدارة النسخ فإنه من المُمكن أن تخسر أو تعبث ببيانات لم تقم بإدراجها بعد، لكن لدى القيام بعملية إدراج فإنه من الصعب جدا أن تفقدها خاصة ما إذا كنت تقوم بدفع البيانات إلى مستودع موجود على خادوم بعيد. هذا الأمر يجعل استخدام Git مُمتعا في حد ذاته، حيث أنه بإمكاننا القيام بأية تجارب نودها على مشاريعنا دون أن نعرض بياناتها للخطر. الحالات الثلاث للبيانات على Git إن قرأت ما سبق ذكره على عجل، فيجب أن تركز جيدا في هذه الفقرة حيث أننا سنناقش المبدأ الأساسي الذي لا يُمكن لك استخدام Git ما لم تستوعبه جيدا. لدى استخدام Git فإن الملفات تملك إحدى الحالات الثلاث التالية: مرحلة الإيداع (ملفات تم إيداعها committed)، مرحلة التعديل (ملفات أجريت تعديلات عليها modified) ومرحلة الإدراج (ملفات تم إدراجها staged). المقصود بالإيداع commit هو أن حفظ البيانات بشكل آمن في قاعدة البيانات المحلية. الملفات التي تم تعديلها هي التي تم إدخال تغييرات عليها لكنه لم يتم حفظ تلك التغييرات إلى قاعدة البيانات المحلية بعد. أما الإدراج فهو تعليم الملفات التي تم تعديلها في حالتها الحالية ليتم تضمينها في الإيداع القادم. هذه الحالات الثلاث تُقسم مشاريع Git إلى 3 أقسام: مُجلد Git، مُجلد العمل، ومنطقة الإدراج. الشكل 3: مُجلد Git، مُجلد العمل ومنطقة الإدراج مُجلد Git هو المكان الذي يقوم النظام فيه بتخزين البيانات الوصفية metadata وقاعدة بيانات مشروعك، ويُعتبر الجزء الأهم من Git حيث أنه المُجلد الذي يتم نسخه لدى القيام بعملية استنساخ المُستودعات الموجودة على أجهزة أخرى. مُجلد العمل عبارة عن إصدار المشروع الحالي والذي يحتوي ملفات تم استخراجها من قاعدة بيانات Git ووضعها تحت تصرفك لإدخال التعديلات التي ترغب فيها عليها. منطقة الإدراج عبارة عن ملف واحد يتم الاحتفاظ به عادة داخل مُجلد Git والذي يحفظ معلومات حول المُحتوى الذي سيتم إرساله في الإيداع القادم. عادة ما تتم الإشارة إليه باسم الفهرس index لكن استخدام مُصطلح “منطقة الإدراج” staging area أصبح الأكثر شيوعا. سير عمل مشاريع Git يتم عادة على النحو التالي: التعديل على الملفات الموجودة في مُجلد العمل. إضافة الملفات إلى منطقة الإدراج إيداع الملفات commit، أي التقاط صورة عن الملفات الموجودة في منطقة الإيداع وحفظها بشكل دائم داخل مُجلد Git. لتلخيص الأمر: إذا كان الملف موجودا داخل مُجلد Git فهذا يعني بأنه تم إيداعه committed. إذا تم إدخال تغييرات عليه وتم وضعه في منطقة الإيداع فهذا ملف مُدرج staged. أما إذا تم إحداث تغييرات عليه ولم يتم نقله إلى منطقة الإدراج فيُعتبر مُعدّلا. في مقال قادم سنتحدث بشكل أوسع حول الحالات الثلاث هذه وكيفية الاستفادة منها بشكل جيد، إضافة إلى كيفية تجاوز منطقة الإدراج بشكل كامل. ترجمة -وبتصرف- لـ Git Basics من كتاب Pro Git لصاحبه Scott Chacon.