Semua orang dapat berkontribusi ke OpenXLA, dan kami menghargai kontribusi semua orang. Ada beberapa cara untuk berkontribusi, termasuk:
Menjawab pertanyaan di forum diskusi OpenXLA (openxla-discuss)
Meningkatkan kualitas atau memperluas dokumentasi OpenXLA
Berkontribusi terhadap code base OpenXLA
Berkontribusi dengan salah satu cara di atas ke ekosistem library yang lebih luas yang dibangun di OpenXLA
Project OpenXLA mematuhi Pedoman Komunitas Open Source Google.
Sebelum memulai
Tanda tangani Perjanjian Lisensi Kontributor
Kontribusi ke project ini harus disertai dengan Perjanjian Lisensi Kontributor (CLA). Anda (atau perusahaan Anda) tetap memegang hak cipta atas kontribusi Anda. Tindakan ini hanya memberi kami izin untuk menggunakan dan mendistribusikan ulang kontribusi Anda sebagai bagian dari project.
Jika Anda atau perusahaan Anda saat ini telah menandatangani Google CLA (meskipun untuk project yang berbeda), Anda mungkin tidak perlu melakukannya lagi.
Buka <https://cla.developers.google.com/> untuk melihat perjanjian saat ini atau untuk menandatangani perjanjian baru.
Tinjau Kode Etik
Project ini mengikuti Kode Etik Tensorflow.
Proses kontribusi
Panduan Developer
Untuk mengetahui panduan cara menyiapkan lingkungan pengembangan OpenXLA, termasuk mendapatkan kode, mem-build-nya, menjalankan pengujian, dan mengirimkan perubahan, lihat Panduan developer.
Standar kode
Gaya coding: Kami mengikuti panduan gaya kode Google. Secara khusus, lihat panduan C/C++ dan Python. Semua kode yang dikirimkan harus benar-benar sesuai dengan panduan gaya ini.
Perubahan ringkas: Kami mengikuti praktik engineering Google. Secara khusus, harap ikuti panduan tentang cara menulis perubahan ringkas. Tindakan ini akan meningkatkan kecepatan penggabungan kode karena akan meningkatkan kemampuan peninjauan, dan mengurangi kemungkinan efek perubahan yang tidak disengaja. Bahkan jika Anda memiliki perubahan besar, ada banyak strategi untuk memecahnya menjadi perubahan inkremental.
Cakupan Pengujian: Semua perubahan harus menyertakan pengujian unit yang sesuai. Pengujian unit tidak boleh bergantung pada pengaturan waktu hardware tertentu (CPU, GPU, dll.), dan harus memanfaatkan tiruan dan palsu secara bebas untuk melakukan pengujian yang deterministik dan terfokus. Perubahan yang berupaya memperluas kode yang ada dan saat ini sulit diuji harus menghasilkan peningkatan yang sesuai pada kemampuan pengujian.
Semua perubahan harus menyertakan hasil tolok ukur yang sesuai juga dalam judul perubahan untuk memastikan manfaatnya dipahami dengan jelas.
Jika ragu dengan konvensi dalam kode, sebaiknya periksa kode yang sudah ada sebelumnya dan coba ikuti pola yang sudah ada di OpenXLA.
Tinjau Proses
Semua pengajuan, termasuk kiriman oleh anggota proyek, memerlukan peninjauan. Untuk tujuan ini, kami menggunakan permintaan pull GitHub. Lihat Bantuan GitHub untuk mengetahui informasi selengkapnya tentang cara menggunakan permintaan pull.
Kode harus mengikuti semua standar yang tercantum di atas sebelum ditinjau. Hal ini tidak bersifat opsional dan sangat penting bagi pengirim untuk memastikan bahwa kodenya sesuai sebelum meminta peninjauan untuk memastikan penerimaan perubahan secara tepat waktu.
Semua pengujian harus lulus. Jika Anda mendapati bahwa pengujian rusak dan masalah tersebut tidak terkait dengan lingkungan build atau perubahan Anda, hubungi pengelola.
Cobalah untuk menghindari {i>scope creep <i}selama proses peninjauan. Ini adalah tanggung jawab pengirim dan peninjau. Jika perubahan mulai menjadi terlalu besar, pertimbangkan untuk membaginya menjadi beberapa perubahan.
Sebelum digabungkan, perubahan akan menjalani pengujian internal yang menggunakan kode internal untuk Google dan vendor hardware lainnya. Hal ini berpotensi menambahkan langkah tambahan ke proses peninjauan jika ada kegagalan pada pengujian internal yang tidak terdeteksi oleh CI publik kami. Googler yang meninjau perubahan Anda akan mengomunikasikan setiap kegagalan uji internal dan menjelaskan apa yang perlu diperbaiki.
Pertanyaan umum (FAQ)
"Perubahan infrastruktur ini tidak terkait dengan PR saya. Mengapa saya harus melakukannya?"
Tim XLA tidak memiliki tim infrastruktur khusus, jadi semua terserah kita untuk membangun library helper dan menghindari utang teknis. Kami menganggapnya sebagai bagian rutin dari perubahan pada XLA, dan semua orang diharapkan untuk berpartisipasi. Kita biasanya membangun infrastruktur sesuai kebutuhan saat menulis kode.
Peninjau XLA mungkin meminta Anda untuk membangun beberapa infrastruktur (atau membuat perubahan besar pada PR) bersama dengan PR yang Anda tulis. Permintaan ini mungkin tampak tidak perlu atau ortogonal terhadap perubahan yang Anda coba buat. Hal ini mungkin karena ketidakcocokan antara ekspektasi Anda tentang jumlah infrastruktur yang perlu dibangun dan ekspektasi peninjau untuk hal yang sama.
Ketidakcocokan ekspektasi adalah hal yang wajar. Hal ini wajar jika Anda baru mengenal suatu project (dan hal ini kadang juga terjadi pada kami). Kemungkinan besar proyek yang Anda kerjakan sebelumnya memiliki ekspektasi yang berbeda. Itu juga tidak apa-apa dan diharapkan. Bukan berarti salah satu dari proyek ini memiliki pendekatan yang salah; keduanya hanya berbeda. Kami mengundang Anda untuk menerima permintaan infra bersama semua komentar ulasan lainnya sebagai kesempatan untuk mempelajari apa yang kami harapkan dalam project ini.
"Bisakah saya menangani komentar Anda pada PR mendatang?"
Pertanyaan yang sering diajukan sehubungan dengan permintaan infrastruktur (atau permintaan besar lainnya) dalam PR adalah apakah perubahan harus dibuat dalam PR asli atau tidak, atau apakah perubahan tersebut dapat dilakukan sebagai tindak lanjut dalam PR mendatang.
Secara umum, XLA tidak mengizinkan penulis PR untuk menangani komentar ulasan dengan PR tindak lanjut. Saat peninjau memutuskan bahwa ada hal yang perlu ditangani dalam PR tertentu, biasanya kami berharap penulis akan menanganinya dalam PR tersebut, meskipun hal yang diminta adalah perubahan yang besar. Standar ini berlaku secara eksternal dan juga secara internal di dalam Google.
Ada beberapa alasan mengapa XLA menggunakan pendekatan ini.
Kepercayaan: Mendapatkan kepercayaan dari pengulas merupakan komponen utama. Dalam project open source, kontributor dapat muncul atau menghilang kapan saja. Setelah kami menyetujui PR, peninjau tidak memiliki cara untuk memastikan bahwa tindak lanjut yang dijanjikan benar-benar selesai.
Dampak pada developer lain: Jika Anda telah mengirim PR yang menyentuh bagian tertentu dari XLA, kemungkinan besar orang lain akan melihat bagian yang sama. Jika kami menerima utang teknis di PR Anda, semua orang yang melihat file ini akan terpengaruh oleh utang ini hingga tindak lanjut dikirimkan.
Bandwidth peninjau: Menunda perubahan pada tindak lanjut akan menimbulkan beberapa biaya bagi peninjau kami yang sudah kelebihan beban. Peninjau mungkin akan melupakan tentang {i>PR <i}pertama sambil menunggu tindak lanjut, membuat {i>review<i} berikutnya lebih sulit. Peninjau juga harus melacak tindak lanjut yang diharapkan, memastikan hal itu benar-benar terjadi. Jika perubahan dapat dilakukan sehingga benar-benar ortogonal dengan PR asli sehingga beberapa peninjau lain dapat meninjaunya, masalah bandwidth akan berkurang. Berdasarkan pengalaman kami, hal ini jarang terjadi.