TensorFlow RFC işlemi

Her yeni TensorFlow özelliği, bir Yorum İsteği (RFC) olarak hayata başlar.

RFC, bir gereksinimi ve onu çözecek önerilen değişiklikleri açıklayan bir belgedir. Özellikle, RFC şunları yapacaktır:

• RFC şablonuna göre biçimlendirilmelidir.
• Community / rfcs dizinine bir çekme isteği olarak gönderilecektir.
• Kabulden önce tartışmaya ve gözden geçirme toplantısına tabi olun.

TensorFlow Yorum Talebinin (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

1. Bir RFC göndermeden önce, hedeflerinizi projeye katkıda bulunanlar ve geliştiricilerle tartışın ve erken geri bildirim alın. İlgili proje için geliştirici posta listesini kullanın (developer@tensorflow.org veya ilgili SIG için liste).

2. RFC'nizin taslağını oluşturun.

   • Tasarım inceleme kriterlerini okuyun
   • RFC şablonunu izleyin.
   • RFC dosyanızı YYYYMMDD-descriptive-name.md descriptive-name YYYYMMDD-descriptive-name.md ; burada YYYYMMDD , gönderim tarihidir ve descriptive-name , RFC'nizin başlığıyla ilişkilidir. (Örneğin, 20180531-parallel-widgets.md başlığı Parallel Widgets API ise , 20180531-parallel-widgets.md dosya 20180531-parallel-widgets.md kullanabilirsiniz.
   • Resimleriniz veya diğer yardımcı dosyalarınız varsa, bu dosyaların saklanacağı YYYYMMDD-descriptive-name biçiminde bir dizin oluşturun.

   RFC taslağını yazdıktan sonra, göndermeden önce geliştiricilerden ve katkıda bulunanlardan geri bildirim alın.

   Uygulama kodu yazmak bir gereklilik değildir, ancak tasarım tartışmalarına yardımcı olabilir.

3. Bir sponsor bulun.

   • Sponsor, projenin koruyucusu olmalıdır.
   • PR'yi yayınlamadan önce RFC'deki sponsoru tanımlayın.

   Bir sponsor olmadan RFC verebilirsiniz, ancak hiçbir sponsor hala PR gönderme izleyen bir ay içinde, eğer kapalı olacaktır.

4. RFC'nizi bir çekme isteği olarak tensorflow / community / rfcs'ye gönderin .

   Markdown kullanarak, başlık tablosunu ve Hedef bölümünün içeriğini çekme isteğinizin açıklamasına ekleyin. Bir örnek için lütfen bu RFC örneğine bakın. Ortak yazarların, gözden geçirenlerin ve sponsorların GitHub tutamaçlarını dahil edin.

   PR'nin üst kısmında, yorum süresinin ne kadar süreceğini belirleyin. Bu, PR'nin yayınlanmasından itibaren en az iki hafta olmalıdır.

5. Geliştirici posta listesine kısa bir açıklama, PR bağlantısı ve inceleme isteği içeren bir e-posta gönderin. Bu örnekte görebileceğiniz gibi, önceki postaların biçimini izleyin.

6. Sponsor, RFC PR yayınlandıktan sonra en geç iki hafta içinde bir gözden geçirme komitesi toplantısı talep edecektir. Tartışma canlıysa, incelemeye gitmeden önce çözülmesini bekleyin. Gözden geçirme toplantısının amacı küçük sorunları çözmektir; Önceden önemli konularda fikir birliğine varılmalıdır.

7. 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ılacaktır.

RFC katılımcıları

Birçok kişi RFC sürecine dahil olur:

• RFC yazarı - RFC yazan ve süreç boyunca onu savunmaya kararlı bir veya daha fazla topluluk üyesi

• RFC sponsoru - RFC'ye sponsor olan ve onu RFC inceleme sürecinde 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şılamayacağı konusunda geri bildirim sağlayarak yardımcı olabilir.

RFC sponsorları

Sponsor, RFC sürecinin mümkün olan en iyi sonucunu sağlamaktan sorumlu bir proje geliştiricisidir. Bu içerir:

• Önerilen tasarımı savunmak.
• Mevcut tasarım ve stil kurallarına uyması için RFC'ye rehberlik etmek.
• İnceleme komitesine verimli bir fikir birliğine varması için rehberlik etmek.
• İnceleme komitesi tarafından değişiklik talep edilirse, bunların yapıldığından emin olun ve komite üyelerinden daha sonra onay alın.
• RFC uygulamaya geçerse:
  • Önerilen uygulamanın sağlanması tasarıma bağlı kalır.
  • Başarılı bir arazi uygulaması için uygun taraflarla koordinasyon sağlayın.

RFC inceleme komiteleri

İnceleme komitesi, değişiklikleri onaylama, reddetme veya talep etme konusunda fikir birliği temelinde karar verir. Şunlardan sorumludurlar:

• Kamuya açık geri bildirimlerin önemli öğelerinin hesaba katılmasının sağlanması.
• PR'a yorum olarak toplantı notlarını ekleme.
• Kararları için gerekçeler sunmak.

Bir gözden geçirme komitesinin yapısı, her projenin belirli yönetim tarzına ve liderliğine göre değişebilir. Çekirdek TensorFlow için komite, ilgili alan alanında uzmanlığa sahip TensorFlow projesine katkıda bulunanlardan oluşacaktır.

Topluluk üyeleri ve RFC süreci

RFC'lerin amacı, topluluğun TensorFlow'daki yeni değişikliklerle iyi temsil edilmesini ve sunulmasını sağlamaktır. Sonuçla ilgilendikleri RFC'lerin gözden geçirilmesine katılmak topluluk üyelerinin sorumluluğundadır.

Bir RFC ile ilgilenen topluluk üyeleri şunları yapmalıdır:

• Değerlendirmeye yeterli zaman ayırmak için mümkün olan en kısa sürede geri bildirim sağlayın .
• Geri bildirim sağlamadan önce RFC'leri iyice okuyun .
• Sivil ve yapıcı olun.

Yeni özelliklerin uygulanması

Bir RFC onaylandıktan sonra uygulama başlayabilir.

Bir RFC uygulamak için yeni kod üzerinde çalışıyorsanız:

• RFC'de onaylanan özelliği ve tasarımı anladığınızdan emin olun. İşe 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 izleyin
• İlgili API belgelerini ekleyin veya güncelleyin. Yeni belgelerde RFC'ye bakın.
• Katkıda bulunduğunuz proje deposundaki CONTRIBUTING.md dosyası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 herkesi cesaretlendirip kutlasak da, RFC kabulü için çıta kasıtlı olarak yüksek tutulur. Aşağıdaki aşamalardan herhangi birinde yeni bir özellik reddedilebilir veya önemli revizyona ihtiyaç duyabilir:

• İlgili posta listesindeki ilk tasarım konuşmaları.
• Bir sponsor bulamama.
• Geri bildirim aşamasında kritik itirazlar.
• Tasarım incelemesi sırasında fikir birliğine varılamama.
• Uygulama sırasında ortaya çıkan endişeler (örneğin: geriye dönük uyumluluğun sağlanamaması, bakımla ilgili endişeler).

Bu süreç iyi çalışıyorsa, RFC'lerin daha sonraki aşamalardan ziyade önceki 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 işlemle ilgili herhangi bir sorunuz varsa, geliştiricilerin posta listesinde sormaktan veya tensorflow / toplulukta bir sorun bildirmekten çekinmeyin .