Geliştirici olmak ne demektir?

Birçok insanın kullandığı açık kaynak bir projeyi sürdürürseniz, daha az kodladığınızı ve sorunlara daha fazla cevap verdiğinizi fark etmiş olabilirsiniz.

Bir projenin ilk aşamalarında, yeni fikirleri deniyor ve istediğinizi temel alan kararlar alıyorsunuz. Projeniz popülerlik arttıkça, kendinizi kullanıcılar ve katkıda bulunanlarla daha fazla çalışırken bulabilirsiniz.

Bir projeyi sürdürmek kod yazmaktan daha fazlasını gerektirir. Bu görevler genellikle beklenmedik bir durum değildir, ancak büyümekte olan bir proje için son derece önemlidir. Yaşamınızı kolaylaştırmak için, belgeleme işlemlerinden topluluğunuzu güçlendirmeye kadar birkaç yol yöntemi derledik.

İşlemlerinizi belgeleme

Her şeyi yazı hale getirmek, geliştirici olarak yapabileceğiniz en önemli şeylerden biridir.

Dokümantasyon sadece kendi düşüncelerinizi netleştirmekle kalmaz, diğer kişilerin size sormadan önce neye ihtiyacınız olduğunu veya ne beklediğinizi anlamalarına yardımcı olur.

Bir şeyler yazmak, bir şey sizin kapsamınıza uymadığında hayır demeyi kolaylaştırır. Ayrıca insanların girip yardım etmesini kolaylaştırır. Projenizi kimlerin okuyup kullanabileceğini asla bilemezsiniz.

Geniş paragraflar kullanmasanız da, madde imleri kullanarak not almak bile, yazmaktan daha iyidir.

Belgelerinizi güncel tutmayı unutmayın. Bunu her zaman yapamıyorsanız, eski belgelerinizi silin veya eski olduğunu belirtin; böylece katkıda bulunanlar güncellemelerin memnuniyetle karşılandığını bilir.

Projenizin vizyonunu yazın

Projenizin hedeflerini yazarak başlayın. Bunları README’nize ekleyin veya VISION adlı ayrı bir dosya oluşturun. Proje yol haritası gibi, yardımcı olabilecek başka çıktılar varsa, bunları da yayınlayabilirsiniz.

Net ve belgelenmiş bir vizyona sahip olmanız odaklanmanızı sağlar ve başkalarının katkılarından “kapsamın sürünmesini” önlemenize yardımcı olur.

Örneğin, @lord, proje vizyonuna sahip olmanın, hangi ihtiyaç için zaman harcamaya ihtiyaç duyulacağını belirlemesine yardımcı olduğunu keşfetti. Yeni bir geliştirici olarak, Slate için ilk uzun metraj talebini aldığında, projesinin kapsamına uymadığı için pişmanlık duydu.

Beklentilerinizi iletin

Kurallar yazmak için sinir bozucu olabilir. Bazen başkalarının davranışlarına göz attığınızı ya da tüm eğlenceyi öldürdüğünüzü hissedebilirsiniz.

Ancak, adil bir şekilde yazılmış ve uygulanmış olduğunda, iyi kurallar geliştiricileri güçlendirir. Yapmak istemediğiniz şeyleri yapmaya sürüklenmenizi önlerler.

Projenize rastlayan çoğu kişi sizin hakkınızda veya durumunuz hakkında hiçbir şey bilmiyor olabilir. Üzerinde çalışmak için para aldığınızı varsayabilirler, özellikle düzenli olarak kullandıkları ve güvendikleri bir şeyse. Belki bir noktada projenize çok zaman ayırıyorsunuz, ancak şimdi yeni bir iş veya aile üyesiyle meşgulsünüz.

Bunların hepsi olabilir! Sadece başkalarının da bildiğinden emin ol.

Projenizi yarı zamanlı veya tamamen gönüllü olarak sürdürmekteyseniz, ne kadar vaktiniz olduğu konusunda dürüst olun. Bu, projenin ne kadar zaman gerektirdiğini düşündüğünüzle veya başkalarının ne kadar zaman harcamanızı istediği ile aynı değildir.

Yazmaya değer birkaç kural:

  • Bir katkı nasıl gözden geçirilir ve kabul edilir ( Testlere ihtiyaçları var mı? Bir sorun şablonu var mı? )
  • Kabul edeceğiniz katkı türleri ( Kodunuzun yalnızca belirli bir bölümünde yardım mı istiyorsunuz? )
  • Bekleme süresi ne kadardır (örneğin, “7 gün içinde bir bakıcıdan bir yanıt bekleyebilirsiniz. O zamana kadar bir şey duymadıysanız, ipliğe ping atmaktan çekinmeyin.”)
  • Projeye ne kadar zaman harcıyorsunuz (örneğin, “Bu projeye haftada sadece 5 saat harcıyoruz”)

Jekyll, CocoaPods ve Homebrew geliştiriciler ve katkıda bulunanlar için temel kuralları olan projelere birkaç örnektir.

İletişimi herkese açık tutun

Sizin de etkileşimlerinizi belgelemeyi unutmayın. Nerede olursanız olun, projeniz hakkında iletişimi halka açık tutun. Birisi bir özellik isteğini veya destek ihtiyacını tartışmak için sizinle özel olarak iletişim kurmaya çalışırsa, kibarca onları bir posta listesi veya sorun izleyici gibi bir kamu iletişim kanalına yönlendirin.

Diğer geliştiricilerle tanışırsanız veya özel olarak büyük bir karar verirseniz, bu konuşmaları halka açıklayın, yalnızca notlarınızı gönderiyor olsanız bile.

Bu şekilde, topluluğunuza yeni katılan herhangi biri, yıllardır orada olan biriyle aynı bilgilere erişebilecektir.

Hayır demeyi öğrenme

Her şeyi yazdınız. İdeal olarak, herkes belgelerinizi okur, ancak gerçekte, bu bilginin var olduğunu başkalarına hatırlatmanız gerekecek.

Bununla birlikte, her şeyin yazılı olması, kurallarınızı uygulamanız gerektiğinde durumları kişisellikten uzaklaştırmanıza yardımcı olur.

Hayır demenin eğlenceli olmadığı kesin, ancak “Katkınız bu projenin ölçütlerine uymuyor” cevabı “Katkınızı beğenmedim” cevabından daha kurumsal hissettiriyor.

Bir geliştirici olarak karşılaşacağınız birçok durum için hayır demek uygundur: Örneğin, kapsama uygun olmayan özellik talepleri, tartışmanın rayından çıkması durumunda, başkaları için gereksiz işler yapılması durumunda.

Sohbeti dostane tutun

Hayır demeyi uygulayacağınız en önemli yerlerden biri de, sorun ve istek sıralarıdır. Bir proje sorumlusu olarak, çoğunlukla kabul etmek istemediğiniz öneriler alırsınız.

Belki yapılan katkı projenizin kapsamını değiştiriyor veya vizyonunuza uymuyor. Belki fikir iyidir, ancak uygulama zayıftır.

Sebep ne olursa olsun, projenizin standartlarına uymayan katkıları titizlikle ele almak mümkündür.

Kabul etmek istemediğiniz bir katkı alırsanız, ilk tepkiniz bunu görmezden gelmek veya görmemiş gibi yapmak olabilir. Bunu yapmak, diğer kişinin duygularına zarar verebilir ve hatta topluluğunuzdaki diğer potansiyel katılımcıların cesaretini kırabilir.

Kendinizi suçlu hissettiğiniz için veya iyi davranmak istediğiniz için, istenmeyen bir katkıyı açık bırakmayın. Zaman içinde, cevaplanmayan sorunlar ve birleştirme istekleri projeniz üzerinde çalışmayı çok daha stresli ve korkutucu hissettirecektir.

Kabul etmek istemediğinizi bildiğiniz katkıları derhal kapatmak daha iyidir. Projeniz zaten büyük bir birikimden etkilenmişse, @steveklabnik, sorunların verimli bir şekilde nasıl sıralanacağı konusunda verdiği önerilere bakabilirsiniz.

İkincisi, katkıları görmezden gelmek, topluluğunuz için olumsuz bir sinyal gönderir. Bir projeye katkıda bulunmak, özellikle birinin ilk defa olması durumunda korkutucu olabilir. Katkısını kabul etmeseniz bile, arkasındaki kişiyi kabul edin ve ilgileri için teşekkür ederiz. Onlar için bu büyük bir iltifat olur!

Bir katkıyı kabul etmek istemiyorsanız:

  • Katkıdan dolayı teşekkür edin.
  • Neden proje kapsamına girmediğini açıklayın ve mümkünse iyileştirme için net önerilerde bulunun. Nazik ama kararlı olun.
  • Varsa, ilgili belgelere link verin. Kabul etmek istemediğiniz şeyler için tekrarlanan istekler fark ederseniz, tekrar etmemek için bunları belgelerinize ekleyin.
  • İsteği kapatın.

Cevap vermek için 1-2 cümleden fazlasına ihtiyacınız yoktur. Örneğin, kerevizin kullanıcısı Windows ile ilgili bir hata bildirdiğinde, @berkerpeksag verdiği cevap:

Celery screenshot

Eğer hayır deme düşüncesi sizi korkutuyorsa, yalnız değilsiniz. @Jessfraz’ın söylediği gibi:

Birkaç farklı açık kaynaklı projeden, Mesos, Kubernetes, Chromium’dan gelenlerle konuştum ve hepsi de bir geliştirici olmanın en zor kısımlarından birinin yaptığı istemediğiniz yamalar için “Hayır” demek olduğu konusunda hemfikirler.

Birinin katkısını kabul etmek istemediğiniz için suçluluk hissetmeyin. @Shykes’e göre ilk açık kaynak kuralı: “Hayır geçici, evet kalıcıdır.” Başka birinin coşkusunu empati etmek iyi bir şey olsa da, bir katkıyı reddetmek, arkasındaki kişiyi reddetmekle aynı değildir.

Sonuçta, eğer bir katkı yeterince iyi değilse, kabul etme yükümlülüğünüz yoktur. İnsanlar projenize katkıda bulunurken nazik ve duyarlı olun, ancak yalnızca projenizi daha iyi hale getireceğine gerçekten inandığınız değişiklikleri kabul edin. Ne kadar sık hayır demeyi pratik edersen, işin o kadar kolaylaşır. Kesinlikle.

Proaktif olun

İstenmeyen katkıların hacmini ilk etapta azaltmak için, projenizin katkıda bulunma rehberinde katkı gönderme ve kabul etme sürecini açıklayın.

Çok fazla düşük kaliteli katkı alıyorsanız, katkıda bulunanların önceden biraz çalışma yapmasını isteyin, örneğin:

  • Bir sorun veya PR şablonunu veya kontrol listesi doldurma
  • PR göndermeden önce bir sorun açma

Kurallarınıza uymuyorlarsa, belgelerinizi referans göstererek sorunu hemen kapatın.

Bu yaklaşım ilk başta kaba görünebilir olsa da proaktif olmak her iki taraf için de iyidir. Birisinin kabul etmeyeceğiniz bir talep boşa saatlerce çalışma yapma riskini azaltır. Ve sizin de iş yükünüzü yönetmeyi kolaylaştırır.

Bazen, hayır dediğinizde, katkıda bulunan kişi kararınızdan dolayı kırılabilir veya sizi eleştirebilir. Davranışları düşmanca olursa, yapıcı bir şekilde işbirliği yapmaya istekli olmazlarsa durumu etkisiz hale getirmek için adımlar atın ve hatta onları topluluğunuzdan çıkarın.

Mentorluğu benimseyin

Belki de topluluğunuzdaki birileri düzenli olarak projenizin standartlarını karşılamayan katkılar sunar. Her iki tarafın da bu reddedilme süreçlerinden defalarca geçmesi sinir bozucu olabilir.

Birinin projeniz için hevesli olduğunu ancak biraz el vermek gerektirdiğini görürseniz, sabırlı olun. Her durumda katkılarının neden projenin beklentilerini karşılamadığını açık bir şekilde açıklayın. Onları ellerini kirletmek için “ilk iş için uygun” olarak işaretlenmiş bir konu gibi daha kolay veya daha az belirsiz bir işe yönlendirmeyi deneyin. Vaktiniz varsa, ilk katkılarınla onlara mentor olmayı düşünün veya topluluğunuzda mentor olmaya istekli olabilecek başka birini bulun.

Topluluğunuzdan yararlanma

Her şeyi kendiniz yapmak zorunda değilsiniz. Projenizin topluluğunun olmasının bir nedeni var! Henüz aktif bir katkıda bulunan topluluğunuz olmasa bile, çok fazla kullanıcınız varsa, onları işe dahil edin.

İş yükünü paylaşın

Başkalarının işe girişmesini istiyorsanız, bu dile getirerek başlayın.

Yeni katılımcılar kazanmanın bir yolu da yeni katılanlar için kolay çözülebilecek sorunları belirmektir. GitHub bu sorunları platform üzerindeki farklı sayfalarda göstererek farkedilebilir olmalarını sağlayacaktır.

Katkıda bulunan arasında yeni olanları gördüğünüzde, çalışmalarını daha fazla sorumluluk sunarak tanıyın. İsterlerse kendilerinin de yöneticilik rolüne nasıl dönüşebileceğini belgeleyin.

Başkalarını yüreklendirmek ve projenin sahipliğini paylaşmak kendi iş yükünüzü azaltır. @lmccart kendi projesinde bunu nasıl yaptığını aşağıdaki gibi anlatıyor, p5.js.

Projenizden, ara sıra veya kalıcı olarak çıkmanız gerekirse, bir başkasının sizin için üstlenmesini istemek utanılacak bir şey değildir.

Diğer insanlar yeni yön konusunda istekliyse, giriş yapmalarını sağlayın veya resmi olarak bir başkasına kontrolünü verin. Birisi projenizi çatalladı ve aktif olarak başka bir yerde sürdürüyorsa, orijinal projenizdeki çatalda bağlantı kurmayı düşünün. Bu kadar çok insanın projenizin devam etmesini istemesi harika bir şeydir!

@progrium farkına vardı ki; projesinin (Dokku) vizyonunu belgelemesi sayesinde kendisi projeden çekilse bile hedefleri canlı kalabildi:

Ne istediğimi ve neden istediğimi anlatan bir wiki sayfası yazdım. Bir nedenden dolayı, bakıcıların projeyi bu yönde hareket ettirmeye başlaması bana sürpriz oldu! Tam olarak benim istediğim gibi mi oldu? Her zaman değil. Ama yine de projeyi yazdıklarımın yakınına getirdi.

Başkalarının ihtiyaç duydukları çözümleri inşa etmelerine izin verin

Potansiyel bir katılımcının projenizin ne yapması gerektiği konusunda farklı bir görüşü varsa, onları kendi çatalı üzerinde çalışmaya kibarca teşvik etmek isteyebilirsiniz.

Bir projeyi terk etmek kötü bir şey olmak zorunda değildir. Projeleri kopyalayıp değiştirebilmek, açık kaynak kodlu hakkında en iyi şeylerden biridir. Topluluk üyelerinizi kendi çatalı üzerinde çalışmaya teşvik etmek, projenizin vizyonuyla çelişmeden ihtiyaç duydukları yaratıcı çıkışı sağlayabilir.

Aynı şey, inşa edecek bant genişliğine sahip olmadığınız bir çözümü gerçekten isteyen bir kullanıcı için de geçerlidir. API’ler ve kişiselleştirme kancaları sunmak, kaynağını doğrudan değiştirmek zorunda kalmadan, başkalarının kendi ihtiyaçlarını karşılamasına yardımcı olabilir. @orta, CocoaPod’lar için teşvik edici eklentilerin “en ilginç fikirlerin bazılarına” yol açtığını gördü :

Bir proje büyükleştiğinde, bakımcılar yeni kodu nasıl girdikleri konusunda daha muhafazakar hale gelmek neredeyse kaçınılmazdır. Hayır demekte iyisin, ama birçok insanın meşru ihtiyaçları var. Bunun yerine aracınızı bir platforma dönüştürürsünüz.

Robotları kullanın

Tıpkı diğer insanların size yardımcı olabileceği görevler olduğu gibi, hiçbir insanın yapmaması gereken görevler de vardır. Robotlar senin arkadaşın. Hayatınızı kolaylaştırmak için bunları kullanın.

Kodunuzun kalitesini yükseltmek için testler ve diğer kontrolleri zorunlu kılın

Projenizi otomatikleştirmenin en önemli yollarından biri de testler eklemektir.

Testler, katkıda bulunanların hiçbir şeyi kırmayacaklarından emin olmalarına yardımcı olur. Ayrıca katkıları hızla incelemenizi ve kabul etmenizi kolaylaştırır. Ne kadar duyarlı olursanız, toplumunuz o kadar adanmış olabilir.

Tüm gelen katkılarda çalışacak otomatik testler ayarlayın ve testlerinizin katılımcılar tarafından kolayca yerel olarak çalıştırılabildiğinden emin olun. Tüm kod katkılarının gönderilmeden önce testlerinizi geçmesini şart koşun. Tüm gönderiler için minimum kalite standardı belirlenmesine yardımcı olmuş olacaksınız. GitHub’daki zorunlu durum kontrolleri , testleriniz geçmeden değişiklik yapılmadan birleştirilmemesini sağlayabilir.

Testler eklerseniz, CONTRIBUTING dosyanızda nasıl çalıştıklarını açıkladığınızdan emin olun.

Temel bakım görevlerini otomatikleştirmek için araçlar kullanın

Popüler bir projeyi sürdürmenin iyi haberi, diğer geliştiricilerin de benzer sorunlarla karşı karşıya kalmaları ve bunun için bir çözüm üretmeleridir.

Bakım çalışmalarının bazı yönlerini otomatikleştirmeye yardımcı olacak çeşitli araçlar vardır. Birkaç örnek:

  • semantic-release sürümlerinizi otomatikleştirir
  • mention-bot PR talepleri için potansiyel denetçilerden bahseder
  • Danger kod incelemesini otomatikleştirmeye yardımcı olur
  • no-response geliştiricilerin uzun süre yanıt vermediği sorunları kapatır
  • dependabot bağımlılık dosyalarınızı her gün eski gereksinimler için kontrol eder ve bulduğu her biri için PR istekleri açar

Hata raporları ve diğer genel katkılar için GitHub, aldığınız iletişimi kolaylaştırmak için oluşturabileceğiniz Sorun Şablonlarına ve PR İsteği Şablonlarına sahiptir. @TalAter sorununuzu ve PR şablonlarınızı yazmanıza yardımcı olmak için Choose Your Own Adventure rehberini geliştirdi.

E-posta bildirimlerinizi yönetmek için, önceliğe göre düzenlemek için e-posta filtreleri ayarlayabilirsiniz.

Biraz daha gelişmiş olmak istiyorsanız, stil rehberleri ve taslaklar proje katkılarını standartlaştırabilir ve inceleme ve kabul etmeyi kolaylaştırabilir.

Bununla birlikte, standartlarınız çok karmaşıksa, katılımların önüne engel olabilirler. Herkesin hayatını kolaylaştırmak için sadece yeterince kural eklediğinizden emin olun.

Hangi araçları kullanacağınızdan emin değilseniz, özellikle ekosisteminizdeki diğer popüler projelerin neler yaptığına bakın. Örneğin, katılım süreci diğer Node modülleri için nasıl yapılmış? Benzer araçlar ve yaklaşımlar kullanmak, sürecinizi katkıda bulunması olası insanlar için daha tanıdık yapacaktır.

Duraklatmak sorun değildir

Açık kaynak çalışması bir zamanlar size heyecan ve mutluluk getirmiştir. Ama şimdi size yük veya sorumluluk hissettirmeye başlamış olabilir.

Belki de projelerinizi düşünürken bunalmış veya artan bir korku hissi duyuyorsunuz. Bu arada, sorunlar ve PR talepleri de yığılıyor.

Tükenmişlik, özellikle geliştiriciler arasında açık kaynaklı çalışmalarda gerçek ve yaygın bir konudur. Bir geliştirici olarak mutluluğunuz, açık kaynaklı herhangi bir projenin hayatta kalması için tartışılmaz bir gerekliliktir.

Söylemeye gerek yok ama, ara verin! Tatil yapmak için yanmış hissedene kadar beklemeniz gerekmez. Bir Python çekirdek geliştiricisi olan @brettcannon, 14 yıllık gönüllü OSS çalışmasının ardından bir ay boyunca tatil yapmaya karar verdi.

Tıpkı diğer tüm işlerde olduğu gibi, düzenli molalar vermek de işinizi yenileyecek, mutlu ve heyecanlı tutacaktır.

Bazen, herkesin size ihtiyacı olduğunu düşündüğünüz zamanlarda, bir açık kaynak projesine mola vermek zor olabilir. İnsanlar uzaklaştığınız için sizi suçlu hissettirmeye çalışabilir.

Bir projeden uzaktayken kullanıcılarınız ve topluluğunuz için destek bulmak için elinizden geleni yapın. İhtiyacınız olan desteği bulamazsanız, yine de bir ara verin. Uygun olmadığınız zamanı duyurduğunuzdan emin olun, böylece insanlar yanıt verme konusundaki eksikliğinizden dolayı şaşkınlığa uğramazlar.

Ara vermek, tatillerden daha fazlası için de geçerlidir. Hafta sonları veya mesai saatleri arasında açık kaynak kodlu bir iş yapmak istemiyorsanız, bu beklentinizi başkalarına iletin; böylece sizi rahatsız etmemeleri gerektiğini bilirler.

İlk önce kendinize iyi bakın!

Popüler bir projeyi sürdürmek, büyümenin önceki aşamalarından farklı beceriler gerektirir, ancak daha az ödüllendirici değildir. Bir geliştirici olarak, birkaç kişinin deneyimleyebileceği bir seviyede liderlik ve kişisel beceriler geliştireceksiniz. Yönetimi her zaman kolay olmamakla birlikte, net sınırlar koymak ve yalnızca neleri yapacağınızı belirlemek sizin mutlu, yenilenmiş ve üretken kalmanıza yardımcı olacaktır.