1. Dlaczego nagrody (bounties) są lepsze niż „kto chce pomóc?”
Wezwania do wolontariatu generują jednorazowe odpowiedzi. Członek pomaga raz, czuje się dobrze i wraca do biernego obserwowania — ponieważ nie było żadnego zapisu, nagrody ani kontynuacji. Nagroda (bounty) zamienia to samo zapytanie w publiczny, wyceniony, stanowy kontrakt: tytuł, nagroda, właściciel, status i historię, którą każdy na serwerze może zobaczyć.
Cena jest kluczowa. Nagroda w wysokości 20 euro za zadanie związane z dokumentacją sygnalizuje, że praca ma realną wartość. Członkowie, którzy nigdy nie zgłosiliby się na ochotnika, reagują na wycenioną pracę, ponieważ wyceniona praca usuwa niepewność, czy ich wysiłek zostanie doceniony.
2. Cykl życia: cztery komendy, pięć stanów
Sovereign implementuje nagrody (bounties) jako ścisłą maszynę stanów: OPEN → IN_PROGRESS → REVIEW → PAID, z wyraźną ścieżką CLOSED dla porzuconych postów. Każdy z połączoną tożsamością może stworzyć nagrodę za pomocą /bounty create <Title> | <Amount> (minimum 5 EUR, przechowywane w centach), przeglądać otwarte za pomocą /bounty list, podjąć jedną za pomocą /bounty claim <ID> i przesłać ukończoną pracę za pomocą /bounty done <ID>.
Maszyna stanów wykonuje za Ciebie pracę moderacyjną. Nagroda nie może zostać podjęta dwukrotnie, twórca nie może podjąć własnego postu, a tylko przypisany pracownik może przesłać pracę. Każde przejście powiadamia właściwą osobę: twórca otrzymuje DM, gdy jego nagroda zostanie podjęta, i ponownie, gdy praca zostanie przesłana, a zgłoszenie trafia do Dashboard Exchange w celu zatwierdzenia.
Środki są uwalniane tylko po wyraźnym zatwierdzeniu w Dashboard. To utrzymuje pętlę ludzką tam, gdzie ma to znaczenie — zaufanie — i zautomatyzowaną wszędzie indziej.
// Command routing and the guard clauses that make the state machine safe
switch (action) {
case 'create': return await createBounty(tenantId, member.id, args); // -> OPEN
case 'list': return { reply: await listBounties(tenantId) }; // 5 latest OPEN
case 'claim': return await claimBounty(tenantId, member.id, args); // OPEN -> IN_PROGRESS
case 'done': return await completeBounty(tenantId, member.id, args); // IN_PROGRESS -> REVIEW
}
// Guards enforced inside the transition functions:
// - status must match the expected state or the command is rejected
// - creatorId !== workerId (no self-claims)
// - only the assigned workerId may call /bounty done
// Funds are released after owner approval: Dashboard > Exchange (REVIEW -> PAID)3. Dostosowywanie nagród (bounties) tak, aby budowały retencję, a nie tylko produktywność
Skuteczne nagrody (bounties) są małe, konkretne i możliwe do zdobycia w jeden wieczór. Społeczność, która publikuje trzy lub więcej nowych nagród tygodniowo, daje członkom stały powód do sprawdzania serwera: otwarta praca to regularnie odświeżany powód do powrotu, co jest dokładnie zachowaniem, które inżynierowie retencji starają się wytworzyć.
Strategia kumulacyjna polega na publikowaniu nagród za rzeczy, które usprawniają działanie społeczności: skrypty onboardingowe, dokumentację, tworzenie klipów, pokrycie moderacyjne, logistykę wydarzeń. Każda ukończona nagroda jest trwałym zasobem, a nie jednorazowym produktem.
Minimum odfiltrowuje szum. Nagroda poniżej 5 EUR nie jest warta narzutu maszyny stanów ani uwagi, którą odciąga od prawdziwej pracy. Dolny limit ceny, podobnie jak brama REVIEW, to kontrola oszustw i spamu przebrana za zasadę produktu.