Popüler açık kaynak projeleri oluşturmak için ipuçları
(skerritt.blog)<p>"Ağ etkisi: İnsanlar onu ne kadar çok ararsa, kullanıcı sayısı o kadar artar, katılım o kadar çoğalır, özellikler o kadar iyileşir ve proje o kadar tanınır hale gelir."<br />
Popüler olmak için ne yapmak gerekir?<br />
<br />
#1. İyi tasarlanmış bir README <br />
- En başta kısa ve net açıklayın <br />
→ Bu ne işe yarıyor?<br />
→ Benim sorunumu çözüyor mu?<br />
→ Benim sorunumu rakiplerden daha iyi çözüyor mu?<br />
→ Nasıl kurarım?<br />
→ Bilmem gereken temel komutlar neler?<br />
→ Yardım almak için nereye gitmeliyim?<br />
<br />
1.1 Projeyi özetleyen bir header oluşturun <br />
→ Logo: Logoyu Canva gibi yerlerde GIF logo olarak oluşturun <br />
→ Slogan: Projeyi tek cümlede açıklayın. Bunu GitHub açıklamasına da uygulayın<br />
⇨ İlk bakışta dikkat çekmeli<br />
⇨ Kullanıcının neden buna ihtiyaç duyduğunu anlatmalı <br />
⇨ Bunun neden diğerlerinden daha iyi olduğunu göstermeli <br />
⇨ Anlaşılması kolay olmalı <br />
⇨ Örn.) hugo: The world’s fastest framework for building websites<br />
→ Rozetler: Küçük görseller/bağlantılarla projeyi anlatın <br />
⇨ Son etkinlik sayısı, indirme sayısı, sohbet odasında kaç kişi olduğu, kullanılan sürümler, lisans vb. <br />
→ Hızlı kurulum: Kolay ve hızlı kurulum komutlarını hemen görünür şekilde koyun<br />
⇨ Ne aradığını bilenler hızlıca denemeye başlayabilsin <br />
⇨ Docker/PIP ile tek satırda kurulabildiği gibi şeyleri mümkün olduğunca başta gösterin <br />
⇨ docker run -it --rm remnux/ciphey<br />
→ Hızlı bağlantılar (zorunlu değil)<br />
⇨ Web sitesi, forum, dokümantasyon, kurulum kılavuzu, katkı kılavuzu, Twitter vb.<br />
<br />
1.2 "What is This?" Projeyi kısa ve net şekilde açıklayın <br />
→ Kısa açıklama + projenin nasıl çalıştığını gösteren GIF + insanların görmek isteyeceği temel özellikler <br />
→ Örn.) Starship: Solda temel özelliklerin anlatıldığı, sağda ise çalışan GIF’in olduğu iki sütunlu düzen <br />
→ Tüm özellikleri göstermek zorunda değilsiniz. Kullanıcıların görmek isteyeceği şeyleri listeleyin ve anlaşılır biçimde anlatın <br />
<br />
1.3 "X vs Y" Rakiplerle karşılaştırın <br />
→ İnsanlara bu projeyi neden rakipler yerine seçmeleri gerektiğini göstermelisiniz <br />
→ Avantajlar kolayca görülebilmeli<br />
→ Bu, yalın girişim yaklaşımında önce "ortalama kullanıcıyı" değil "erken benimseyenleri" bulmanız gerektiği fikrine benzer <br />
⇨ Daha iyi özellikler varsa, yeni bir araca geçmekten çekinmeyen kişiler <br />
→ Yalnızca hiç rakip yoksa ya da mevcut çözümler sizin çözümünüze göre aşırı karmaşıksa "ortalama kullanıcıyı" hedeflemek mantıklıdır <br />
→ En kolay yöntem, temel özellikleri karşılaştıran bir tablo hazırlamaktır<br />
⇨ Sözlerden çok sayılarla gösterin <br />
⇨ Çalışmayı GIF’lerle karşılaştırmalı göstermek de iyidir <br />
<br />
1.4 Harika dokümantasyon hazırlayın <br />
→ Tüm dokümantasyonu README’ye koymak zorunda değilsiniz. Güncellemesi ve aranması zorlaşır, ayrıca README’yi okunması güç hale getirir <br />
→ Yukarıda kurulum yöntemini yazdığınıza göre, ek olarak göstermeniz gerekenler şunlar: <br />
⇨ Nasıl çalıştırılır<br />
⇨ Dokümantasyon nerede bulunur<br />
⇨ Nasıl destek alınır <br />
→ Çalıştırma yöntemini GIF ile göstermek de iyidir <br />
<br />
1.5 Nasıl katkı yapılacağını anlatın, katkı sunanlara teşekkür edin ve onları karşılayın <br />
→ Projeye nasıl katkı sunulur<br />
→ Önceki katkı sunanlara teşekkür edin <br />
→ all-contributors gibi botlar kullanın <br />
<br />
#2. İnsanların istediği şeyi yapın <br />
→ İyi bir README insanların ilgisini çeker; onların "sorununu çözen" bir proje ise insanların bunu başkalarına anlatmasını sağlar <br />
<br />
2.1 Önce sorun, sonra ürün<br />
→ Bir ürün yapmak için bir şey üretmeyin; bir sorunu çözün <br />
→ "İlerleme yalnızca büyük sıçramalarla değil, yüzlerce küçük adımla da gelir."<br />
<br />
2.2 Sorunla birlikte yaşayın <br />
→ Ortada sorun yoksa, onu etkili biçimde çözemezsiniz <br />
→ Rastgele fikir üretmektense, kendi hayatınızdaki sorunları gözlemlemek çok daha kolaydır <br />
→ Bir sorun olduğunu fark ettiğinizde iki şeyi öğrenirsiniz: Gerçekten bir sorun vardır ve başkalarında da vardır.<br />
<br />
2.3 Topluluk içinde sorun bulun <br />
→ Topluluklara baktığınızda, insanlar karşılaştıkları sorunları açıkça ortaya koyar <br />
→ Ne kadar çok insanı dinlerseniz, yalnız başınıza düşünmekten daha fazla fikir üretebilirsiniz <br />
→ Topluluğun yaşadığı sorunu çözen bir MVP (Minimum Viable Product) yapmayı deneyin <br />
→ Bunu toplulukla paylaşın, etkisini ölçün, nasıl daha iyi hale getireceğinizi öğrenin ve yeniden yaparak ya da eklemelerle iyileştirin <br />
<br />
#3. Dışarıya duyurun <br />
→ Ne kadar iyi yaparsanız yapın, yayımlamazsanız kimse görmez <br />
→ Öncesinde topluluktan yararlandıysanız, neyse ki onlar zaten bunu bilir ve kullanır <br />
→ GitHub Star sayısını 0’dan 1’e çıkarmak zordur ama 10’dan 100’e çıkarmak daha kolaydır <br />
<br />
3.1 Toplulukla paylaşın <br />
→ Build, Measure, Learn döngüsü <br />
→ İlk gerçek sürümünüzde topluluğun mutlaka haberi olsun. Onlar da bunu arkadaşlarıyla paylaşacaktır<br />
<br />
3.2 News Aggregators <br />
→ İlgili Subreddit <br />
→ HackerNews (çevirmenin notu: GeekNews de!)<br />
→ Lobste.rs <br />
<br />
3.3 Awesome List <br />
→ Konuyla ilgili listeleri bulun ve PR gönderin </p>
2 yorum