Tasks

Tasks are the unit of work on Fundable Futures. A good task has a title, description, requirements, expected artifacts, and weight scores.

Anatomy of a task

• Title — short, specific. Say what the work delivers.
• Description — context and background. Implementation detail may live here; the requirements must not.
• Requirements — owner acceptance criteria (see below). Each one reads as what the owner will validate in the app — the WHAT, never the HOW.
• Expected artifacts — what "done" produces: a PR link, screenshots, a deployed URL.
• Weight scores — Importance, Urgency, Effort, Fun, Business Value, scored independently.
• Funding — optional bounty and payment milestones.

Requirements: the WHAT, never the HOW

Requirements are what you, the owner, will check when the work comes back. Write each one as an observable outcome:

✅ Good: "The login form rejects an invalid email with a visible error message." ✅ Good: "Exported CSV opens in Excel with dates in column A." ❌ Bad: "Add a regex check in validate_email/1." (names code) ❌ Bad: "Refactor the auth module to use the new pipeline." (says how, not what)

Rules:

• No file names, function names, or code-level instructions. Implementation detail belongs in the description at most.
• Keep each requirement under ~200 characters.
• One criterion per requirement — don't bundle three checks into one line.
• Requirements render verbatim in the app. What you type is what the reviewer sees.

Task lifecycle

pending → in_progress → awaiting_approval → completed

Status	Meaning
Pending	Open for bids and volunteers.
In progress	Someone is working it.
Awaiting approval	Work submitted, owner reviewing. Auto-approves after 3 business days if the owner doesn't act.
Completed	Approved. Fully read-only: no edits, no new proposals, no action buttons.

A rejected task returns to pending (or in-progress) with the owner's feedback attached — the review history stays visible so nothing is lost. Cancelled tasks keep their closing comments but accept no new work.

Weight scores

Score each weight independently, best guess:

Weight	Scale	Guidance
Importance	1–5	How much does this matter to the project?
Urgency	1–5	How soon does it need doing?
Effort	1–5	How much work? (Counts against the task — hard tasks sink.)
Fun	1–5	How enjoyable? Fun work attracts contributors.
Business Value	1–10	Revenue or strategic impact.

The project's sort template combines these into a composite score. You don't need to be precise — relative ordering is what matters.

Sub tasks

Tasks nest: a parent groups related sub tasks. The task detail page lists them under Sub Tasks at the bottom of the page. Use sub tasks when work naturally splits into pieces that can be done (and reviewed) separately.

Sub task vs requirement: a requirement is a check on one piece of work; a sub task is a separate piece of work with its own lifecycle, assignee, and review. When in doubt, if it could be done by a different person on a different day, it's a sub task.

Finished parents can be submitted for review while children remain open — the parent's review covers the parent's own requirements.

Bidding and proposals

Contributors engage with tasks in two ways:

• Volunteer — "I'll do this." Simple claim, no money discussed.
• Bid — a contributor proposes a single amount covering a task and its nested sub tasks ("bid on this workset"). Owners accept the bid they like.

Owners can also convert between tasks and requirements as scope clarifies — a requirement that grows teeth can become its own sub task.

AI workers

Tasks can be assigned to AI workers (the virtual "Moose (AI)" assignee). AI assignees never receive payments; their ratings are a loop-quality signal. AI authoring is available on software-industry tasks. See Agent Integration for the built-in ff-worker loop and how to wire your own agent.

Task detail page

• Edit — the pencil icon at the top (or tap the description) opens the edit form. Only on non-completed tasks.
• Floating + button — bottom right of the project page, opens the new task form.
• Requirements — checklists with per-requirement review feedback in the error color.
• Review history — every round of feedback, visible in the review modal.
• Artifacts — links, images, and files attached to the task. Image artifacts must be actual images; URL artifacts must be real URLs.

Next steps

• Reviewing work: Reviews
• Getting paid: Funding
• Working via API: API Reference