Get best of the week

Panduan Sumber Terbuka: Meluncurkan Proyek Sumber Terbuka



Kata Pengantar Penerjemah


Beberapa bulan yang lalu di Github saya menemukan tautan "Panduan sumber terbuka" dan tidak bisa lepas. Di suatu tempat dalam seminggu saya dengan cermat membaca semua 10 bagian. Tentu saja, saya sudah tahu tentang open source: Saya membaca berbagai artikel (misalnya, "Memahami Open Source" ), menggunakan proyek-proyek seperti itu dalam pekerjaan saya, menjawab pertanyaan-pertanyaan kepada masyarakat, melaporkan bug, menjelajahi masalah dan bahkan membuat upaya-upaya canggung untuk kemudian tingkatkan, setidaknya dokumentasinya. Dan tentu saja, saya senang dengan orang-orang yang berbagi perangkat lunak dan pengetahuan tentang penggunaannya. Namun, konsep open source agak kabur dan terpisah-pisah. Dan artikel ini menambahkan kejelasan.

Selain itu, saya memiliki beberapa proyek yang saya rencanakan untuk diluncurkan dalam format ini, dengan harapan dukungan masyarakat, dan dengan banyak ketakutan dan keraguan yang menyertai, dan sekali lagi artikel ini membantu saya membangun niat saya dan menyarankan langkah-langkah praktis.

Terlepas dari sikap Anda terhadap open source, saya pikir Anda akan menemukan dalam seri 10 artikel ini banyak ide dan fakta menarik: organisasi, psikologis, hukum, etika dan teknis.

Saya membiarkan non-programmer ini membaca teks ini, mereka berkata bahwa mereka mengerti segalanya. Dan dalam judul artikel, saya sengaja meletakkan "sumber" tanpa "kode", karena topik ini relevan tidak hanya untuk programmer, tetapi untuk hampir semua aktivitas intelektual dalam format proyek terbuka.

Manual ini sendiri juga merupakan sumber terbuka dan telah diterjemahkan ke dalam 14 bahasa. Saya merasa terhormat untuk menambahkan utas Rusia dan terjemahan dari artikel pertama. Saya berencana untuk terus menerjemahkan artikel per minggu. Jika ada yang ingin terhubung, berikut adalah repositori: Panduan Open Source .

Jika tiba-tiba seseorang membutuhkan screensaver dari judul artikel (ilustrasi + nama Rusia), maka itu adalah lay-out pada codesandbox.io .

Pemilihan istilah


Saya mohon maaf sebelumnya atas kekurangan dalam terjemahan. Beberapa istilah yang tampaknya dangkal tidak begitu mudah diambil dalam bahasa Rusia. Misalnya, untuk berkontribusi, menarik permintaan, menerbitkan, saya sering menerjemahkan sebagai "ikut serta dalam proyek, mengusulkan koreksi, dan sebuah pertanyaan." Saya meninggalkan open source dalam bahasa Inggris sejauh ini. Saya sudah membuat komentar dan mengirim tautan ke kamus istilah Github . Saya tidak suka banyaknya transliterasi di sana. Jika Anda memasukkan ke dalam artikel ini semua ish, pullrequest, push, pool, fork, maka itu akan menjadi tidak dapat dipahami oleh semua orang yang tidak bekerja dengan Github.

Ya, masalahnya bisa berupa pertanyaan, tugas, laporan bug, kalimat, dll, dan sulit untuk menemukan satu kata Rusia yang akan menyampaikan semua makna ini. Tetapi masalah kata dalam bahasa Inggris juga tidak memiliki arti yang luas, hanya pencipta dan pengguna Github yang telah menganugerahinya dengan luas seperti itu. Jika kita maksud dengan kata-kata "membuka pertanyaan di Github" bahwa pertanyaan ini bisa sangat berbeda (bug, pertanyaan, permintaan bantuan, tugas, ...), maka kata "pertanyaan" akan secara harmonis menggantikan kata "masalah". Juga - tekan - kirim, tarik - terima, garpu - cabang, dll. Bukan kata itu sendiri yang penting, tetapi makna yang kami setujui untuk dimasukkan ke dalamnya. Inggris, yang pertama kali menemukan istilah masalah pada Github, juga harus terlebih dahulu membaca deskripsi dari semua makna yang mungkin dalam kerangka sistem ini.Sementara itu, saya menganggap kejelasan sebagai prioritas untuk jumlah maksimum orang yang belum bekerja dengan Github. Bagaimanapun, pemilihan istilah sedang dalam proses, dan seluruh terjemahan, seperti aslinya, adalah open source, jadi lakukan pencarian-tarik dan buka dengan ish.


: ?
«open source»?
?
Open source — ?

open source ?



open source

README






, ( ) !






: ?


Jadi, apakah Anda berpikir untuk meluncurkan proyek open source Anda? Selamat! Dunia menghargai partisipasi Anda. Mari kita bicara tentang apa itu open source dan mengapa orang melakukannya.

Apa artinya open source?


Ketika kode proyek terbuka, itu berarti bahwa siapa pun bebas untuk menggunakan, mempelajari, memodifikasi, dan mendistribusikan proyek Anda untuk tujuan apa pun. Izin ini diberikan melalui lisensi sumber terbuka .

Keuntungan dari open source adalah mengurangi hambatan untuk memilih program dan kolaborasi Anda, memungkinkan orang untuk dengan cepat mendistribusikan dan meningkatkan proyek. Selain itu, ini memberikan pengguna kemampuan untuk mengontrol kode, bukan tertutup. Perusahaan perangkat lunak open source (perangkat lunak) dapat mempekerjakan seseorang untuk melakukan perbaikan pada perangkat lunak tersebut, alih-alih hanya mengandalkan keputusan dari vendor open source.

Perangkat lunak bebas mengacu pada proyek yang sama denganperangkat lunak open source (sumber terbuka) . Kadang-kadang Anda dapat menemukan kombinasi dari istilah - istilah ini : "Perangkat lunak sumber terbuka dan gratis" (perangkat lunak sumber terbuka dan bebas FOSS atau perangkat lunak bebas, bebas, dan terbuka, FLOSS). Kata-kata gratis dan gratis di sini berarti "bebas," bukan "gratis . "

Mengapa orang membuat pekerjaan mereka terbuka?


avatarSalah satu penghargaan terbesar yang saya terima dari open source adalah hubungan yang telah terjalin dengan pengembang lain yang menghadapi masalah yang sama dengan saya.
@ kentcdodds , “Betapa Hebatnya Saya Memasuki Open Source”

Ada banyak alasan mengapa seseorang atau organisasi membuka sumber proyek mereka. Inilah beberapa di antaranya:

  • : Open source . , Exercism, 350 .
  • : Open source , . -. WordPress, , b2.
  • Transparansi: Siapa pun dapat memeriksa proyek sumber terbuka untuk kesalahan dan ketidakkonsistenan. Transparansi penting bahkan di tingkat negara. Misalnya, pemerintah Bulgaria dan Amerika Serikat mengatur transparansi untuk industri seperti perbankan, layanan kesehatan, dan perangkat lunak keamanan seperti Let's Encrypt .

Sumber terbuka tidak hanya berlaku untuk perangkat lunak, tetapi juga untuk semua hal lain: dari kumpulan data hingga buku. Dalam Tinjauan GitHub, Anda bisa mendapatkan lebih banyak ide tentang apa yang bisa menjadi terlalu sensitif.

Apakah open source gratis?


Open source adalah salah satu manfaat terbesarnya, tetapi bukan satu-satunya, melainkan produk sampingan dari nilai gabungannya.

Karena lisensi terbuka menyiratkan bahwa siapa pun dapat menggunakan, memodifikasi, dan mendistribusikan proyek Anda untuk hampir semua tujuan, dalam banyak kasus ini menyiratkan gratis. Karena jika Anda meminta bayaran, maka orang akan mengunduh proyek dan menggunakannya secara gratis, benar-benar legal.

Oleh karena itu, sebagian besar proyek open source gratis, tetapi ini tidak termasuk dalam definisi open source. Ada cara untuk membebankan biaya untuk proyek sumber terbuka secara tidak langsung melalui lisensi ganda atau fitur terbatas, tetapi mereka memenuhi definisi resmi sumber terbuka.

Haruskah saya meluncurkan proyek open source saya?


Jawaban singkatnya adalah ya, karena terlepas dari hasilnya, meluncurkan proyek Anda adalah cara yang baik untuk memahami cara kerja open source.

Jika Anda belum pernah menjalankan proyek seperti itu sebelumnya, Anda mungkin khawatir: "apa yang akan dikatakan orang?", "Bagaimana jika tidak ada yang akan memperhatikannya sama sekali?" Jika ini sudah biasa bagi Anda, jangan khawatir, Anda bukan satu-satunya!

Sumber terbuka, seperti karya kreatif apa pun, baik itu menulis atau menggambar, menimbulkan kegembiraan sebelum membaginya dengan dunia. Tetapi satu-satunya cara untuk memperbaikinya adalah dengan berlatih, bahkan jika Anda tidak memiliki audiensi.

Jika Anda belum memutuskan, luangkan waktu untuk memikirkan kemungkinan tujuan Anda.

Penetapan tujuan


Sasaran akan membantu Anda memutuskan apa yang harus dikerjakan, apa yang menyerah, dan di mana Anda membutuhkan bantuan dari luar. Tanyakan kepada diri sendiri: "Mengapa saya membuka proyek ini?" .

Tidak ada jawaban tunggal untuk pertanyaan ini. Anda dapat memiliki banyak tujuan untuk satu proyek, atau proyek yang berbeda dengan tujuan yang berbeda.

Jika tujuan Anda hanya untuk menunjukkan pekerjaan Anda dan tidak perlu kerja sama, Anda dapat menulis di file README. Di sisi lain, jika Anda tertarik pada asisten, maka Anda harus menginvestasikan waktu Anda dalam menulis dokumentasi yang dapat dimengerti dan merawat pemula.
avatar UIAlertView … open source. GitHub. , , . , - . .
mavris@mavris, « : Open Source »

Ketika proyek tumbuh, komunitas Anda akan membutuhkan lebih dari sekadar kode. Jawaban atas pertanyaan (masalah), verifikasi kode, penyebaran informasi tentang diri Anda - semua ini adalah tugas penting dari proyek sumber terbuka.

Meskipun jumlah waktu yang dihabiskan untuk tugas-tugas non-program tergantung pada ukuran dan skala proyek Anda, Anda harus siap untuk menyelesaikannya sendiri atau mencari asisten untuk ini.

Jika Anda adalah bagian dari perusahaan yang meluncurkan proyek sumber terbuka, pastikan sebelumnya bahwa Anda memiliki sumber daya internal untuk pengembangannya. Tetapkan petugas pendukung pasca peluncuran dan tentukan bagaimana tugas-tugas akan didistribusikan dalam komunitas.

Jika Anda memerlukan anggaran khusus atau staf untuk memajukan, mengoperasikan, dan mendukung proyek, diskusikan hal ini sesegera mungkin.
avatarKetika Anda memulai proyek open source, penting bahwa proses manajemen dalam organisasi mempertimbangkan kontribusi dan kemampuan komunitas yang telah terbentuk di sekitar proyek. Jangan takut untuk melibatkan orang luar, bahkan dalam aspek-aspek kunci, terutama jika mereka terlibat secara aktif.
@captainsafia , "Che, apakah Anda ingin membuka kode proyek?"

Partisipasi dalam proyek orang lain


Jika tujuan Anda adalah untuk memahami cara berinteraksi dengan orang lain dan bagaimana open source bekerja, pertimbangkan untuk berpartisipasi dalam proyek yang sudah ada yang Anda gunakan dan sukai. Partisipasi Anda dapat berupa hal-hal sederhana seperti kesalahan ketik dan pembaruan dokumentasi.

Jika Anda tidak mengerti bagaimana cara mulai berpartisipasi dalam proyek orang lain, lihat panduan kami Cara berpartisipasi dalam proyek sumber terbuka .

Mulai proyek open source Anda sendiri


Tidak ada momen yang sempurna untuk membuka sumber pekerjaan Anda. Anda dapat membukanya pada tahap ide, dalam proses kerja, atau setelah beberapa tahun penutupan.

Secara umum, Anda dapat membuka sumber ketika Anda merasa cukup percaya diri untuk menunjukkan pekerjaan Anda kepada orang asing dan mendapatkan umpan balik mereka.

Setiap proyek, terlepas dari tahap di mana Anda memutuskan untuk membuka sumbernya, harus memiliki dokumentasi berikut:


Mereka akan membantu Anda menyampaikan harapan Anda, menerima perubahan dari peserta lain, dan melindungi hak yang sah dari semua penulis bersama, termasuk Anda. Ini sangat meningkatkan kemungkinan pengalaman positif.

Jika proyek Anda menggunakan github dan Anda menempatkan file-file ini dalam kategori root dengan nama yang direkomendasikan, github akan mengenalinya dan secara otomatis akan menampilkannya kepada pembaca Anda.

Pilihan Lisensi


Lisensi sumber terbuka memastikan bahwa orang lain dapat menggunakan, menyalin, memodifikasi, dan membuat perubahan pada proyek Anda tanpa konsekuensi apa pun. Ini juga melindungi Anda dari situasi hukum yang tidak menyenangkan. Anda harus mengaktifkan lisensi ketika memulai proyek sumber terbuka.

Pekerjaan hukum tidak mudah. Tetapi ada kabar baik: Anda dapat menyalin lisensi yang ada dan menempatkannya di repositori Anda, melindungi kerja keras Anda dalam satu menit.

MIT , Apache 2.0 , dan GPLv3 adalah lisensi paling populer, tetapi ada opsi lain untuk dipilih.

Saat Anda membuat proyek baru di Github, Anda diberikan pilihan beberapa lisensi. Dengan memilih lisensi sumber terbuka, Anda akan membuat proyek Anda terbuka.

Pilih lisensi

Jika Anda memiliki pertanyaan atau masalah lain terkait aspek hukum open source, kami telah menjelaskannya di sini .

Kompilasi README


File README ("baca saya") tidak hanya menjelaskan cara menggunakan proyek Anda, tetapi juga menjelaskan mengapa itu penting dan apa yang dapat dilakukan pengguna dengan itu.

Cobalah untuk menjawab pertanyaan-pertanyaan berikut dalam README:

  • Apa yang dilakukan proyek ini?
  • Bagaimana proyek ini bermanfaat?
  • Bagaimana saya bisa mulai bekerja dengannya?
  • Di mana saya bisa mendapatkan bantuan jika diperlukan?

Anda dapat menentukan dalam README: bagaimana cara berpartisipasi dalam proyek Anda, apa tujuannya, berbicara tentang lisensi dan kepengarangan. Jika Anda tidak berencana untuk menerima peningkatan dari orang lain, atau dia belum siap untuk menjalankan - cukup tulis tentang hal itu.
avatarDokumentasi yang baik berarti lebih banyak pengguna, lebih sedikit permintaan bantuan, dan lebih banyak kolaborator. (...) Ingatlah bahwa pengguna Anda bukan Anda. Ini mungkin orang-orang dengan pengalaman - sangat berbeda dari Anda.
@tracymakes , “Tulis agar kata-kata Anda terbaca (video)”

Terkadang orang menunda menulis README karena mereka merasa bahwa proyek tersebut tidak selesai, atau tidak mau menerima perbaikan orang lain. Tapi ini hanya alasan yang bagus untuk menulis tentang itu.

Untuk inspirasi, Anda dapat membaca panduan "Make README" atau Template README .

Ketika Anda menambahkan file README ke direktori root proyek, github secara otomatis menampilkannya di halaman utama repositori.

Menulis panduan untuk peserta


File CONTRIBUTING memberi tahu audiens Anda bagaimana menjadi anggota proyek Anda. Contohnya:


Selain detail teknis, file CONTRIBUTING adalah tempat yang baik untuk menyatakan harapan Anda mengenai partisipasi orang lain. Contohnya:

  • Partisipasi seperti apa yang Anda tunggu?
  • Rencana dan visi Anda untuk pengembangan proyek
  • Bagaimana peserta dapat (dan tidak bisa) menghubungi Anda

Nada ramah Anda dan proposal spesifik Anda untuk berpartisipasi, seperti menulis dokumentasi atau membuat situs, dapat menjadi sangat penting untuk menarik pendatang baru untuk bekerja pada suatu proyek.

Misalnya, Admin Aktif memulai panduan partisipasinya dengan kata-kata ini:
Pertama-tama, kami ingin mengucapkan terima kasih karena telah mempertimbangkan untuk berpartisipasi dalam pengembangan Admin Aktif. Orang-orang seperti Anda yang menjadikan Admin Aktif sebagai alat yang hebat.

Pada tahap awal suatu proyek, file CONTRIBUTING Anda bisa sederhana. Anda harus selalu menjelaskan cara melaporkan kesalahan dan mengisi pertanyaan, serta menjelaskan persyaratan teknis untuk mengedit anggota (misalnya, tes).

Seiring waktu, Anda dapat menambahkannya dengan jawaban untuk pertanyaan umum. Karena itu, semakin sedikit orang yang akan menanyakan hal yang sama berulang kali kepada Anda.

Untuk membuatnya lebih mudah untuk mengkompilasi file CONTRIBUTING, lihat templat panduan kolaborasi @ nayafia ataumozilla's 'Bagaimana mengkompilasi file CONTRIBUTING.md' .

Tautan ke file CONTRIBUTING di dalam README, sehingga lebih banyak orang akan melihatnya. Jika Anda menempatkan file CONTRIBUTING.md di root proyek Anda , maka github akan secara otomatis merujuknya ketika seseorang membuka pertanyaan baru (masalah) atau menambahkan suntingan ke proyek (menarik permintaan).

panduan kolaborasi

Pengembangan kode etik


avatarKita semua menghadapi situasi yang tidak menyenangkan ketika pemilik proyek dengan kasar menjelaskan sesuatu atau pengguna mengajukan pertanyaan mendasar. (...) Kode perilaku menjadi dokumen yang mudah untuk dirujuk dan yang mengatakan bahwa tim Anda melakukan dialog konstruktif dengan sangat serius.
@lynlyn , Membuat open source menjadi tempat yang lebih bahagia

Sebagai hasilnya, kode etik menetapkan aturan dasar perilaku untuk para peserta dalam proyek Anda. Ini sangat penting jika Anda meluncurkan proyek untuk perusahaan atau komunitas. Kode perilaku membantu membangun perilaku yang sehat dan konstruktif di masyarakat, yang mengurangi stres bagi Anda sebagai orang yang bertanggung jawab atas proyek tersebut.

Lihat lebih detail: Pedoman Perilaku - Panduan .

Selain menjelaskan bagaimana Anda ingin peserta berperilaku, kode etik juga menjelaskan kepada siapa dan kapan berlaku, dan apa yang akan terjadi jika dilanggar.

Dengan analogi dengan lisensi, Anda tidak harus menulis kode sendiri, tetapi Anda dapat menyalin salah satu opsi yang ada. Perjanjian anggota digunakan diLebih dari 40.000 proyek sumber terbuka termasuk Kubernetes, Rails, dan Swift. Apa pun kode yang Anda gunakan, Anda harus siap untuk menerapkannya jika perlu.

Letakkan file CODE_OF_CONDUCT.md di root proyek Anda, sehingga akan lebih mudah untuk menemukan dan menautkannya, misalnya, dari README.

Memberi nama dan merek proyek Anda


Branding tidak hanya logo yang menarik dan nama yang mudah diingat, tetapi juga bagaimana Anda berbicara tentang proyek Anda dan siapa yang mencapai pesan Anda.

Memilih nama yang tepat


Pilih nama yang mudah diingat dan, idealnya, memberikan gagasan tentang esensi proyek. Contohnya:


Jika proyek Anda merupakan tambahan dari proyek yang ada, maka gunakan namanya sebagai awalan, ini akan membantu untuk memahami apa yang sedang dilakukan proyek Anda. Sebagai contoh, node-fetch membawa `window.fetch` ke Node.js).

Pilihlah kejelasan. Pun bisa menyenangkan, tetapi pikirkan orang-orang dari budaya lain atau dengan pengalaman berbeda dari Anda yang mungkin tidak mengerti lelucon itu. Pengguna potensial Anda mungkin karyawan perusahaan yang akan berbicara dengan atasan Anda tentang proyek Anda. Jangan membuat mereka memerah pada saat yang sama.

Konflik nama


Periksa proyek sumber terbuka dengan nama yang sama , terutama jika Anda menggunakan bahasa atau ekosistem yang sama. Jika nama Anda cocok dengan proyek populer yang ada, Anda dapat membingungkan audiens Anda.

Jika Anda berencana untuk memulai situs web, twitter, atau platform publikasi apa pun, pastikan nama yang Anda butuhkan gratis di sana. Dan lebih baik untuk memesan nama-nama ini sekarang untuk ketenangan pikiran, bahkan jika Anda belum berencana untuk menggunakannya.

Pastikan Anda tidak melanggar merek dagang perusahaan mana pun. Di masa depan, dia akan dapat meminta Anda untuk menutup proyek atau bahkan menuntut. Ini adalah risiko yang tidak dapat dibenarkan.

Anda dapat memeriksa konflik merek pada basis data merek WIPO global. Jika Anda melakukan proyek atas nama perusahaan, maka departemen hukum dapat membantu Anda dalam hal ini .

Terakhir, lakukan pencarian Google cepat pada nama proyek Anda. Apakah orang akan dapat dengan mudah menemukan proyek Anda di sana? Atau mungkin sesuatu yang tidak diinginkan muncul pada permintaan ini?

Cara Anda menulis (dan kode) juga memengaruhi merek Anda!


Sepanjang kehidupan proyek, Anda akan banyak menulis: README, panduan, dokumen komunitas, jawaban atas pertanyaan, bahkan mungkin buletin dan milis.

Baik itu dokumentasi resmi atau pesan reguler, gaya tulisan Anda adalah bagian dari merek proyek. Pikirkan tentang cahaya di mana Anda melihat di depan penonton dan apakah Anda telah memilih nada yang tepat.
avatar , , . , , , , .
@janl, CouchDB, « Open Source»

Bahasa yang ramah dan sopan akan menciptakan suasana yang menyenangkan bagi peserta baru. Perhatikan juga kesederhanaan presentasi, karena bagi banyak pembaca, bahasa Inggris mungkin bukan asli.

Tidak hanya kata-kata yang Anda tulis, tetapi juga gaya kode dapat menjadi bagian dari merek proyek Anda. Angular dan jQuery adalah dua proyek sampel dengan gaya dan rekomendasi yang ketat.

Tidak perlu menulis panduan gaya ketika Anda baru memulai, dan dalam hal apa pun Anda mungkin ingin memasukkan gaya yang berbeda dalam proyek Anda. Tetapi Anda harus memahami sebelumnya bahwa gaya penulisan dan kode Anda akan menarik beberapa orang dan mendorong orang lain menjauh. Tahap awal proyek adalah kesempatan untuk menciptakan preseden dari mana proyek akan tumbuh dalam bentuk yang Anda inginkan.

Daftar periksa sebelum memulai


Apakah Anda siap untuk membuka proyek Anda? Berikut adalah daftar periksa untuk membantu Anda. Ketika Anda telah memeriksa semua item, klik "terbitkan" dan pujilah diri Anda.

Dokumentasi


  • Ada file LISENSI open source dalam proyek
  • Proyek ini memiliki dokumentasi dasar (README, CONTRIBUTING, CODE_OF_CONDUCT)
  • Namanya mudah diingat, memberikan gambaran tentang esensi proyek, tidak bertentangan dengan proyek yang ada dan tidak melanggar merek dagang.
  • Daftar masalah saat ini, terorganisir dengan baik, dan diberi label.

Kode


  • Proyek ini menggunakan konvensi kode yang disepakati dan nama fungsi / metode / variabel yang ramah
  • Kode ini jelas dikomentari, niat dan kasus khusus didokumentasikan.
  • Tidak ada data sensitif seperti kata sandi atau informasi non-publik lainnya - dalam sejarah revisi, masalah (masalah) dan permintaan revisi (tarik permintaan).

Orang-orang


Jika Anda seorang individu pribadi:

  • Anda berbicara dengan departemen hukum dan / atau memahami peraturan kekayaan intelektual perusahaan Anda dan kebijakan sumber terbuka (jika Anda bekerja di suatu tempat)

Jika Anda adalah badan hukum:

  • Anda berbicara dengan departemen hukum
  • Apakah Anda memiliki rencana pemasaran untuk meluncurkan dan mempromosikan proyek?
  • Seseorang telah ditunjuk bertanggung jawab untuk berinteraksi dengan komunitas: menjawab pertanyaan, memeriksa permintaan tarikan dan melampirkannya ke proyek
  • Setidaknya dua orang memiliki akses administratif ke proyek.

Anda berhasil!


Selamat telah membuka kode sumber untuk proyek pertama Anda! Terlepas dari hasilnya, bekerja dalam pandangan penuh orang adalah hadiah bagi komunitas. Setiap komit, komentar, dan permintaan revisi adalah kesempatan untuk belajar dan tumbuh untuk Anda dan orang lain.

More articles:


All Articles