Buna Basın: WordPress Eklentileriniz GPL uyumlu mu?

WMR'nin WordPress topluluğu podcast'i Press This'e hoş geldiniz. Her bölümde topluluktan konuklar ve WordPress geliştiricilerinin karşılaştığı en büyük sorunlara ilişkin tartışmalar yer alıyor. Aşağıda orijinal kaydın transkripsiyonunu bulabilirsiniz .

RedCircle tarafından desteklenmektedir

Doc Pop : WMR'de bir WordPress topluluğu podcast'i olan Press This'i dinliyorsunuz. Her hafta WordPress topluluğunun üyelerini öne çıkarıyoruz. Ben sizin sunucunuzum Doktor Pop. WP Engine'deki görevim ve TorqueMag.io'daki katkılarım aracılığıyla WordPress topluluğunu destekliyorum. Press This'e RedCircle, iTunes, Spotify veya favori podcasting uygulamanızdan abone olabilir veya bölümleri doğrudan WMR.fm'den indirebilirsiniz.

Açık kaynaklı bir projeye katkıda bulunduysanız, bunun tamamen işbirliği ve yenilikle ilgili olduğunu bilirsiniz, ancak eklentilerinin GPL'nin, GNU'nun doğru tarafında kalmasını sağlama konusunda birçok geliştiricinin karşılaşabileceği az bilinen bir zorluk vardır. Genel Kamu Lisansı. Bu sadece uyum meselesi değil. Bu, açık kaynağın ruhunu korumakla ilgilidir.

Bugün özel bir konuğumuz var, 10up'ın açık kaynak direktörü Jeff Paul, bu yıl WordCamp ABD'de sunduğu oyunun kurallarını değiştiren bir çözümü paylaşacak. Siz yeni özellikler ve bağımlılıklar ekleseniz bile eklentinizin GPL uyumluluğunu garanti etmek için kod tabanınızı otomatik olarak tarayan bir araca sahip olduğunuzu hayal edin.

Bugün bunun hakkında konuşacağız. Ancak bu konuya dalmadan önce Jeff, bize WordPress'in başlangıç ​​hikâyesini anlatabilir misin?

Jeff Paul : Elbette. Tam yılım var mı bilmiyorum. Muhtemelen 2000'li yılların başıydı. Eski bir CMS'de bulunan kişisel bir sitem vardı, sanırım adı Geeklog'du. Ve bununla o zamanki barındırma sağlayıcım arasında ve kim bilir daha kaç faktör arasında CMS'deki içeriğin çökmesi vardı.

Ben de o zamanlar bunun yerini alacak bir şey arıyordum. WordPress'i buldum ve ihtiyacım olan şey için işe yaradı. Bilirsiniz, pek çok insan için iyi bir başlangıç ​​hikayesi gibi görünen bir CMS oluşturma yoluna girmedim. Ama bu, buna, bilmiyorum, '04'ten '07'ye kadar, bu aralıkta bir yerdeydi, ama WordPress 4.7 sürümüne kadar oradaki sürüm ekibine katıldığımda katkıda bulunmak için sınırı aşmadım. Helen Hou-Sandi ve Aaron Jorbin. Böylece uzun yıllarımı projenin tüketicisi olarak geçirdim ve ancak epey bir süre sonra katkıda bulunanlardan biri oldum ve o zamandan beri bu yolda devam ettim. Bilirsiniz, bu noktada ikili tüketici ve katılımcı.

DP : Siz de WordPress çekirdeğine çok aktif katkıda bulundunuz. 10up, eklenti deposunda ElasticPress, Distributor, ClassifAI dahil düzinelerce eklentiyi tutar. Bunların hepsi wordpress.org deposunda mevcuttur ve GitHub'da halka açık olarak ve açık kaynak uygulamaları kullanılarak tutulur.

İnceleyeceğimiz konuyu çok iyi biliyorsunuz. Neden WordPress eklenti deposu gibi WordPress deposuyla başlamıyoruz? Bize hızlıca söyleyin, WordPress deposu nedir ve buraya herhangi bir şey yükleyebilmenin kuralları nelerdir?

JP : Elbette. Dolayısıyla WordPress deposu, WordPress.com'dan ayrı, ekosistemdeki diğer ana bilgisayarlardan ayrı, üçüncü taraf eklenti şirketlerinden veya distribütörlerinden ayrı, açık kaynaklı bir proje olan WordPress.org tarafından barındırılmaktadır. Ve oradaki her WordPress kurulumuna doğrudan bağlı veya bağlı olan şey budur. Birisi WordPress yöneticisindeyken bir eklenti veya tema ararken, bu aramalar WordPress.org eklenti deposu ve WordPress yöneticisinde bulunan tema deposu aracılığıyla yapılır. WordPress.org'da da benzer şekilde. Etkili olarak aynı arama, aynı içerik orada mevcuttur.

Burada listelenen bir şeyi almak açısından, wordpress.org eklenti inceleme ekibinin, eklenti geliştiricileri için yapılması ve yapılmaması gerekenlerle ilgili bir dizi ayrıntılı yönergesi vardır. Ve sonra, wordpress.org eklenti deposuna bu ilk gönderimi yapmak için gerçek bir gönderim iş akışı var. Bu onaylandıktan sonra eklentiniz için oluşturulmuş bir SVN deposu vardır. Ve biliyorsunuz, tüm güncellemeler, sürümler vb. SVN'ye aktarılıyor. Ve burası, WordPress.org'da veya WordPress yöneticisinde aranabilecek şeyler için şu anda her şeyin yaşadığı ve nefes aldığı yerdir.

DP : İnandığım ilk kurallardan biri, WordPress deposuna koyduğunuz her şeyin, yalnızca kod değil, yazı tipleri ve resimler de dahil olmak üzere GPL ile uyumlu olması gerektiğidir. Bu doğru mu?

JP : Doğru. Sağ. Yani kelimenin tam anlamıyla eklenti ekibinin ilk kuralı, eklentilerin tamamının GPL uyumlu olması gerektiğidir. Bu, WordPress'in izlediği lisansın aynısıdır ve sizin de belirttiğiniz gibi kod, görseller ve üçüncü taraf kitaplıkların hepsinin GPL uyumlu olması gerekir. Bunun mutlaka gerçek GPLv2 lisansı olması gerekmiyor, GPL uyumlu başka lisanslar da var, ancak evet, yazı tipleri, resimler, üçüncü taraf kitaplıkları, bağımlılıklar, bunların hepsi GPL uyumlu olmalı ve yalnızca bir eklenti geliştiricisinin yazdığı kod, değil mi? Diğer tüm şeylerin de GPL uyumlu olması gerekir.

DP : Ve dinleyicileri bekletmemek için hemen konuya girebiliriz. Konuşmanız GitHub eylemlerini kullanarak GPL uyumluluğunun nasıl kontrol edilebileceğiyle ilgiliydi. Bize bu süreci anlatabilir misiniz?

JP : Evet, bu biraz da benim 10Up'taki açık kaynak direktörü rolümden kaynaklanıyor. Bu belki de sıradan bir eklenti yazarının tek bir eklentinin, hatta birden fazla eklentinin farkında olabileceği veya onları rahatsız edebileceği bir şey değildir. Ama sanırım bir noktada gece yarısı uyandığımda kelimenin tam anlamıyla şunu düşündüm: "Tüm görselleri, tüm üçüncü taraf bağımlılıklarını, tüm yazı tiplerini bildiğinizden emin olup olmadığımı bilmiyorum." vb. GPL uyumludur ve sizin de belirttiğiniz gibi wordpress.org deposunda veya GitHub'da bulunan düzinelerce eklentiye sahip olduğumuz 10up'ta bizim için geniş ölçekte bir yol bulmaya çalışıyorlar. Kaynak orda.

Tüm bunları ince dişli bir taramayla yapmak zorunda kalmak ve eklentiler için kullandığımız yukarı akış bağımlılıklarını kontrol etmek ve bunların nasıl lisanslandığını anlamak zorunda kalmak istemedim. Bu, bırakın birden fazla eklentiyi, tek bir eklenti için bile baş belası olabilir. Bazıları aracılığıyla çevrimiçi arama yaparak, bu süreci etkili bir şekilde otomatikleştirmeye yardımcı olmak için kullanılabilecek bazı araçların, bazı GitHub eylemlerinin olduğunu tespit ettim, böylece, bilirsiniz, bir deponun tek seferlik taranması değil, evet, Uyumlusunuz ya da değilsiniz, ancak eklentinize yeni bir bağımlılık ekleyebilecek ya da belki de bir şeyin nasıl olduğunu değiştirebilecek bir bağımlılığı ortadan kaldırabilecek gelecekteki hata düzeltmeleri, geliştirmeler vb. için taramalara devam edin. lisanslı olmak, devam edenleri kontrol edebilmek ve bu tür bir ilk geçiş işlemini yapabilmek, bunun sadece manuel, yoğun bir süreç ve devam eden bir kabus gibi olmamasını sağlamak için anlamaya çalıştığım bir şeydi. , bu uyumluluk.

Yani evet, sanırım başlangıçtaki endişem şuydu, bunu bilmiyordum; eğer yeni bir bağımlılık ekliyorsak ekleyeceğimiz bazı özelliklerin GPL uyumlu olduğunu bilmemin hiçbir yolu yoktu. , ve daha sonra, yazılımlarında zaten uyumsuzluklar bulunan eklentilerin yayınlandığı ve bunun üzerine tekrarlandığı daha da kötü bir senaryo olabileceğini fark ettik.

Ve bu denemek ve çözmek istediğim ilk sorundu. İlk ilk tarama, değil mi? Bireysel eklentilerimiz ve 10up'ın desteklediği eklentilerin tümü beyan ettiğimiz lisansla gerçekten uyumlu mu? Ve umarım öyleydiler. Ve sonra, biliyorsunuz, oradan, ekibimden ve 10up'taki açık kaynak uygulamalarından olsun, genel olarak projelere katkıda bulunan diğer 10up'lardan veya topluluktaki herhangi bir kişiden gelecek PR'lerin, eklentilerin kendisinde belirttiğimiz lisansı koruduklarını.

DP : Ve burada açıklığa kavuşturmak gerekirse, eğer bunu yapmadıysanız, eğer bunu yaparak, mevcut bir bağımlılığın ya da orada uyumlu olmayan bir şeyin olduğunu fark ettiyseniz, bunun sonuçları bir nevi utanç vericidir. topluluk mu yoksa kurallara uymamanız nedeniyle maruz kalabileceğiniz cezai bir zarar var mı?

JP : Yani ben avukat değilim, değil mi? Yani, biliyorsunuz, bu yorumu yapma konusunda avukatlık şapkam yok, yani biliyorsunuz, geçerli bir hukuki tavsiye değil, ama bu taramaları eklentilerimizde çalıştırırken benimsediğim yaklaşım, çünkü yine de bunu yapmadım. biliyorum, aslında tüm bunları yürütürken sonuçların ne olacağı konusunda oldukça gergindim.

Planım, GPL uyumlu olmayan bir şey kullanan bir eklenti olduğunu tespit edersem, en iyi yaklaşımın ya bu bağımlılığı ortadan kaldırmak, başka bir şeyle değiştirmek, sorun ne olursa olsun bunu etkili bir şekilde ortadan kaldırmak olmasıydı. yeni bir sürümü hızlı bir şekilde yayınladık, değil mi?

Halihazırda yayınlanmış ve yayınlanmış olan şeyler için yapılabilecek pek bir şey olmadığını hissettim. Benim bakış açıma göre bunların hiçbiri, lisanslamayı kasıtlı olarak atlatmaya çalışmak amacıyla yapılmazdı. bu, bir noktada, bir eklenti yazarına bildirilen bir güvenlik sorununa benzeyen, insan hatası olurdu. Mesela, en iyi yaklaşım, bir iyileştirme üzerinde çalışmak ve eklentileri güncel tutan kişilerin, bir güvenlik sorunu veya bu durumda bir lisans endişesi olsun, daha güvenli bir durumda olması için bir düzeltme üzerinde çalışmak ve hızlı bir şekilde bir sürüm çıkarmaktır. Elbette, önemli ölçüde gelir getiren bir eklenti varsa ve eğer olabilirse, bir şeyin lisanssız hale getirilmesinin bilinen bir hata olduğunu gösteren nedenler varsa, bir yana, bu alanda kimsenin buna inandığına inanmıyorum. bunu bilerek yapıyor, ancak potansiyel olarak yasal risk altında olabileceklerin yalnızca önemli ölçüde gelir getirici olan ve lisanslama için hedef olabilecek olanlar olacağını düşünüyorum.

Yani evet, sanırım uzun lafın kısası, eğer biri tarama yapıp mevcut kod tabanında bir sorun bulursa, bence en iyi yaklaşım gerçekten bir sürüm yayınlamak, güncellenmiş bir sürümü, bilirsiniz, değişiklik günlüğünde belirtmektir, Sürüm notlarında neyin ve neden değiştiğini belirtin, bu konuda şeffaf olun. Ancak bu noktada, bu durumda bir eklenti yazarının yapabileceği en iyi şeyin bu olduğunu düşünüyorum. Neyse ki 10up'ın eklentilerinde bu senaryoyla karşılaşmadık. Neyse ki her şey uyumluydu ve bu yola giren insanların büyük çoğunluğunun, onlara bu düzeyde rahatlık sağlayacak bir otomasyon kurmasının benzer bir deneyime sahip olacağını umuyordum.

GitHub eylemlerinin çalışması için birkaç saniye veya bir dakika boyunca biraz gergin, endişeli bir bekleyiş olabilir. Ama biliyorsunuz, her şeyin geçtiğini gösterdiğinde çoğu insanın muhtemelen bu duruma düşeceğini düşünüyorum.

DP : Rahatlamaktan bahsetmişken, kısa bir ara vereceğiz. Arkanıza yaslanın ve rahatlayın; kısa reklam arasından sonra, 10up'ın açık kaynak girişimleri direktörü Jeff Paul ile eklentilerinizi GPL uyumlu tutma konusunda yaptığımız röportajın devamı ile geri döneceğiz. Bu kısa aradan sonra daha fazlası için bizi takip etmeye devam edin.

DP : Bir WordPress Topluluk Podcast'i olan Press This'e tekrar hoş geldiniz. Ben Doc. Jeff Paul ile kodunuzun ve eklentilerinizin GPL uyumlu olduğundan emin olmak için GitHub eylemlerini kullanma hakkında konuşuyorum. Aradan önce bu konuya biraz daldık ve tam olarak uyumlu olmamanız durumunda bunun sonuçları hakkında konuştuk. Ve sanırım bu spesifik konuya geri dönmek istedim. Herkesin oluşturabileceği GitHub eylemleri vardır. Ancak Jeff, WordCamp konuşmanızda resmi GitHub eylemini kullandığınızdan bahsetmiştiniz, sanırım bazı küçük değişikliklerle. İnsanların bunu yapabilmek için araması gereken eylemin adı nedir bize söyleyebilir misiniz?

JP : Elbette. Bu bir bağımlılık inceleme eylemidir. Yani GitHub.com, eğik çizgi eylemleri, eğik çizgi bağımlılığı, tire incelemesi, tire eylemi. Umarım transkript bunu doğru şekilde alır. Bu konuda herhangi bir sorun varsa sitemde, konuşmayı kapsayan bir gönderide bununla ilgili notlarım var. Yani, mevcut bağlantılar var, ancak GitHub eylem pazarında bağımlılık inceleme eylemi ararsanız, benim kullandığım resmi olanı bulacağınızı umarız ve bu, eklenti bağımlılıklarını kontrol etmekten daha fazlasını yapar. Lisanslardan daha fazlasını kontrol edecek. Ayrıca eklenti bağımlılıklarınızdaki güvenlik açıklarını ve diğer şeyleri de kontrol edebilir. Ancak onu kullandığım tek şey, kullandığım temel şey, eklentilerimizin içindeki bağımlılıklarda geçersiz lisansları kontrol etmek.

DP : Bu da ne tür GPL takip etmek istediğinizi ayarlayabileceğiniz bir eylemdir. Bir lisans ekleyebilirsiniz ve o bunu kontrol eder. Ayrıca, diyelim ki düzinelerce eklentiyi sürdürüyorsanız, yine de aynı şeyi kaynaklayabilmeniz olasılığı da var. Devam ettirdiğiniz tüm eklentilerin hala tek bir dizine gelmesini sağlayabilirsiniz, böylece her seferinde gidip güncellemenize gerek kalmaz, değil mi?

JP : Doğru. Evet. WordCamp ABD'deki konuşmamı izlediğinizi görüyorum, dinleyiciler arasında yer aldığınız, uyanık olduğunuz ve dinlediğiniz için sizi tebrik ediyorum veya bunu YouTube'da veya WordPress.tv'de yakaladınız, ancak evet, beklediğim iki tür standart akış var millet burayı takip etmek için.

Birincisi, bir veya çok az sayıda eklentiden sorumlu olan bir eklenti yazarı veya bire bir ölçekte daha fazlasına sahip olan biri, desteklediği çok sayıda eklentiye sahip. Dolayısıyla, yalnızca tek bir taneye sahip olan kişiler için, tanımladığınız gibi GitHub eylemi, bu bağımlılık inceleme eylemini etkili bir şekilde çağırdığınız ve deponuzu taramasını sağladığınız iş akışı dosyasında etkili bir şekilde etkili olabilir, iki tane çevresel değişken vardır: veya sağlayabileceğiniz parametreler. Bu eylem, lisanslara izin vermektir ve bunun doğal sonucu, lisansları reddetmektir. İkisini aynı anda yapamazsınız. ve benim izlediğim yaklaşım, reddetme lisanslarının aksine izin verme lisanslarını kullanmaktı. Buradaki düşünce şuydu… GPL uyumlu bir lisansı izin verilen lisanslar listesine eklemeyi unuttuğum ve etkili bir şekilde yanlış pozitif sonuç almayı tercih ederim, değil mi? Mesela, lisansları listeye eklemeyi unuttuğum bir şey olduğu için lisanslarımla uyumlu değil olarak işaretlenen bir bağımlılık almak gibi; buna karşın lisansları reddet listesini kullanırsam ve istemediğim bir lisansı reddetmeyi unutursam, o zaman bu durum ortaya çıkabilir. bir bağımlılığın geçeceği, bu çeke yakalanmayacağı anlamına geliyordu.

Bu nedenle son derece güçlü tavsiyem, izin verilen lisanslar listesine uymanızdır. Birisinin tek bir eklentiyi sürdürdüğü durumda, iş akışı dosyalarınızda yalnızca o parametreyi ve lisans listesini kullanmaktır. Yani, 10up için, eklentilerimiz için bu, nokta GitHub dizini ve ardından oradaki iş akışları alt dizini. Ve sonra, bu bağımlılık inceleme eylemini çağıran, izin verilen lisanslar listesine sahip olan bağımlılık inceleme iş akışımız var, sunumumu sitemde bulabilir veya çevrimiçi konuşmayı bulabilir ve sahip olduğumuz lisansların listesini görebilirsiniz. Ayrıca GitHub'da 10up'ın depolarından herhangi birini keşfedebilir ve incelediğimiz lisansları görebilirsiniz.

İş akışı dosyalarımız oldukça iyi belgelenmiştir ve eklentilerimizle uyumlu olduğunu düşündüğümüz lisansları nasıl tespit ettiğimizi açıklamaktadır. Yani insanlar elimizdeki listeyi kullanabilir, bu listenin bir alt kümesini kullanabilir, kendi araştırmalarını yapabilir, belki de bu düzeyde rahatlık hissedebilirler. Ancak izin verilen lisanslar listemizde kullandığımızın aslında beyan ettiklerimizle uyumlu olduğundan emin olmak için oldukça uzun bir araştırma yaptık. Ve 10up için hemen hemen varsayılan olarak GPLv2 veya üstünü kullanıyoruz ve dolayısıyla listelediğimiz tüm lisanslar özellikle GPLv2 ile uyumludur.

Bu, eklenti yazarının sürdürdüğü tek bir eklenti için de geçerli. Bahsettiğiniz gibi, birinin birden fazla lisansa sahip olması durumunda, içinde belirtilen tüm lisansları etkili bir şekilde içeren ayrı bir lisans politikası dosyanız olabilir. Ve sonra eklentilerinizdeki iş akışında o yapılandırma dosyasına, o lisans politikası dosyasına referans verirsiniz, böylece bahsettiğiniz gibi, gerçekten bu noktada uyumlu lisansların listesini tutmak için ihtiyacınız olan tek bir yer olur. Biliyorsunuz, bizim için GPLv2 uyumlu yeni bir açık kaynaklı, girişim onaylı lisans varsa, değil mi? Eğer yeni bir tanesi sahneye çıkarsa, o da listeye eklenebilir veya herhangi bir nedenle listeden çıkarılması gerekirse, bunu onlarca yerde yapmanıza gerek yok. Bunu tek bir konumda yaparsınız ve ardından bu yapılandırmaya referans veren tüm iş akışı dosyalarınız, bu yeni lisans listesi kullanılarak hemen güncellenir.

DP : Bunların hepsi otomatiktir, yani birisi bir çekme isteğinde bulunursa, bunu yalnızca sizin için yapar. Sağ?

JP : Doğru, doğru. Yani iş akışı dosyalarımızı depolarımızda oluşturduğumuzda, çekme isteği üzerine bir tetikleyicimiz olur. Yani, onu bir CRON planına göre çalışacak şekilde de ayarlayabilirsiniz, haftalık veya aylık çalışmasını sağlayabilirsiniz, ancak gerçekte, ilk çalıştırmayı yaptığınızda, bağımlılıkların tüm kod tabanını tararsınız ve bu gerçekten işe yarar. ileriye doğru, gerçekten yalnızca gelen çekme isteklerini kontrol etmeniz gerekiyor. Eklentileriniz için varsayılan veya kararlı dallarınız ne olursa olsun, PR'leri zorunlu kılan oldukça katı bir sistem kullanmıyorsanız, muhtemelen bireysel taahhütleri de kontrol edebilirsiniz.

Dolayısıyla insanların kullanmak isteyebileceği ek tetikleyiciler olabilir. 10up için, bu eylemi güvenilir bir şekilde kullanabilmemiz ve bağımlılıklarda yeni bir tane getiren veya lisansı değiştiren bir sürümü öne çıkaran herhangi bir değişikliğin buna yakalanacağını bilebilmemiz için PR'lerin geliştirmesini ve şubeleri birleştirmesini oldukça sıkı bir şekilde zorunlu kılma eğilimindeyiz. . Yani evet, çekme isteklerini kullanıyoruz, döndürüyoruz veya tetikliyoruz, ancak insanların ne kadar katı olduğuna bağlı olarak, belki belirli bir şubeye bireysel taahhütleri kontrol ettirebilirsiniz, hatta günlük, haftalık, aylık bir programa göre çalıştırabilirsiniz. kodunuzun hâlâ geçtiğini, bu durumda GPLv2 for 10up ile uyumsuz hiçbir lisans olmadığını bilmenin rahatlığını yaşamak.

DP : Burada kısa bir mola daha vereceğiz. Geri döndüğümüzde Jeff Paul ile GPL lisansları hakkındaki sohbetimizi tamamlayacağız ve belki daha önce değinmediğimiz konulara değineceğiz. Bu kısa aradan sonra daha fazlası için bizi takip etmeye devam edin.

DP : Bir WordPress Topluluk Podcast'i olan Press This'e tekrar hoş geldiniz. Gösteriyi tamamlıyoruz ve vitesi biraz değiştireceğiz. Son zamanlarda eklenti deposundaki inceleme süreciyle ilgili bazı konuşmalar yapılıyor ve temelde bu gerçeği belirtmek gerekirse, bu süreç geçmişte olduğundan biraz daha yavaş.

Bazı insanlar, WordPress'te geçirdiğim yılların çoğunda belki dört haftada zirveye ulaştığını gördüğüm bir şeyi gözden geçirmenin aylar sürdüğünü bildiklerini söylüyor. Jeff, belki bu konuda yapacakları bazı değişiklikler hakkında konuştuklarını biliyorum. Ekibin şu anda ne üzerinde çalıştığını bize anlatabilir misiniz?

JP : Elbette. Evet. Ve ben, biliyorsun, söylediklerini daha da güçlendiriyorum. Sanırım tarihsel olarak, gönderdiğim her şeyin iki haftadan kısa sürdüğünü ve genellikle bildirilenden çok daha hızlı olduğunu gördüm. Ve yaklaşık 88 günde sona eriyor ya da olaya dahil olan herkes için talihsiz bir durum.

Bu takımda bir miktar değişim olduğunu düşünüyorum. Bazı çok deneyimli üst düzey bilgiler kaybedildi. Ve bu boşluğu doldurmaya yardımcı olmak için nezaketle müdahale eden kişiler, sanırım hala eklentileri işleme ve bu ilk gönderimleri inceleme konusunda aynı tür verime sahip olabilecekleri noktaya geliyorlar. Ve bunların bir kısmını otomatikleştirmek için yaptıkları çalışmalar var. Yani, bilgisayarların insanlardan daha iyi olduğu, belki de insanların yapamadığı bazı şeyler, belki de WordPress kodlama standartlarını çalıştırmak ve gerçekten kritik hataların bildirildiği yerlerde uzmanlaşmak gibi, değil mi? Bir insanın bu şeyleri gözden geçirmek ve işlemek zorunda kalması yerine, otomatikleştirilebilecek şeyleri çalıştıran ve kontrol eden bir eklenti denetleyicisine sahip olmak ve eklenti inceleme ekibinin sadece hızlı bir başlangıç ​​​​duraklaması yapmasına yardımcı olmak, otomatik olarak geçen şeyler mi? Eğer öyleyse, o zaman, insan incelemesine dalın ve işleri hızlandırın. Otomatikleştirilmiş ve geçmeyen şeyler rapor edilmişse, o zaman bu, sanırım eklenti geliştiricisine daha hızlı bir yanıt olacaktır: hey, taramamızda bu ilk şeyleri belirledik, lütfen bunları çözün ve ardından işleri yoluna koymak için güncellenmiş bir zip dosyası gönderin.

Yani biraz otomasyon eklemek için çalıştıklarını biliyorum, bence bu yolda onlara yardımcı olmak için ne kadar çok şey yapabilirlerse o kadar iyi, çünkü bu noktada binin üzerinde eklenti var, birikmiş iş uzun ve yine , orada kimseye yardım etmiyorum. Yani evet, otomasyon üzerinde çalışıyorlar. Daha fazlasını yapmak istediklerini biliyorum ve eğer bu, birisinin otomasyon konusunda özellikle yetenekli olduğu ve katkıda bulunmak istediği bir alansa, eklenti inceleme ekibinin bu konuda biraz yardım almaktan memnuniyet duyacağını düşünüyorum. Durum buysa kesinlikle Slack'e ulaşın.

DP : WordCampUS'ta yaptığınız konuşma veya 10uP'nin açık kaynak alanında üzerinde çalıştığı bazı projeler hakkında sorularınız varsa, insanların size ulaşmasının en iyi yolu nedir? ?

JP : Elbette. Web sitem jeffpaul.com. Sunumum orada var, eğer sadece GPL'yi ararsanız, muhtemelen her halükarda ilk gönderilerden biri olacaktır. Aksi takdirde, e-postam [e-posta korumalı] , iş e-postam ve hemen hemen her sosyal ağ. WordPress.org, GitHub, Twitter, eğik çizgi X ve ben @Jeff Paul'um ve hepiniz beni sosyal ağlarda bu şekilde bulabilirsiniz.

DP : Benzer şekilde, eğer dinleyiciler GitHub'da 10uP çalışmalarının örneklerini bulmak isterse, bunun GitHub'da sadece 10uP olduğunu varsayıyorum.

JP : Doğru, evet, github.com/10up. Eklentilerimizin tüm depoları halka açıktır. Ekibimiz yeni konuları ve PR'ları yakından takip ediyor. Bunların hepsi Slack kanalımıza aktarılıyor, yani her türlü soru, her türlü tartışma orada açılıyor. Ekibimizin bunlara karşı oldukça duyarlı olması gerekir, ancak eğer değilse WordPress Slack'ten, Twitter'dan e-posta yoluyla bana ulaşarak bu işlerden herhangi birini yapabilirsiniz. Topluluktaki insanlarla açık kaynak sohbet etmekten her zaman mutluluk duyarım.

DP : Bugün bize katıldığınız için çok teşekkür ederim Jeff, sizinle konuşmak gerçekten harikaydı ve GitHub'ın çekme istekleri ve bu deneyimi otomatikleştirme konusunda yaptığı eylemler hakkında çok şey öğrendim. Bu çok faydalı oldu.

Geçen haftaki Press This bölümünü kaçırdıysanız, sitenizi MySQL 5.7'nin kullanım ömrünün sonuna hazırlamak için atabileceğiniz adımları ve MySQL 8'e nasıl hazırlanacağınızı Carmen Johnson ile konuştuk. kontrol edebiliriz ve elimizde çok daha fazlası var. Yazıya dökülmüş versiyonlarını bulmak istiyorsanız bunları TorqueMag.io'da bulabilirsiniz. WMR'deki bir WordPress topluluğu podcast'i olan Press This'i dinlediğiniz için teşekkür ederiz. Maceralarımızı Twitter'da Torque Mag'de takip edebilirsiniz.

Press This'e RedCircle, iTunes, Spotify veya favori podcasting uygulamanızdan abone olabilir veya bölümleri doğrudan WMR.fm'den indirebilirsiniz. Ben sizin sunucunuzum, Dr. Popular. WP Engine'deki görevim aracılığıyla WordPress topluluğunu destekliyorum ve bu topluluğun üyelerini her hafta PressThis'de öne çıkarmayı seviyorum.