[ English | Indonesia | 한국어 (대한민국) | español (México) | English (United Kingdom) | Deutsch | 中文 (简体, 中国) ]

Menyumbang Panduan Organisasi

Apa itu Panduan Organisasi yang Berkontribusi?

Panduan yang menguraikan persyaratan dasar dan rekomendasi untuk karyawan (employee) yang ingin berkontribusi ke OpenStack.

Rekomendasi

Keterlibatan Pengembang

Mengapa kita perlu mengirim orang teknis ke komunitas?

Dengan orang-orang teknis di komunitas, Anda akan lebih mudah memicu tugas pengembangan atau diskusi di komunitas untuk mendapatkan peluang terbaik untuk berintegrasi dengan rencana bisnis / produk Anda.

Anda membutuhkan orang untuk mempertahankan produk Anda, sama seperti masyarakat membutuhkan orang untuk memelihara proyek di setiap siklus rilis untuk menjaga pengembangan terus berjalan.

Ada beberapa peluang dalam setiap siklus rilis untuk memicu tugas pengembangan di komunitas. Membawa lebih banyak keputusan teknis kepada komunitas akan membantu Anda mendapatkan lebih banyak umpan balik dan panduan dari pengembang dan operator secara global. Juga, bantu mereka membuat sasaran siklus yang lebih baik yang juga bermanfaat bagi Anda.

Berapa banyak orang yang harus Anda kirim?

Tergantung pada rencana Anda sendiri, tetapi cobalah untuk mencakup berbagai layanan proyek yang Anda gunakan atau rencanakan untuk digunakan untuk layanan Anda.

Terlibat dalam proyek-proyek ini berarti Anda dapat:

  • Pantau kesehatan proyek.

  • Terlibat dalam desain dan arah proyek.

  • Terlibat dalam dan membentuk diskusi implementasi.

  • Hindari membawa patch hilir (downstream patch).

Semakin banyak orang yang bekerja di hulu, semakin baik perhatian fitur Anda. Memberikan lebih banyak pengulas pasti akan membantu menggabungkan implementasi Anda dengan proyek. Ulasan kode adalah hambatan untuk pendaratan patch (landing patch), lebih banyak ulasan bagus kode lebih cepat dapat mendarat.

Berapa lama mereka di sana?

Jawaban yang ideal adalah memberi orang-orang teknis persentase waktu mereka sebanyak yang Anda bisa berikan, dan selama mungkin.

Jika perusahaan Anda cukup besar untuk memiliki pilihan, memberi insinyur lebih banyak waktu untuk mengkhususkan dan berkonsentrasi pada bidang-bidang tertentu cenderung lebih efisien daripada meminta insinyur terus-menerus mengubah konteks karena mereka harus mengenakan banyak topi (wear multiple hats).

Memiliki insinyur yang menghabiskan lebih banyak waktu di hulu membantu semua orang dengan memberikan masukan dan umpan balik yang berkelanjutan untuk tugas-tugas yang Anda tetapkan sebagai prioritas tinggi. Namun lebih dari itu, OpenStack mengandalkan peer review <https://governance.openstack.org/tc/reference/principles.html#we-value-constructive-peer-review> _. Dari kode pendaratan (landing code) hingga kepemimpinannya (its governance), untuk berfungsi, proyek ini membutuhkan orang-orang di komunitas yang meninjau.

Lebih jauh, memiliki insinyur dalam komunitas jangka panjang juga akan membuat perusahaan berada di depan kurva karena mereka tertanam dan terlibat dalam komunitas daripada muncul dan keluar.

Sederhananya, semakin banyak investasi perusahaan di masyarakat, semakin besar kemungkinan mereka mendapatkan tempat pengaruh.

Mengapa Anda perlu melakukan sinkronisasi dengan komunitas teknis?

Komunitas hulu dipenuhi oleh orang-orang yang bersemangat dan cerdas yang semuanya menginginkan yang terbaik untuk proyek ini. Terlibat berarti Anda dapat membantu membentuk dan meningkatkan proyek.

Lebih baik lagi, daripada memanipulasi (forking) atau menambahkan patch hilir dalam produk Anda sendiri yang perlu Anda bawa, dukung, dan pelihara, yang bisa sangat mahal. Anda bisa mendorongnya ke atas dan mendapatkan manfaat dari seluruh komunitas pengembang yang meningkatkan dan mempertahankannya bersama Anda. Secara efektif menghapus sebagian besar, jika tidak semua biaya tambahan dan risiko mempertahankannya di hilir.

Ini juga akan diuji lebih baik daripada apa pun yang dikembangkan secara internal karena itu akan diuji oleh komunitas dan digunakan lebih luas daripada hanya pelanggan Anda.

Semua pengembang tambahan ini berarti lebih banyak perhatian pada pencarian kode, perbaikan, dan peningkatan kode. Ini berarti memiliki komunitas pengembang yang membantu dalam pengembangan dan peningkatan infrastruktur Anda sendiri.

Ingat banyak tangan membuat pekerjaan ringan.

Teknis

Kode

Internet Relay Chat (IRC)

  • Access to chat.oftc.net port 6697/tcp (IRC communication)

    • Jika menggunakan IRC bouncer port 443,, ke bouncer, dapat digunakan.

    • Lihat Pengaturan IRC.

Saran

Ada layanan IRC berbasis browser, seperti irccloud, yang akan membuat pengguna tetap terhubung dan menggunakan standard HTTPS (443/tcp).

Jika konektivitas ke port tertentu dikunci atau ada masalah, server SOCKS dapat digunakan untuk menyediakan akses.

Pertimbangan Email

  • Kemampuan menerima E-mail dari dan mengirim E-mail ke alamat di lists.openstack.org (milis)

    • Mailing list dapat berupa traffic tinggi, pertimbangkan untuk mengizinkan penggunaan layanan mail eksternal untuk menangani intake dari mailing list komunitas.

  • Pertimbangkan pengecualian untuk footer email standar pada email yang dikirim ke milis komunitas

  • Lihat Mailing Lists (ML).

Pertimbangan Sistem Operasi (OS)

Ada banyak komponen dan proyek yang berkaitan dengan menjalankan dan mengembangkan OpenStack yang semuanya berjalan di atas Linux. Jadi pengembang perlu:

  • Izin untuk menjalankan Linux dan menginstal perangkat lunak open source lainnya pada perangkat keras yang disediakan majikan.

Acara Teknis

Ada sejumlah acara teknis yang diadakan di mana komunitas, proyek, dan perencanaan serta jejaring lintas proyek terjadi secara langsung. Meskipun perencanaan dan jaringan ini terjadi secara online di luar acara ini, Anda harus mempertimbangkan untuk mengirimkan pengembang untuk terlibat.

Beberapa acara teknis meliputi:

  • Project Technical Gatherings (PTGs)

  • Summits dan Forums

  • Pertemuan operator

Untuk informasi lebih lanjut tentang acara tersebut, lihat: https://www.openstack.org/community/events/

Non-Teknis

OpenStack adalah komunitas global. Interaksi dengan komunitas berarti bekerja dan berinteraksi dengan orang-orang dari zona waktu dan budaya yang berbeda, karena ada rekomendasi non-teknis lainnya yang membantu memfasilitasi keterlibatan dalam komunitas OpenStack, ini dapat dipecah menjadi tiga bidang: komunikasi, budaya dan harapan.

Komunikasi

Menjadi komunitas global, dengan anggota dari seluruh dunia tersedia untuk sesekali bekerja, berbicara, atau bertemu di luar jam kerja biasa adalah yang terpenting.

Beberapa media komunikasi yang tidak sinkron, seperti email dan gerrit, sangat banyak digunakan, tetapi kadang-kadang diskusi ini dapat dipercepat dengan menggunakan media yang lebih sinkron seperti:

  • Percakapan IRC

    • Bekerja jika pengembang dari bagian lain dunia dapat berarti mencari waktu untuk mengobrol di IRC ketika semua pihak tersedia.

    • Demikian juga, ketika meninjau patch, berbicara dengan pembuat patch di saluran dapat sangat mempercepat ulasan terutama untuk patch yang lebih rumit.

  • Pertemuan IRC

    • Semua proyek memiliki pertemuan rutin di IRC. Sebagian besar pertemuan ini bergantian antara dua zona waktu yang berbeda. Namun terkadang, menguntungkan jika semua pengembang mengerjakan fitur atau proyek tertentu berada di satu tempat pada saat yang sama.

  • Lain

    • Proyek lain mungkin memilih cara komunikasi lain tergantung pada pengembang yang dimaksud. Tetapi transparansi itu penting. Apa pun yang didiskusikan harus dicatat atau di minute untuk dilihat oleh sisa (rest) proyek OpenStack dan dunia.

Budaya Masyarakat

  • Timezones

    • Komunitas OpenStack tersebar di berbagai zona waktu, jadi selalu coba transparan kepada komunitas yang lebih besar dan jika menggunakan sistem komunikasi sinkron untuk membuat keputusan fitur/proyek, pastikan Anda memungkinkan input asinkron dari anggota di zona waktu lain.

    • Zona waktu yang berbeda berarti budaya yang berbeda, jadi peka terhadap perbedaan budaya ini. Salah satu contohnya adalah memberi kesempatan bagi penutur bahasa Inggris non-native untuk berpikir dan berbicara dan jika menggunakan media suara, tolong pelan-pelan.

  • Judul yang dipegang oleh anggota masyarakat bersifat sementara dan kegiatan tidak benar-benar terkait dengan judul.

    • Semua orang bersama-sama dan bekerja untuk OpenStack yang lebih baik.

    • Setiap orang yang memegang gelar, seperti PTL atau bagian dari komite teknis dipilih. Jadi, gelar bersifat sementara.

  • Pencabangan (fork) adalah buruk, berkontribusi di hulu jauh lebih baik.

    • mengutip artikel tentang bagaimana memelihara fork (pencabangan) pada umumnya merupakan proses yang mahal dan menyakitkan (melalui tautan untuk membaca lebih lanjut tentang keterlibatan komunitas open source yang efektif)

  • Komunitas ini tidak secara resmi mendukung Stackalytics, layanan pengumpulan statistik kontribusi yang diselenggarakan oleh Mirantis. Komunitas tidak mendorong upaya untuk meningkatkan statistik kontribusi seseorang dengan mengusulkan sejumlah besar komitmen bernilai rendah atau memilih sejumlah besar proposal perubahan tanpa memberikan ulasan yang matang. Kegiatan seperti ini tampak bagi anggota komunitas lainnya sebagai upaya untuk mempermainkan sistem dan kontributor yang terlibat dalam hal ini akan sering kehilangan kredibilitas untuk diri mereka sendiri dan pemberi kerja mereka di komunitas. Sebaliknya, kontributor harus mencoba untuk terlibat secara mendalam dengan satu proyek atau sejumlah kecil proyek untuk mendapatkan pemahaman tentang komponen perangkat lunak dan membangun hubungan dengan kontributor lain untuk proyek itu.

  • Memfokuskan staf pada area proyek tertentu, atau ke arah tujuan tertentu lebih efektif daripada meminta mereka untuk melacak aktivitas pada banyak proyek.

Harapan

  • Izin untuk menyetujui OpenStack ICLA (wajib)

  • Izin untuk sesekali bekerja di luar jam kerja biasa

  • Suatu proses untuk menghapus kontribusi dari sudut pandang IP

  • Izin dan anggaran untuk mengirim kontributor ke acara

  • Harapan bepergian ke setidaknya beberapa acara - tidak harus semuanya

    • Harus siap untuk menulis surat izin/surat visa/surat yang diperlukan untuk mendapatkan visa

    • Surat-surat/keputusan yang diambil dalam perjalanan harus diberikan, idealnya berminggu-minggu atau lebih, sebelumnya

    • Izin untuk menyetujui persyaratan menjadi Anggota Perorangan Open Infrastructure Foundation

  • Pertimbangkan mendaftar sebagai anggota organisasi yang berkontribusi