FreedomBox Topluluk Yönetimi
Topluluğumuz Hakkında
FreedomBox yazılım projesi, yarı zamanlı gönüllüler ve tam zamanlı katılımcılar içeren bir topluluk tarafından yönetilmektedir. Yönetimde, yazılı davranış kurallarımıza ve karşılıklı olarak uygulanan standartlarımıza güveniriz. Topluluk, açık tartışma ve fikir birliği yoluyla kararlar almayı hedefler. Anlaşmazlık durumlarında, topluluk bir çözüm bulana kadar tartışır veya tartışmayı ertelemeyi kabul eder. Seçkin sayıda geliştiricimiz birleştirme isteklerini kabul etme gücüne sahip olsa da, herkes katkıda bulunan topluluğumuza katılabilir ve kodlu veya kodsuz katkılar gönderebilir.
Çekirdek Takım
Çekirdek ekibimizin üyeleriyle tanışın! Birkaç topluluk üyesi katkıda bulunsa da, çekirdek ekip FreedomBox’ın geliştirilmesinde en çok yer alanlardan oluşur.
-
Sunil Mohan AdapaLead Developer & Code ReviewerE-posta
-
Joseph NuthalapatiDevOps Engineer, Developer, & Code ReviewerE-posta | Sosyal | Web Sitesi
-
James ValleroyRelease Manager, Developer, & Code ReviewerE-posta | Sosyal
Katkıda Bulunanlar
Çekirdek ekibimiz küçük olsa da, yüzlerce gönüllü yıllar boyunca FreedomBox’a katkılarda bulundu. Katkıda bulunanların çoğu burada listelenmiştir. Kendilerine çalışmaları için teşekkür ederiz!
Kararlar Nasıl Alınır
Genel olarak, yazılım geliştirme ve tasarımla ilgili kararlar çekirdek ekibin üyeleri tarafından tartışılır ve açık yazılım geliştirme platformumuz (yani GitLab) kullanılarak uygulanır. Ekibimiz tarafından alınan kararların çoğu tartışmasızdır ve uzun tartışmalar gerektirmez.
Ancak bazen uzun tartışmalar gereklidir. Makul bir şekilde anlaşmazlığa konu olabilecek teklifler için bir “Yorum İsteği” (Yİ - RFC) yöntemi kullanıyoruz. Yİ’leri açık geliştirme platformlarımızdan birine (yani Gitlab veya forum) gönderilmeli ve (1) teklifin yazılı bir özetini, taslağını veya modelini, (2) teklifin neden gerekli olduğuna dair kısa bir açıklama içermelidir ve (3) teklifi uygulamak için gerekli eylem öğelerinin bir listesi. İsteğe bağlı olarak, Yİ’ne dördüncü bir öğe de eklenebilir: gereksiz gecikmeleri önlemek için tartışma süreci için önerilen bir zaman çizelgesi. Bazen anlaşmazlıklar, önceden belirlenmiş zaman çizelgelerini takip etmeyi zorlaştırır; Bu gibi durumlarda, katılımcılar uzlaşmak için iyi niyetle çaba sarf etmelidir ve bu sağlanamazsa tartışmayı uzatabilir.
Düzeltim ile İyileştirme
Genel olarak, yazılım geliştirme veya tasarımla ilgili teklifler kabul edildiğinde, bu öneriler kalıcı değil düzeltim olarak değerlendirilir. Tekliflere yönelik bu düzeltim-ile-iyileştirme yaklaşımı, küçük ayrıntılar üzerinde durmadan genel olarak sağlam teklifleri kabul etmemizi sağlar. Kabul edilen tekliflerde küçük değişiklikler her zaman önceden yerine daha sonra yapılabilir. Orijinal teklif gibi, düzeltimler de tartışmaya tabidir ve tek taraflı yapılamaz. Deneysellik ruhu içinde, yazılımımızda aşamalı iyileştirmeleri teşvik etmek için düzeltilebilirliği benimsiyoruz.