Sumber Daya untuk Program Kode Musim Panas Google.
Halo! Dan selamat datang di gudang sumber daya Google Summer of Code (GSOC) Stdlib.
GSOC adalah program global yang menawarkan kontributor baru (yang berusia 18 tahun atau lebih) peluang untuk dibayar untuk berkontribusi pada proyek open source selama periode tiga bulan. Kontributor dibayar oleh Google untuk bekerja di bawah panduan mentor dari komunitas open source. GSOC adalah peluang besar untuk belajar, mengembangkan keterampilan baru, membangun koneksi, memperoleh pengalaman bekerja dengan tim yang lebih besar dan sering didistribusikan, dan dikompensasi secara finansial atas upaya Anda.
Dalam repositori ini, Anda akan menemukan informasi tentang cara melamar GSOC dan daftar ide potensial yang dapat berfungsi sebagai dasar untuk proyek GSOC.
Kontributor GSOC diharapkan bekerja baik 350 jam (setara dengan waktu penuh), 175 jam (setara paruh waktu), atau 90 jam (setara waktu) selama program. Jadwal default berlangsung selama 3 bulan (12 minggu) dan berpotensi tersebar dalam periode yang lebih lama.
Tanggal mulai program tidak dapat dinegosiasikan . Semua kontributor GSOC harus memulai program pada saat yang sama.
Untuk mendaftar ke GSOC dengan stdlib, Anda harus:
Harap diingat bahwa semua aplikasi harus melalui sistem aplikasi Google dan Anda harus mengirimkan aplikasi Anda di situs web Google . Jika Anda tidak mengirimkan aplikasi Anda di situs web GSOC, kami tidak dapat menerima aplikasi Anda.
Maksud GSOC adalah untuk menyediakan cara bagi kontributor baru untuk bergabung dan berpartisipasi dalam dunia open source. Para kontributor yang paling mungkin dipilih dan pada akhirnya berhasil adalah mereka yang terlibat dalam masyarakat dan berharap untuk melanjutkan keterlibatan mereka di luar durasi program GSOC. Secara umum, untuk sebagian besar proyek, menjadi anggota komunitas yang baik lebih penting daripada menjadi pembuat kode yang baik .
Menyampaikan. Komunikasi mungkin merupakan bagian terpenting dari proses aplikasi. Bicaralah dengan mentor dan pengembang stdlib lainnya, dengarkan ketika mereka menawarkan saran, dan menunjukkan bahwa Anda telah memahami saran mereka dengan memasukkan umpan balik mereka ke dalam apa yang Anda usulkan. Kegagalan untuk memasukkan umpan balik secara signifikan menurunkan peluang keberhasilan Anda.
Baca instruksinya. Selalu baca (dan baca ulang) semua instruksi saat mengirimkan proposal. Jangan hanya mengirimkan resume, makalah ilmiah, presentasi, atau file lain yang tidak berisi informasi tentang proyek yang ingin Anda kejar. Kegagalan untuk mengikuti instruksi dijamin akan menyebabkan penolakan proposal.
Menjadi profesional. Tunjukkan rasa hormat dan tunjukkan bahwa Anda akan menganggap serius hubungan pendampingan. Itu berarti mendengarkan secara aktif ketika Anda menerima umpan balik dan selalu menghargai waktu setiap anggota di komunitas STDLIB. Komunikasi yang buruk dan kegagalan untuk membaca dan mengikuti instruksi menyampaikan kurangnya rasa hormat dan kurangnya pertimbangan untuk waktu mentor, dan tidak ada mentor yang ingin bekerja dengan kontributor yang tidak menunjukkan profesionalisme yang diperlukan untuk memastikan keberhasilan proyek mereka dan Pertumbuhan pribadi mereka sebagai anggota komunitas STDLIB.
Jika Anda memiliki pertanyaan, periksa apakah pertanyaannya sudah dijawab di FAQ GSOC. Jika Anda masih memiliki pertanyaan setelah berkonsultasi dengan FAQ GSOC, Anda dapat menjangkau saluran elemen stdlib.
Anda dapat menggunakan elemen untuk meminta umpan balik pada ide -ide proyek awal dan untuk mendapatkan bantuan saat Anda mulai bekerja dengan basis kode stdlib. Ingatlah bahwa semakin spesifik dan bersihkan pertanyaan Anda di forum STDLIB, semakin besar kemungkinan Anda mendapatkan jawaban yang baik. Pertanyaan terbuka atau tidak jelas tidak mungkin mendapatkan respons yang berguna.
Misalnya, pertanyaan yang bagus bisa menjadi sesuatu di sepanjang garis
Saya tertarik pada Project X, dan saya telah melakukan sedikit riset dan menemukan bahwa masalah Y dan Z tampaknya terkait. Berdasarkan temuan saya, A, B, dan C sudah diterapkan, jadi saya ingin tahu apakah akan masuk akal untuk mengusulkan proyek yang akan mencapai D, E, dan F.
Sebaliknya, pertanyaan berikut terlalu terbuka dan terlalu kabur untuk meminta respons yang bermakna
Saya tertarik dengan Project X. Tolong bantu saya untuk mengerjakan ini.
Saat menjangkau elemen, pastikan untuk memperkenalkan diri Anda sehingga kami dapat mengenal Anda. Beberapa informasi yang berguna untuk dimasukkan
Sebelum mengerjakan aplikasi GSOC Anda, silakan tinjau daftar ide kami untuk melihat apakah Anda menemukan proyek yang menggairahkan Anda. Daftar ide yang ada disediakan untuk berfungsi sebagai inspirasi dan untuk menunjukkan arah mana yang mungkin baik untuk stdlib.
Jika Anda menemukan ide yang ingin Anda kejar, pastikan untuk menghubungi kami di saluran elemen kami untuk membahasnya terlebih dahulu! Selalu pastikan untuk bertanya tentang ide -ide ini sebelum mengerjakan aplikasi untuk mendapatkan informasi terbaru tentang apa yang sudah diimplementasikan dan apa yang sebenarnya harus dilakukan.
Daftar ide disusun oleh label sesuai dengan konvensi berikut:
Prioritas
high : Gagasan yang dianggap penting dalam peta jalan kita.normal : Gagasan yang tidak mendesak tetapi akan menyenangkan memiliki lebih cepat daripada nanti.low : Gagasan yang baru atau menarik, tetapi rendah dalam daftar prioritas kami.Kesulitan
1 : Sebuah ide yang cocok untuk seseorang dengan sedikit atau tanpa pengalaman JavaScript.2 : Sebuah ide yang cocok untuk seseorang dengan pengetahuan JavaScript yang berfungsi.3 : Gagasan yang cenderung menantang tetapi dapat dikelola.4 : Gagasan yang kemungkinan akan menantang dan memiliki tujuan yang ambisius.5 : Gagasan yang mungkin sulit diimplementasikan dengan beberapa yang tidak diketahui.Teknologi
javascript : Gagasan yang melibatkan pemrograman dalam JavaScript. Setidaknya beberapa JavaScript kemungkinan diperlukan untuk semua ide.nodejs : Gagasan yang membutuhkan pengembangan dengan Node.js. Bekerja dengan Node.js kemungkinan diperlukan untuk sebagian besar, jika tidak semua, ide, karena Node.js adalah lingkungan default untuk pengujian, pembandingan, dan pengembangan lokal.c : Gagasan yang melibatkan pemrograman dalam C. Ini diperlukan untuk add-ons asli node.js.fortran : Gagasan yang melibatkan pemrograman di Fortran. Ini diperlukan untuk mengerjakan binding BLAS/Lapack.html/css : Gagasan yang melibatkan penggunaan HTML dan CSS (misalnya, jika membangun aplikasi frontend).jsx/react : Gagasan yang melibatkan pemrograman dengan React JSX (misalnya, jika bekerja di situs web STDLIB).native addons : Gagasan yang melibatkan pengembangan add-ons asli Node.js.typescript : Gagasan yang melibatkan pemrograman dalam TypeScript.Area prioritas, kesulitan, teknologi, dan topik tidak memiliki pengaruh pada kemungkinan ide diterima. Semua ide sama baiknya, dan peluang Anda diterima hanya bergantung pada kualitas aplikasi Anda .
Panjang proyek
GSOC memungkinkan tiga panjang proyek yang berbeda: 90 jam, 175 jam dan 350 jam. Setiap ide harus menunjukkan apakah idenya lebih cocok untuk 90, 175, atau 350 jam.
Dalam beberapa kasus, kami mungkin dapat memperpanjang proyek 175 jam ke proyek 350 jam dengan memperluas ide -ide tentang apa yang dapat dilakukan. Demikian pula, dalam beberapa kasus, proyek 350 jam dapat dipersingkat menjadi proyek 175 jam dengan hanya menerapkan bagian dari sebuah ide dan meninggalkan sisanya untuk proyek masa depan. Dalam kedua kasus tersebut, jika Anda ingin menyesuaikan panjang proyek, pastikan untuk menghubungi kami di saluran elemen kami untuk membahasnya terlebih dahulu!
Jika Anda ingin mengirimkan ide Anda sendiri, itu juga diterima; Pastikan untuk mengusulkan ide Anda kepada mentor stdlib terlebih dahulu! Setelah menjangkau, kami akan memberi tahu Anda apakah ide tersebut telah diterapkan, jika idenya akan memerlukan pekerjaan yang cukup untuk bertahan selama program GSOC, jika ide tersebut membutuhkan terlalu banyak pekerjaan untuk dikejar secara bermakna selama GSOC, dan jika pada Ide berada dalam ruang lingkup stdlib. Ide -ide yang tidak diminta dan tidak dibahas cenderung diterima.
Proyek terbaik untuk Anda adalah yang paling Anda minati dan berpengetahuan luas. Kegembiraan dan bakat adalah dua bahan utama dari proyek yang sukses dan membantu memastikan komitmen dan kemampuan Anda untuk melihat proyek hingga selesai. Jadi jika ada sesuatu yang sangat Anda sukai dan Anda percaya selaras dengan ruang lingkup dan tujuan Stdlib, kami akan senang mendengar nada Anda!
Setelah berdiskusi dengan kami di saluran elemen kami dan menerima persetujuan untuk mengirimkan ide Anda, buka masalah yang menjelaskan ide Anda menggunakan Template Masalah Ide .
Selain proposal tertulis, kami mengharuskan setiap pelamar GSOC untuk menulis tambalan dan membuatnya digabungkan ke dalam repositori stdlib utama.
Kami membawa tambalan Anda ke stdlib ke dalam pertimbangan yang kuat saat meninjau proposal Anda. Mengirimkan satu atau lebih tambalan adalah kesempatan terbaik Anda untuk menunjukkan bahwa Anda mampu melakukan apa yang termasuk dalam proposal Anda.
Untuk mengirimkan tambalan,
Garakan repositori stdlib.
Siapkan platform Anda untuk mengembangkan stdlib (misalnya, instal git, klon repositori bercabang Anda, atur untuk melacak repositori stdlib hulu jarak jauh, instal dependensi, dan inisialisasi lingkungan pengembangan lokal Anda). Panduan yang berkontribusi kami menuntun Anda melalui pengaturan git dan merinci cara pengembangan yang kami sukai.
Harap jangan mengirimkan tambalan melalui editor web GitHub. Anda perlu belajar cara menggunakan git dan mengembangkan stdlib secara lokal jika proyek Anda diterima. Meluangkan waktu sekarang untuk menggunakan git dan mengembangkan stdlib secara lokal meningkatkan peluang keberhasilan Anda dan membantu Anda memutuskan apakah stdlib cocok untuk Anda.
Temukan sesuatu di stdlib yang tidak berhasil, perlu ditingkatkan, atau akan menjadi tambahan yang berguna. Jika Anda membutuhkan inspirasi, jangan ragu untuk memperbaiki masalah apa pun dalam daftar masalah yang baik untuk kontributor pertama kali.
Selain masalah, cari FIXME atau TODO di basis kode. Anda dapat menggunakan grep dari baris perintah dengan git grep "TODO" .
Anda juga dapat bermain -main di stdlib repl dan menemukan sesuatu yang perlu diperbaiki atau dapat diimplementasikan.
Setelah Anda menemukan sesuatu, jika suatu masalah belum ada, buka masalah pada pelacak masalah stdlib yang menggambarkan masalah dan solusi yang Anda usulkan.
Jika proyek Anda akan menggunakan bahasa selain JavaScript (misalnya, C atau Fortran), Anda harus mengirimkan tambalan yang menggunakan bahasa itu, juga, untuk menunjukkan bahwa Anda mahir dalam bahasa itu.
Perhatikan bahwa tambalan Anda harus terkait dengan kode, bukan dokumentasi. Sementara perbaikan dokumentasi selalu diterima, mereka tidak memenuhi persyaratan patch.
Dan perhatikan lebih lanjut bahwa tambalan Anda tidak perlu terkait dengan proyek yang Anda usulkan untuk memenuhi persyaratan tambalan. Untuk membiasakan diri dengan kode tempat Anda akan bekerja, Anda mungkin ingin mencoba memperbaiki bug yang relevan dalam kode yang sama atau serupa, tetapi ini bukan bagian dari persyaratan tambalan.
Publikasikan tambalan Anda untuk peer review dengan membuat permintaan tarik di github. Anda harus mengirimkan permintaan tarik Anda melalui github (sebagai lawan, misalnya, menempelkan file yang ditambal pada suatu masalah) karena ini adalah cara termudah bagi kami untuk meninjau kode Anda dan memberikan umpan balik dan merupakan apa yang kami harapkan dari kontributor yang bekerja pada a Proyek GSOC.
Anda harus mengirimkan tambalan yang berhasil ditinjau dan digabungkan untuk memenuhi persyaratan tambalan. Kami tidak mempertimbangkan aplikasi tanpa berhasil menggabungkan tambalan.
Patch yang sukses menunjukkan kemahiran teknis Anda dan kemampuan Anda untuk berinteraksi dengan komunitas STDLIB.
Setelah Anda membuat permintaan tarik di GitHub, pengulas STDLIB akan meninjau kode Anda dan berpotensi meminta perubahan. Anda harus mengatasi perubahan ini.
Sepanjang proses pengembangan dan umpan balik, Anda harus selalu menjalankan tes unit secara lokal untuk memverifikasi perilaku yang diharapkan.
Selama ulasan, harap bersabar dengan pengulas. Karena GSOC, mungkin ada sejumlah permintaan tarik untuk ditinjau, dan kami mungkin lambat meninjau semua permintaan tarik, terutama jika mereka diajukan dekat dengan batas waktu aplikasi. Anda sangat dianjurkan untuk mengirimkan permintaan tarik Anda di awal proses aplikasi untuk memberi diri Anda kesempatan terbaik untuk memiliki tambalan gabungan sebelum batas waktu aplikasi .
Meskipun memiliki tambalan yang digabungkan sebelum tenggat waktu aplikasi lebih disukai, jika tambalan Anda masih sedang ditinjau, itu baik -baik saja. Yang penting adalah tambalan Anda digabungkan sebelum tenggat waktu penerimaan .
Terserah Anda untuk menanggapi umpan balik kami secara cukup tepat waktu agar tambalan Anda dapat digabungkan sebelum batas waktu penerimaan .
Dalam aplikasi Anda, berikan ringkasan singkat tentang kontribusi Anda kepada STDLIB sejauh ini, termasuk pekerjaan yang belum digabungkan. Ini harus menjadi daftar permintaan tarik dan indikasi apakah setiap permintaan tarik digabungkan, ditutup, atau masih terbuka. Jika Anda memberikan kontribusi yang signifikan di luar permintaan tarik Anda (misalnya, meninjau permintaan tarikan orang lain), Anda dapat mencantumkannya juga.
Harap dicatat bahwa kami tidak akan mentolerir plagiarisme dalam bentuk apa pun. Saat mengembangkan aplikasi Anda, lakukan dengan menulis dengan kata -kata Anda sendiri .
Sementara pelamar lain dapat secara terbuka mendiskusikan dan mengirimkan proposal untuk ide yang sama, Anda tidak boleh mengangkat konten dari proposal mereka. Anda harus menulis dan mengusulkan apa yang menurut Anda merupakan tindakan terbaik untuk memastikan proyek yang sukses sesuai dengan garis waktu yang Anda yakini sesuai.
Jika kami mendeteksi bahwa aplikasi Anda berisi konten yang dijiplak, kami akan menolak aplikasi Anda tanpa ulasan.
Selain itu, sementara kami menyadari bahwa, bagi banyak kontributor, bahasa Inggris mungkin bukan bahasa pertama Anda, harap hindari menggunakan LLMS (misalnya, chatgpt, dll). Kami biasanya dapat mengetahui kapan individu mengandalkan LLMS untuk menghasilkan konten aplikasi secara otomatis (dan kontribusi kode!), Dan apa yang sinyal ini bagi kami adalah bahwa Anda tidak dapat repot-repot meluangkan waktu untuk menulis aplikasi yang bijaksana dan bahwa Anda mungkin tidak akan seperti itu mampu mendapatkan kepercayaan kita.
Kandidat terbaik adalah mereka yang bijaksana, yang memperhatikan detail, dan yang ingin belajar.
Dokumen ini meminjam dari
Dokumen ini dapat digunakan kembali di bawah lisensi Creative Commons Attribution-Sharealike 4.0 International (CC BY-SA 4.0).