Herkes OpenXLA'ya katkıda bulunabilir. Herkesin katkılarına değer veririz. Katkıda bulunmanın birkaç yolu vardır:
OpenXLA'nın tartışma forumlarındaki soruları yanıtlama (openxla-discuss)
OpenXLA belgelerini geliştirme veya genişletme
OpenXLA'nın kod tabanına katkıda bulunma
OpenXLA üzerinde oluşturulan daha geniş kitaplık ekosistemine yukarıdaki yöntemlerden herhangi birini kullanarak katkıda bulunma
OpenXLA projesi, Google’ın Açık Kaynak Topluluk Kuralları'na uygundur.
Başlamadan önce
Katkıda Bulunan Lisans Sözleşmesi'ni imzalayın
Bu projeye yapılan katkılar, Katkıda Bulunan Lisans Sözleşmesi (CLA) ile birlikte sağlanmalıdır. Katkınızın telif hakkı size (veya işvereninize) aittir; bu, bize katkılarınızı projenin bir parçası olarak kullanma ve yeniden dağıtma izni verir.
Siz veya şu anki işvereniniz Google CLA'yı daha önce imzaladıysanız (farklı bir proje için olsa bile) muhtemelen tekrar imzalamanız gerekmez.
Mevcut sözleşmelerinizi görmek veya yeni bir sözleşme imzalamak için <https://cla.developers.google.com/> adresini ziyaret edin.
Davranış Kurallarını İnceleyin
Bu proje, Tensorflow'un Davranış Kuralları'na uygundur.
Katkı süreci
Geliştirici Kılavuzu
Kod alma, geliştirme, test çalıştırma ve değişiklikleri gönderme dahil olmak üzere, OpenXLA için geliştirme ortamı oluşturma konusunda bir kılavuz için lütfen Geliştirici kılavuzuna bakın.
Kod standartları
Kodlama stili: Google'ın kod stili kılavuzunu uygularız. Özellikle C/C++ ve Python rehberlerini inceleyin. Gönderilen tüm kodlar bu stil kılavuzlarına kesinlikle uygun olmalıdır.
Kompakt değişiklikler: Google'ın mühendislik uygulamalarını izliyoruz. Lütfen özellikle kompakt değişiklikleri yazma rehberini inceleyin. Bu yöntem, incelenebilirliği artırmak için kodunuzu birleştirme hızınızı önemli ölçüde artırır ve değişikliğin kasıtsız yan etkilerinin görülme olasılığını azaltır. Büyük bir değişikliğiniz olsa bile, bunu daha büyük değişikliklere bölmek için uygulayabileceğiniz birçok strateji vardır.
Test Kapsamı: Tüm değişiklikler uygun birim testlerini içermelidir. Birim testleri belirli donanım (CPU, GPU vb.) zamanlamalarına bağlı olmamalı ve belirleyici ve odaklı testler yapmak için taklit ve sahtelerden serbest bir şekilde yararlanılmalıdır. Şu anda test edilmesi zor olan mevcut kodun kapsamını genişletmek isteyen değişikliklerin test edilebilirlik açısından uygun iyileştirmeleri yapması gerekir.
Faydaların net bir şekilde anlaşılmasını sağlamak için tüm değişiklikler, değişiklik başlığında uygun karşılaştırma sonuçlarını da içermelidir.
Kod içindeki kurallar konusunda şüpheye düşerseniz önceden var olan kodu incelemek ve OpenXLA'da halihazırda bulunan kalıpları izlemeye çalışmak her zaman iyi bir fikirdir.
İnceleme Süreci
Proje üyelerinin gönderdiği gönderimler de dahil olmak üzere tüm gönderimlerin incelenmesi gerekir. GitHub pull isteklerini bu amaçla kullanırız. Pull isteklerinin kullanımı hakkında daha fazla bilgi için GitHub Yardımı'na bakın.
Kod, incelemeden önce yukarıda listelenen tüm standartlara uygun olmalıdır. Bunlar isteğe bağlı değildir ve gönderenin, değişikliklerin zamanında kabul edilmesini sağlamak için inceleme isteğinde bulunmadan önce kodunun uygunluğunu sağlaması çok önemlidir.
Tüm testler başarılı olmalıdır. Bir testte hata olduğunu tespit ederseniz ve sorunun derleme ortamınızla ya da yaptığınız değişikliklerle ilgili olmadığını fark ederseniz lütfen destekleyicilerle iletişime geçin.
İnceleme süreci sırasında kapsam kaymasından kaçınmaya çalışın. Bu sorumluluk hem gönderenin hem de inceleyenin sorumluluğundadır. Bir değişiklik fazla büyürse bunu birden fazla değişikliğe bölebilirsiniz.
Bir değişiklik birleştirilmeden önce, Google ve diğer donanım tedarikçi firmalarına ait dahili kodları kullanan dahili testlerden geçer. Bu, dahili testlerde herkese açık CI'mızın yakalayamadığı hatalar olursa inceleme sürecine ekstra adımlar ekleyebilir. Değişikliğinizi inceleyen Google çalışanı dahili test hatalarını bildirir ve nelerin düzeltilmesi gerektiğini açıklar.
Sık sorulan sorular (SSS)
"Bu altyapı değişikliği benim halkla ilişkiler ile ilgili değil. Bunu neden yapmalıyım?"
XLA ekibinin özel bir altyapı ekibi yoktur, bu nedenle yardımcı kitaplıklar oluşturmak ve teknik borçlardan kaçınmak hepimizin görevidir. Bunu, XLA'da değişiklikler yapmanın düzenli bir parçası olarak görüyoruz ve herkesin bu sürece katılması beklenmektedir. Genellikle kod yazarken altyapıyı gereken şekilde oluştururuz.
XLA incelemecileri, yazdığınız bir PR ile birlikte bazı altyapılar oluşturmanızı (veya bir halkla ilişkilerde büyük bir değişiklik yapmanızı) isteyebilir. Bu istek, yapmaya çalıştığınız değişiklik açısından gereksiz veya dikey görünebilir. Bunun nedeni muhtemelen ne kadar altyapı oluşturmanız gerektiği konusundaki beklentilerinizle incelemecinin aynı şekilde altyapı oluşturma konusundaki beklentileri arasındaki uyumsuzluktur.
Beklentiler arasında uyuşmazlık olması normaldir. Bir projeye yeni katıldığınızda (hatta bazen eski şapkalarda bile olur) bu beklenen bir durumdur. Geçmişte üzerinde çalıştığınız projelerin beklentileri farklı olabilir. Bu da olur ve beklenir. Bu, söz konusu projelerden birinin yanlış yaklaşıma sahip olduğu anlamına gelmez, sadece birbirinden farklıdır. Bu projeden neler beklediğimizi öğrenmeniz için sizi diğer tüm inceleme yorumlarının yanı sıra alt altyapı taleplerine katılmaya davet ediyoruz.
"Gelecekteki bir halkla ilişkiler toplantısında yorumunuzu ele alabilir miyim?"
PR'lerde altyapı istekleri (veya diğer büyük talepler) ile ilgili sık sorulan sorulardan biri, değişikliğin orijinal PR'de yapılması gerekip gerekmediği veya gelecekteki bir halkla ilişkilerde takip olarak yapılıp yapılamayacağıdır.
Genel olarak, XLA, PR yazarlarının yorum yorumlarını takip PR ile ele almasına izin vermez. Bir incelemeci, belirli bir halkla ilişkilerde bir şeyin ele alınması gerektiğine karar verdiğinde, talep büyük bir değişiklik olsa bile genellikle yazarların bu halkla ilişkilerde bu konuyu ele almasını bekleriz. Bu standart, hem harici hem de Google içinde geçerlidir.
XLA'nın bu yaklaşımı benimsemesinin birkaç nedeni vardır.
Güven: Yorumcunun güvenini kazanmış olmak temel bileşenlerden biridir. Açık kaynak projelerde, katkıda bulunanlar diledikleri zaman görünebilir veya kaybolabilir. Halkla ilişkiler (PR) onaylandıktan sonra, incelemeciler sözünü edilen herhangi bir takip işleminin gerçekleştirildiğinden emin olamazlar.
Diğer geliştiriciler üzerindeki etkisi: XLA'nın belirli bir bölümüne temas eden bir halkla ilişkiler gönderdiyseniz, başkalarının da aynı bölüme bakma olasılığı yüksektir. Halkla İlişkilerinizde teknik borcu kabul edersek, durumu takip edene kadar bu dosyaya bakan herkes bu borçtan etkilenecektir.
İncelemeci bant genişliği: Bir takip değişikliğinin ertelenmesi, aşırı yüklenmiş inceleme uzmanlarımıza birden fazla maliyet getirir. İnceleme ekibi takip yanıtını beklerken ilk halkla ilişkiler ekibinin neyle ilgili olduğunu muhtemelen unutur. Bu da bir sonraki incelemeyi zorlaştırır. Ayrıca incelemeciler beklenen takipleri takip ederek bunların gerçekten gerçekleştiğinden emin olmalıdır. Değişiklik, orijinal halkla ilişkilere tamamen dik olacak şekilde yapılabilir ve böylece başka bir inceleme uzmanı tarafından da incelenebilirse bant genişliği sorun teşkil etmeyecektir. Deneyimlerimize göre, böyle bir durum çok nadir yaşanır.