1. Varför bounties slår ”vem vill hjälpa till?”
Frivilliga upprop får engångssvar. En medlem hjälper till en gång, känner sig nöjd och återgår till att vara passiv – eftersom det inte fanns någon registrering, ingen belöning, ingen uppföljning. En bounty förvandlar samma förfrågan till ett offentligt, prissatt, tillståndsbaserat kontrakt: titel, belöning, ägare, status och historik som vem som helst på servern kan se.
Prissättningen är poängen. En bounty på 20 euro för en dokumentationsuppgift signalerar att arbetet har ett verkligt värde. Medlemmar som aldrig skulle ställa upp frivilligt svarar på prissatt arbete, eftersom prissatt arbete tar bort tvetydigheten kring huruvida deras insats kommer att uppmärksammas.
2. Livscykeln: fyra kommandon, fem tillstånd
Sovereign implementerar bounties som en strikt tillståndsmaskin: OPEN → IN_PROGRESS → REVIEW → PAID, med en explicit CLOSED-väg för övergivna inlägg. Vem som helst med en länkad Identity kan skapa en bounty med /bounty create <Title> | <Amount> (minimum 5 EUR, lagrat i cent), bläddra bland öppna med /bounty list, ta en med /bounty claim <ID>, och skicka in färdigt arbete med /bounty done <ID>.
Tillståndsmaskinen sköter modereringsarbetet åt dig. En bounty kan inte tas två gånger, skaparen kan inte ta sitt eget inlägg, och endast den tilldelade arbetaren kan skicka in. Varje övergång meddelar rätt person: skaparen får ett DM när deras bounty tas och igen när arbetet skickas in, och inskickningen hamnar i Dashboard Exchange för godkännande.
Medel släpps först efter explicit godkännande i Dashboard. Det håller loopen mänsklig där det är viktigt – förtroende – och automatiserad överallt annars.
// 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. Justera bounties så att de bygger retention, inte bara output
Bounties som fungerar är små, specifika och möjliga att slutföra på en kväll. En community som publicerar tre eller fler nya bounties i veckan ger medlemmarna en ständig anledning att kolla servern: öppet arbete är en regelbundet uppdaterad anledning att komma tillbaka, vilket är exakt det beteende som retention engineers försöker skapa.
Den kumulativa effekten är att publicera bounties för saker som gör communityn bättre att driva: onboarding scripts, dokumentation, klipptillverkning, modereringstäckning, evenemangslogistik. Varje slutförd bounty är en permanent tillgång, inte en engångsleverans.
Minimumet filtrerar bort brus. En bounty under 5 EUR är inte värd tillståndsmaskinens overhead eller den uppmärksamhet den stjäl från verkligt arbete. Prisgolvet, liksom REVIEW-grinden, är bedrägeri- och skräppostkontroll förklädd till en produktregel.