Her yeni TensorFlow özelliği, Yorum İsteği (RFC) olarak hayata başlar.
RFC, bir gereksinimi ve bu gereksinimi çözecek önerilen değişiklikleri açıklayan bir belgedir. RFC özellikle şunları yapacaktır:
- RFC şablonuna göre biçimlendirilmelidir.
- Topluluk/rfcs dizinine çekme isteği olarak gönderilmelidir.
- Kabul edilmeden önce tartışmaya ve inceleme toplantısına tabi olun.
TensorFlow Yorum İsteğinin (RFC) amacı, paydaşlardan ve uzmanlardan geri bildirim alarak ve tasarım değişikliklerini geniş bir şekilde ileterek TensorFlow topluluğunu geliştirme sürecine dahil etmektir.
RFC nasıl gönderilir?
Bir RFC göndermeden önce hedeflerinizi projeye katkıda bulunanlar ve bakım sağlayıcılarla tartışın ve erken geri bildirim alın. İlgili proje için geliştirici posta listesini kullanın (developers@tensorflow.org veya ilgili SIG'nin listesi).
RFC'nizin taslağını oluşturun.
- Tasarım inceleme kriterlerini okuyun
- RFC şablonunu takip edin.
- RFC dosyanızı
YYYYMMDD-descriptive-name.mdolarak adlandırın; buradaYYYYMMDDgönderim tarihidir vedescriptive-nameRFC'nizin başlığıyla ilgilidir. (Örneğin, RFC'nizin adı Parallel Widgets API ise,20180531-parallel-widgets.mddosya adını kullanabilirsiniz. - Resimleriniz veya başka yardımcı dosyalarınız varsa, bu dosyaların depolanacağı
YYYYMMDD-descriptive-namebiçiminde bir dizin oluşturun.
RFC taslağını yazdıktan sonra, göndermeden önce bakımcılardan ve katkıda bulunanlardan geri bildirim alın.
Uygulama kodunun yazılması bir gereklilik değildir ancak tasarım tartışmalarına yardımcı olabilir.
Bir sponsor bulun.
- Sponsor projenin sürdürücüsü olmalıdır.
- Halkla İlişkileri yayınlamadan önce RFC'de sponsoru tanımlayın.
Sponsor olmadan bir RFC yayınlayabilirsiniz , ancak PR yayınlandıktan sonraki bir ay içinde hala sponsor yoksa kapatılacaktır.
RFC'nizi tensorflow/community/rfcs'ye çekme isteği olarak gönderin.
Markdown'ı kullanarak başlık tablosunu ve Hedef bölümünün içeriğini çekme isteğinizin yorumuna ekleyin. Bir örnek için lütfen bu örnek RFC'ye bakın. Ortak yazarların, gözden geçirenlerin ve sponsorların GitHub tanıtıcılarını ekleyin.
PR'nin üst kısmında yorum süresinin ne kadar süreceğini belirtin. Bu, PR'nin yayınlanmasından itibaren en az iki hafta olmalıdır.
Kısa bir açıklama, PR bağlantısı ve inceleme talebiyle birlikte geliştirici posta listesine e-posta gönderin. Bu örnekte görebileceğiniz gibi, önceki postaların formatını takip edin.
Sponsor, RFC PR'nin yayınlanmasından en geç iki hafta sonra bir inceleme komitesi toplantısı talep edecektir. Tartışma canlıysa, incelemeye gitmeden önce kararlaşana kadar bekleyin. İnceleme toplantısının amacı küçük sorunları çözmektir; Önemli konularda önceden fikir birliğine varılmalıdır.
Toplantı RFC'yi onaylayabilir, reddedebilir veya yeniden değerlendirilmeden önce değişiklik yapılmasını gerektirebilir. Onaylanan RFC'ler topluluk/rfcs ile birleştirilecek ve reddedilen RFC'lerin PR'leri kapatılacak.
RFC katılımcıları
Birçok kişi RFC sürecine dahil olur:
RFC yazarı — RFC yazan ve süreç boyunca RFC'yi desteklemeye kararlı bir veya daha fazla topluluk üyesi
RFC sponsoru — RFC'ye sponsor olan ve onu RFC inceleme süreci boyunca yönlendirecek bir bakımcı
inceleme komitesi — RFC'nin benimsenmesini tavsiye etme sorumluluğuna sahip bir grup bakımcı
Herhangi bir topluluk üyesi, RFC'nin ihtiyaçlarını karşılayıp karşılayamayacağı konusunda geri bildirimde bulunarak yardımcı olabilir.
RFC sponsorları
Sponsor, RFC sürecinin mümkün olan en iyi sonucunu sağlamaktan sorumlu olan proje yürütücüsüdür. Bu içerir:
- Önerilen tasarımın savunulması.
- RFC'nin mevcut tasarım ve stil kurallarına uymasına rehberlik etmek.
- Verimli bir fikir birliğine varmak için inceleme komitesine rehberlik etmek.
- İnceleme komitesi tarafından değişiklik talep edilirse, bunların yapıldığından emin olun ve daha sonra komite üyelerinden onay alın.
- RFC uygulamaya geçerse:
- Önerilen uygulamanın tasarıma bağlı kalmasının sağlanması.
- Başarılı bir arazi uygulaması için uygun taraflarla koordinasyon sağlayın.
RFC inceleme komiteleri
İnceleme komitesi, onay, reddetme veya değişiklik talep etme konusunda fikir birliğine dayalı olarak karar verir. Şunlardan sorumludurlar:
- Kamuoyunun geri bildirimlerinin önemli öğelerinin dikkate alınmasının sağlanması.
- Toplantı notlarını PR'a yorum olarak eklemek.
- Kararlarının gerekçelerini sunmak.
İnceleme komitesinin yapısı, her projenin yönetim tarzına ve liderliğine göre değişebilir. Temel TensorFlow için komite, ilgili alan alanında uzmanlığa sahip TensorFlow projesine katkıda bulunan kişilerden oluşacaktır.
Topluluk üyeleri ve RFC süreci
RFC'lerin amacı, topluluğun iyi temsil edilmesini ve TensorFlow'daki yeni değişikliklerle hizmet verilmesini sağlamaktır. Sonuçla ilgilendikleri RFC'lerin incelenmesine katılmak topluluk üyelerinin sorumluluğundadır.
RFC ile ilgilenen topluluk üyelerinin şunları yapması gerekir:
- Değerlendirmeye yeterli zaman tanımak için mümkün olan en kısa sürede geri bildirim sağlayın .
- Geri bildirimde bulunmadan önce RFC'leri iyice okuyun .
- Medeni ve yapıcı olun.
Yeni özelliklerin uygulanması
RFC onaylandıktan sonra uygulama başlayabilir.
RFC uygulamak için yeni kod üzerinde çalışıyorsanız:
- RFC'de onaylanan özelliği ve tasarımı anladığınızdan emin olun. Çalışmaya başlamadan önce sorular sorun ve yaklaşımı tartışın.
- Yeni özellikler, özelliğin beklendiği gibi çalıştığını doğrulayan yeni birim testleri içermelidir. Kodu yazmadan önce bu testleri yazmak iyi bir fikirdir.
- TensorFlow Kod Stil Kılavuzunu Takip Edin
- İlgili API belgelerini ekleyin veya güncelleyin. Yeni belgelerdeki RFC'ye bakın.
- Katkıda bulunduğunuz proje deposundaki
CONTRIBUTING.mddosyasında belirtilen diğer yönergeleri izleyin. - Kodunuzu göndermeden önce birim testleri çalıştırın.
- Yeni kodu başarıyla almak için RFC sponsoruyla birlikte çalışın.
Çıtayı yüksek tutmak
Katkıda bulunan her kişiyi teşvik edip kutlarken, RFC kabul çıtası kasıtlı olarak yüksek tutuluyor. Yeni bir özellik aşağıdaki aşamalardan herhangi birinde reddedilebilir veya önemli bir revizyona ihtiyaç duyulabilir:
- İlgili e-posta listesindeki ilk tasarım görüşmeleri.
- Sponsor bulunamaması.
- Geri bildirim aşamasında kritik itirazlar.
- Tasarım incelemesi sırasında fikir birliğine varılamaması.
- Uygulama sırasında dile getirilen endişeler (örneğin: geriye dönük uyumluluk sağlanamaması, bakımla ilgili endişeler).
Bu süreç iyi çalışıyorsa, RFC'lerin daha sonraki aşamalardan ziyade daha erken aşamalarda başarısız olması beklenir. Onaylanmış bir RFC, uygulama taahhüdünün garantisi değildir ve önerilen bir RFC uygulamasının kabulü yine de olağan kod inceleme sürecine tabidir.
Bu süreçle ilgili herhangi bir sorunuz varsa geliştiricilerin e-posta listesine soru sormaktan veya tensorflow/community'de sorun bildirmekten çekinmeyin.