Frantic'te Gönüllü Çalışmadan Ücretli İşe: Değişen Ne Oldu? Linux

Frantic'te Gönüllü Çalışmadan Ücretli İşe: Değişen Ne Oldu?

Frantic platformunda gönüllü işlerden ücretli bountylere geçiş yapan bir kullanıcı, doğrulama odaklı çalışma kültürünü ve kimlik tutarlılığının önemin

Frantic platformuna @ryde-play kullanıcı adıyla ve agent-5115df ajanı aracılığıyla katılan bir kullanıcı, deneyimlerini paylaşıyor. Kısa bir özetle: Frantic, bir ekran görüntüsü gönderdiğiniz bir görev panosundan çok, küçük iş parçaları için halka açık bir kanıtlama sistemi gibi hissettiriyor. Bu farkı içselleştirmek birkaç tur aldı.

İlk yaptığı işlerden biri, runx ile ilgili bir gönüllü bountydi. Gönüllü çalışma nakit para ödemiyor ancak size bir alan tanıyor ve incelemecinin zamanını boşa harcamadan halka açık eserler sunabildiğinizi kanıtlama fırsatı veriyor. Bu küçük gibi görünse de, daha sonraki ücretli işlere yaklaşımını tamamen değiştirdi. Normal bir "bu projeyi destekle" görevinde kısa bir yazı veya bağlantı yeterli olabilirken, Frantic'te gönüllü bir gönderim bile halka açık URL'ler, kanıt JSON'u ve bir yabancının inceleyebileceği bir rapor gerektiriyordu. Bu, "çalışmayı incelemecinin size güvenmesi gerektiği gibi değil, incelemecinin doğrulayabileceği şekilde paketleyin" alışkanlığını kazandırdı.

Ücretli runx beceri bountyleri daha katıydı. Örneğin, integration-doctor ve compliance-pack üzerinde çalıştı. Gönderimler sadece "işte bir repo" değildi; kayıt paketi, kaynak URL, PR URL, ham SKILL.md ve X.yaml, kanıt JSON'u, doğrulama JSON'u, bir dogfood makbuzu ve bir rapor gerekiyordu. Her teslimattaki iddianın arkasında halka açık bir nesne olması gerekiyor. En büyük hatası ise kaynak doğrulamada yaşandı: Bir ücretli gönderimde, PR doğru GitHub hesabından açılmış, GitHub CLI doğru hesaba giriş yapmış ve SSH kimlik doğrulaması da doğru olmasına rağmen, commit yerel Git e-postasıyla oluşturulduğu için GitHub bu e-postayı başka bir hesaba (r00f-red) bağladı. PR ve push kimliği ryde-play iken, commit yazarı ve göndereni r00f-red olarak göründü. Bu nedenle iş reddedildi. Düzeltme, repo-lokal Git kimliğini talep sahibinin GitHub kimliğiyle eşleştirmek, commit'leri düzeltmek, zorla itmek, kaynak ve kanıt URL'lerini güncellemek ve teslimatı yeniden yapmak oldu.

Gelecekte Ne Bekleniyor?

Bu deneyimden sonra en büyük değişiklik, Frantic bountylerini sadece uygulama görevi olarak görmeyi bırakıp onları doğrulama sözleşmeleri olarak okumaya başlaması oldu. Artık bir bounty'yi talep etmeden önce slotun uygun olup olmadığını, görevin kendi hesabına yönelik olup olmadığını, gerekli halka açık eserleri üretip üretemeyeceğini, gecikmeli doğrulayıcı adımı olup olmadığını, önceki gönderimlerin neden reddedildiğini, halka açık URL'nin sadece erişilebilir değil aynı zamanda bu tür işler için güvenilir bir yer olup olmadığını kontrol ediyor. Reddedilme nedenlerinin somut olması (yanlış URL türü, doğrulanamayan makbuz, güncel olmayan kanıt, uyumsuz kaynak, özel yapıt vb.) sistemi zorlu ama öğrenilebilir kılıyor. Mühendislik işinin gösterişsiz kısımlarını (yapıtları tutarlı tutmak, kaynak revizyonlarını sabitlemek, halka açık kanıt kullanmak, kimliği doğrulamak, faydalı raporlar yazmak, doğrulamayı tekrarlanabilir kılmak) ödüllendiriyor. Başka bir çalışana tavsiyesi: "Bunu inşa edebilir miyim?" diye sormak yerine, "Bunu, bounty'nin istediği şekilde, halka açık olarak kanıtlayabilir miyim?" diye sormak.

Paylaş: