google summer of code
1.0.0
موارد برنامج Google Summer of Code.
مرحبًا! ومرحبا بكم في مستودع موارد Google Summer of Code (GSOC) من Stdlib.
GSOC هو برنامج عالمي يوفر للمساهمين الجدد (الذين يبلغون من العمر 18 عامًا أو أكبر) فرصة للدفع مقابل المساهمة في مشروع مفتوح المصدر على مدار فترة ثلاثة أشهر. يتم دفع المساهمين من قبل Google للعمل تحت إشراف الموجهين من مجتمع مفتوح المصدر. تعد GSOC فرصة رائعة للتعلم وتطوير مهارات جديدة وبناء اتصالات واكتساب خبرة في العمل مع فريق أكبر وغالبًا ما يتم توزيعها ، ويتم تعويضها ماليًا لجهودك.
في هذا المستودع ، ستجد معلومات حول كيفية التقدم للحصول على GSOC وقائمة من الأفكار المحتملة التي يمكن أن تكون بمثابة أساس لمشروع GSOC.
من المتوقع أن يعمل المساهمون في GSOC إما 350 ساعة (مكافئ بدوام كامل) أو 175 ساعة (ما يعادل بدوام جزئي) أو 90 ساعة (ما يعادلها لفترة قصيرة) على مدار البرنامج. يمتد الجدول الافتراضي على مدى 3 أشهر (12 أسبوعًا) ويمكن أن ينتشر على مدى فترة أطول.
تاريخ بدء البرنامج غير قابل للتفاوض . يجب أن يبدأ جميع المساهمين في GSOC البرنامج في نفس الوقت.
من أجل التقدم إلى GSOC باستخدام stdlib ، يجب عليك:
يرجى تذكر أن جميع التطبيقات يجب أن تمر عبر نظام تطبيقات Google ويجب عليك إرسال طلبك على موقع Google على الويب . إذا لم ترسل طلبك على موقع GSOC ، فلا يمكننا قبول طلبك.
تهدف GSOC إلى توفير وسيلة للمساهمين الجدد للانضمام والمشاركة في عالم المصدر المفتوح. المساهمون على الأرجح يتم اختيارهم والنجاح في النهاية هم أولئك الذين يشاركون في المجتمع ويأملون في مواصلة مشاركتهم بعد مدة برنامج GSOC. بشكل عام ، بالنسبة لمعظم المشاريع ، فإن كونك عضوًا جيدًا في المجتمع هو أكثر أهمية من كونه المبرمج الجيد .
يتواصل. ربما يكون التواصل هو الجزء الأكثر أهمية في عملية التقديم. تحدث إلى الموجهين وغيرهم من مطوري stdlib ، والاستماع عندما يقدمون المشورة ، وأثبت أنك فهمت اقتراحاتهم من خلال دمج ملاحظاتهم في ما تقترحه. الفشل في دمج ردود الفعل يقلل بشكل كبير من فرصتك في النجاح.
اقرأ التعليمات. اقرأ دائمًا (وإعادة قراءة) جميع التعليمات عند تقديم المقترحات. لا تقم ببساطة بإرسال سيرة ذاتية أو ورقة علمية أو عرض تقديمي أو ملف آخر لا يحتوي على أي معلومات حول المشروع الذي ترغب في متابعته. إن عدم اتباع التعليمات مضمونة لقيادة رفض الاقتراح.
كن محترفًا. أظهر الاحترام وأظهر أنك ستأخذ علاقة التوجيه على محمل الجد. هذا يعني الاستماع بنشاط عند تلقي التعليقات وتقييم وقت كل عضو في مجتمع stdlib. ينقل التواصل الضعيف والفشل في قراءة واتباع التعليمات عدم الاحترام وعدم النظر في وقت المعلم ، ولا يريد أي معلم العمل مع مساهم لا يظهر الاحترافية اللازمة لضمان نجاح مشروعهم و نموهم الشخصي كعضو مجتمع stdlib.
إذا كانت لديك أسئلة ، تحقق أولاً مما إذا كانت الأسئلة قد تمت الإجابة عليها بالفعل في الأسئلة الشائعة حول GSOC. إذا كان لا يزال لديك سؤال بعد استشارة الأسئلة الشائعة حول GSOC ، فيمكنك التواصل مع قناة عنصر stdlib.
يمكنك استخدام العنصر لطلب التعليقات على أفكار المشروع الأولية والحصول على المساعدة عندما تبدأ العمل مع قاعدة كود stdlib. ضع في اعتبارك أنه كلما كان أسئلتك أكثر تحديداً ومسحًا في منتديات stdlib ، زاد احتمال الحصول على إجابة جيدة. من غير المرجح أن يحصل سؤال مفتوح أو غامض على استجابة مفيدة.
على سبيل المثال ، يمكن أن يكون السؤال الجيد شيئًا على غرار
أنا مهتم بالمشروع X ، وقد قمت ببعض الأبحاث ووجدت أن المشكلات التي تبدو y و z ذات صلة. استنادًا إلى النتائج التي توصلت إليها ، يتم تنفيذ A و B و C بالفعل ، لذلك أود أن أعرف ما إذا كان من المعقول اقتراح مشروع يحقق D و E و F.
في المقابل ، يكون السؤال التالي مفتوحًا جدًا وغامضًا جدًا لدرجة أنه لا يطلب استجابة ذات مغزى
أنا مهتم بالمشروع X. الرجاء مساعدتي في العمل على هذا.
عند الوصول إلى العنصر ، تأكد من تقديم نفسك حتى نتمكن من التعرف عليك. بعض المعلومات المفيدة لتضمينها
قبل العمل على تطبيق GSOC الخاص بك ، يرجى مراجعة قائمة الأفكار الخاصة بنا لمعرفة ما إذا كنت تجد مشروعًا يثيرك. يتم توفير قائمة الأفكار الحالية لتكون بمثابة مصدر إلهام ولإشارة إلى الاتجاهات التي قد تكون جيدة ل stdlib.
إذا وجدت فكرة حالية ترغب في متابعتها ، فيرجى التأكد من الاتصال بنا في قناة العناصر الخاصة بنا لمناقشتها أولاً! تأكد دائمًا من السؤال عن هذه الأفكار قبل العمل على التطبيق من أجل الحصول على أحدث المعلومات حول ما تم تنفيذه بالفعل وما يجب القيام به بالضبط.
يتم تنظيم قائمة الأفكار بواسطة العلامات وفقًا للاتفاقيات التالية:
أولوية
high : الأفكار التي تعتبر مهمة في خارطة الطريق الخاصة بنا.normal : الأفكار غير الملحة ولكن سيكون من الجيد أن تكون عاجلاً وليس آجلاً.low : الأفكار التي هي جديدة أو مثيرة للاهتمام ، ولكنها منخفضة في قائمة أولويتنا.صعوبة
1 : فكرة مناسبة لشخص لديه تجربة JavaScript قليلاً أو معدومة.2 : فكرة مناسبة لشخص لديه معرفة عملية بجافا سكريبت.3 : فكرة من المحتمل أن تكون صعبة ولكن يمكن التحكم فيها.4 : فكرة من المحتمل أن تكون صعبة ولها أهداف طموحة.5 : فكرة من المحتمل أن يكون من الصعب تنفيذها مع العديد من المجهولين.تكنولوجيا
javascript : فكرة تتضمن البرمجة في JavaScript. على الأقل ، من المحتمل أن تكون بعض JavaScript مطلوبة لجميع الأفكار.nodejs : فكرة تتطلب التطوير باستخدام Node.js. من المحتمل أن يكون العمل مع Node.js مطلوبًا لمعظم الأفكار ، إن لم يكن كلها ، لأن Node.js هي البيئة الافتراضية للاختبار والقياس والتطوير المحلي.c : فكرة تتضمن البرمجة في C. هذا مطلوب للإضافات الأصلية Node.js.fortran : فكرة تنطوي على البرمجة في فورتران. هذا مطلوب للعمل على روابط Blas/Lapack.html/css : فكرة تنطوي على استخدام HTML و CSS (على سبيل المثال ، إذا كانت بناء تطبيق واجهة).jsx/react : فكرة تتضمن البرمجة مع React JSX (على سبيل المثال ، إذا عملت على موقع stdlib).native addons : فكرة تتضمن تطوير الوظائف الإضافية الأصلية Node.js.typescript : فكرة تتضمن البرمجة في TypeScript.الأولوية والصعوبة والتكنولوجيا ومجال الموضوع لا تؤثر على فرص قبول فكرة. جميع الأفكار جيدة على قدم المساواة ، وفرص قبولك تعتمد فقط على جودة تطبيقك .
طول المشروع
يسمح GSOC بثلاثة أطوال مختلفة للمشروع: 90 ساعة و 175 ساعة و 350 ساعة. يجب أن تشير كل فكرة إلى ما إذا كانت الفكرة مناسبة بشكل أفضل لـ 90 أو 175 أو 350 ساعة.
في بعض الحالات ، قد نكون قادرين على تمديد مشروع مدته 175 ساعة إلى مشروع مدته 350 ساعة من خلال توسيع أفكار ما يمكن القيام به. وبالمثل ، في بعض الحالات ، يمكن تقصير مشروع مدته 350 ساعة إلى مشروع مدته 175 ساعة من خلال تطبيق جزء فقط من فكرة وترك الباقي لمشروع مستقبلي. في كلتا الحالتين ، إذا كنت ترغب في ضبط طول المشروع ، فيرجى التأكد من الاتصال بنا في قناة العناصر الخاصة بنا لمناقشتها أولاً!
إذا كنت ترغب في تقديم فكرتك الخاصة ، فهذا موضع ترحيب أيضًا ؛ فقط تأكد من اقتراح فكرتك لموجهين stdlib أولاً! بعد التواصل ، سنبلغك ما إذا كانت الفكرة قد تم بالفعل تنفيذها ، إذا كانت الفكرة ستستلزم عملًا كافيًا لاستمرار مدة برنامج GSOC ، وإذا كانت الفكرة تتطلب الكثير من العمل الذي يجب متابعته بشكل مفيد أثناء GSOC ، وإذا كان الفكرة ضمن نطاق stdlib. الأفكار غير المرغوب فيها وغير المنقولة أقل عرضة للقبول.
أفضل مشروع لك هو الذي تهتم به أكثر ودراية به. الإثارة والكفاءة هما عنصران رئيسيان لمشروع ناجح ويساعدان على ضمان التزامك وقدرتك على رؤية المشروع حتى الانتهاء. لذا ، إذا كان هناك شيء أنت متحمس بشكل خاص وتعتقد أنه يتماشى مع نطاق وأهداف Stdlib ، فسنكون سعداء لسماع الملعب الخاص بك!
بعد مناقشة معنا في قناة العناصر لدينا وتلقي الموافقة على تقديم فكرتك ، يرجى فتح مشكلة تصف فكرتك باستخدام قالب مشكلة الفكرة .
بالإضافة إلى الاقتراح المكتوب ، نطلب من كل مقدم طلب GSOC كتابة تصحيح ودمجها في مستودع stdlib الرئيسي.
نأخذ بقعك إلى stdlib في الاعتبار القوي عند مراجعة اقتراحك. إن تقديم تصحيحات واحدة أو أكثر هو أفضل فرصة لك لإثبات أنك قادر على القيام بما هو مضمن في اقتراحك.
لتقديم رقعة ،
شوكة مستودع stdlib.
قم بإعداد النظام الأساسي الخاص بك لتطوير stdlib (على سبيل المثال ، تثبيت GIT ، واستنساخ مستودعك المتشعب ، وقم بإعداده لتتبع مستودع stdlib عن بُعد ، وتثبيت التبعيات ، وتهيئة بيئة التطوير المحلية). يمشي دليلنا المساهمين من خلال إعداد GIT وتفاصيل طريقة التطوير المفضلة لدينا.
يرجى عدم تقديم تصحيحات من خلال محرر الويب Github. ستحتاج إلى معرفة كيفية استخدام git وتطوير stdlib محليًا إذا تم قبول مشروعك. إن أخذ الوقت الآن لاستخدام Git وتطوير stdlib يزيد محليًا من فرصتك في النجاح ويساعدك على تحديد ما إذا كانت STDLIB مناسبة لك.
ابحث عن شيء في stdlib لا يعمل ، أو يحتاج إلى تحسين ، أو سيكون إضافة مفيدة. إذا كنت بحاجة إلى الإلهام ، فلا تتردد في إصلاح أي مشكلة في قائمة المشكلات التي هي جيدة للمساهمين لأول مرة.
بالإضافة إلى المشكلات ، ابحث عن FIXME أو TODO في قاعدة الشرف. يمكنك استخدام grep من سطر الأوامر مع git grep "TODO" .
يمكنك أيضًا اللعب في REPL STDLIB والعثور على شيء يحتاج إلى إصلاح أو يمكن تنفيذه.
بمجرد العثور على شيء ما ، إذا لم تكن هناك مشكلة بالفعل ، افتح مشكلة على تعقب مشكلة stdlib يصف المشكلة والحل المقترح.
إذا كان مشروعك سيستخدم لغة أخرى غير JavaScript (على سبيل المثال ، C أو Fortran) ، فيجب عليك إرسال تصحيحات تستخدم تلك اللغة أيضًا ، من أجل إثبات أنك تتقن تلك اللغة.
لاحظ أن التصحيح الخاص بك يجب أن يكون مرتبطًا بالرمز ، وليس الوثائق. في حين أن إصلاحات الوثائق نرحب دائمًا ، فإنها لا تفي بمتطلبات التصحيح.
ولاحظ أيضًا أن التصحيح الخاص بك لا يحتاج إلى أن يكون مرتبطًا بمشروعك المقترح من أجل تلبية متطلبات التصحيح. من أجل التعرف على الرمز الذي ستعمل عليه ، قد ترغب في محاولة إصلاح خطأ ذي صلة في نفس الكود أو المماثل ، ولكن هذا ليس جزءًا من متطلبات التصحيح.
نشر التصحيح الخاص بك لمراجعة النظراء عن طريق إنشاء طلب سحب على Github. يجب عليك إرسال طلب السحب الخاص بك من خلال Github (على عكس ، على سبيل المثال ، لصق ملف مصحح حول مشكلة) لأن هذه هي أسهل طريقة لنا لمراجعة الكود الخاص بك وتقديم ملاحظات وهو ما نتوقعه من مساهم يعمل على أ مشروع GSOC.
يجب عليك تقديم تصحيح يتم مراجعته بنجاح ودمجه لتلبية متطلبات التصحيح. نحن لا نفكر في التطبيقات دون دمج بنجاح.
يوضح التصحيح الناجح كفاءتك التقنية وقدرتك على التفاعل مع مجتمع stdlib.
بمجرد إنشاء طلب سحب على GitHub ، سيراجع مراجعو StdLib الكود ويطلبون تغييرات. يجب أن تتناول هذه التغييرات.
خلال عملية التطوير والتعليقات ، يجب عليك دائمًا إجراء اختبارات الوحدة محليًا للتحقق من السلوك المتوقع.
أثناء المراجعة ، يرجى التحلي بالصبر مع المراجعين. بسبب GSOC ، قد يكون هناك عدد من طلبات السحب للمراجعة ، وقد نكون بطيئين في مراجعة جميع طلبات السحب ، خاصة إذا تم تقديمها بالقرب من الموعد النهائي لتقديم الطلبات. يتم تشجيعك بشدة على تقديم طلبات (طلبات) السحب في وقت مبكر في عملية التقديم لمنح نفسك أفضل فرصة للحصول على تصحيح مدمج قبل الموعد النهائي لتقديم الطلب .
بينما يتم دمج التصحيح قبل موعد الموعد النهائي للتقديم ، إذا كان التصحيح الخاص بك لا يزال قيد المراجعة ، فهذا أمر جيد. ما هو مهم هو أن يتم دمج التصحيح الخاص بك قبل الموعد النهائي للقبول .
الأمر متروك لك للرد على ملاحظاتنا في الوقت المناسب بما فيه الكفاية من أجل دمج التصحيح الخاص بك قبل الموعد النهائي للقبول .
في طلبك ، يرجى تقديم ملخص موجز لمساهماتك إلى Stdlib حتى الآن ، بما في ذلك العمل الذي لم يتم دمجه بعد. يجب أن تكون هذه قائمة بطلبات السحب وإشارة إلى ما إذا كان يتم دمج كل طلب سحب أو مغلق أو مفتوح. إذا قدمت مساهمات كبيرة خارج طلبات السحب الخاصة بك (على سبيل المثال ، مراجعة طلب سحب شخص آخر) ، فيمكنك إدراج ذلك أيضًا.
يرجى ملاحظة أننا لن نتسامح مع الانتحال بأي شكل من الأشكال. عند تطوير تطبيقك ، قم بذلك عن طريق الكتابة بكلماتك الخاصة .
بينما يجوز لمقدمي الطلبات الآخرين مناقشة وتقديم المقترحات لنفس الفكرة علنًا ، يجب ألا ترفع المحتوى من مقترحاتهم. يجب أن تكتب وتقترح ما تعتقد أنه أفضل مسار للعمل لضمان مشروع ناجح وفقًا للجدول الزمني الذي تعتقد أنه مناسب.
إذا اكتشفنا أن التطبيق الخاص بك يحتوي على محتوى انتحاري ، فسوف نرفض طلبك دون مراجعة.
بالإضافة إلى ذلك ، بينما ندرك أنه بالنسبة للعديد من المساهمين ، قد لا تكون اللغة الإنجليزية هي لغتك الأولى ، يرجى تجنب استخدام LLMS (على سبيل المثال ، ChatGPT ، إلخ). يمكننا عادة معرفة متى يعتمد الأفراد على LLMs لمحتوى التطبيق التلقائي (ومساهمات التعليمات البرمجية!) ، وما هي هذه الإشارات إلينا هو أنه لا يمكن أن تزعجك أن تأخذ الوقت الكافي لكتابة تطبيق مدروس وأنك لن تكون من المحتمل أن تكون قادرة على كسب ثقتنا.
أفضل المرشحين هم أولئك الذين يدركون ، والذين يولون اهتمامًا وثيقًا بالتفاصيل ، والذين يتوقون إلى التعلم.
هذه الوثيقة تقترض بشدة
يمكن إعادة استخدام هذه الوثيقة بموجب ترخيص Creative Commons Attribution-Sharealike 4.0 International (CC BY-SA 4.0).
