Summary
Add a focused landing-page section that explains how Gibwork keeps funded tasks moving after submissions arrive: clear requirements, proof quality, review cadence, creator activity, and approval expectations.
This proposal is intentionally narrower than the existing landing-page proposals about FAQ wording, proof loops, or general task quality. It focuses on a visible marketplace problem: contributors need to know what makes a submission reviewable, while creators need to know how to avoid large queues of unclear submissions.
Related funded Gibwork task:
https://app.gib.work/tasks/b7c2a3c9-c412-4613-9cfb-d8a5f54d14b7
Current observation
The funded landing-page task itself is a useful example of the problem. At the time of review, the public task page shows:
- reward pool: 350 USDC;
- task is open;
- proposal-only submission is allowed through a public GitHub issue URL;
- pending submissions: 99;
- rejected submissions: 12;
- approved submissions: 0;
- health label: stale.
That does not mean the task is bad. It means the landing page has an opportunity to teach both sides of the marketplace how to create a healthier review loop before users enter the app.
The public homepage currently positions Gibwork broadly as "Find Talent, Find Work" and describes freelance opportunities and token payments. That is accurate, but it does not yet explain the operational layer that makes a funded task successful: precise requirements, reviewable proof, creator review cadence, and payout readiness.
Problem
New contributors can see a USDC reward and submit quickly, but may not understand:
- what proof is strong enough for review;
- whether a public GitHub issue, social post, screenshot, demo, or PR is expected;
- how many other submissions are already pending;
- whether the creator is actively reviewing;
- that payout depends on approval, not just submission.
New task creators may also under-specify:
- what counts as an accepted deliverable;
- what a good submission should include;
- when they will review;
- why a submission may be rejected;
- whether a task should be verified-only, capped, or split into smaller tasks.
This creates avoidable friction: many low-context submissions for creators, and unclear odds for contributors.
Proposed enhancement
Add a landing-page section called:
Faster reviews start with clearer proof
Suggested placement: after the first marketplace/how-it-works section, before broad CTAs.
Section copy
Funded work moves faster when the task and the proof are both clear. Gibwork helps creators define reviewable requirements and helps contributors submit evidence that can be approved without back-and-forth.
Three-card layout
+----------------------------------------------------------------+
| Faster reviews start with clearer proof |
| Funded work moves faster when task requirements and proof align. |
+----------------------+----------------------+------------------+
| 1. Define acceptance | 2. Submit evidence | 3. Review openly |
| Exact deliverable, | Public URL, summary, | Creator cadence, |
| proof format, due | screenshot/demo/PR, | approval criteria,|
| date, rejection risk | and task fit notes | payout readiness |
+----------------------+----------------------+------------------+
| Example task health panel |
| $350 USDC - Open - 99 pending - 12 rejected - 0 approved |
| What this teaches: add clearer proof examples or split task |
+----------------------------------------------------------------+
Mobile layout
Faster reviews start with clearer proof
[Define acceptance]
[Submit evidence]
[Review openly]
[Example task health panel]
[Browse funded work] [Create a clearer task]
Suggested content details
Creator guidance
- State the exact deliverable in one sentence.
- Add an example of an acceptable submission.
- Name required proof: issue URL, PR URL, screenshot, public post, recording, document, or demo.
- Define rejection reasons before work starts.
- Set review cadence, such as "reviewed every 48 hours" or "winners selected after deadline."
- Cap submissions or split the task if the queue gets too large.
Contributor guidance
- Confirm the task is still open and active.
- Read acceptance criteria before starting.
- Submit one public proof link, not a vague claim.
- Include a short summary of what was done and why it matches the requirements.
- Avoid duplicate or generic submissions.
- Understand that payout follows approval.
Marketplace health signals
Where data is already public, show or explain:
- reward amount and payout asset;
- deadline;
- open/closed status;
- verified-only requirement;
- pending, rejected, and approved counts;
- creator activity or stale status;
- submission cap or minimum submission amount;
- proof format.
The first version can use static copy and a static example panel. A later version can use live public task data if the marketing page already has a stable data path.
Why this is different from existing proposals
Existing related issues already cover useful areas:
This proposal focuses specifically on review velocity and queue health: how creators and contributors reduce stalled or unreviewable submissions. It turns a visible marketplace pain point into landing-page education without requiring a full redesign.
Why this improves the landing page
- It sets more realistic expectations before users enter the app.
- It helps contributors self-filter and submit stronger proof.
- It helps creators write tasks that are easier to review.
- It makes Gibwork feel more operationally trustworthy, not just reward-driven.
- It can reduce low-effort submissions on high-reward tasks.
- It connects the marketing page to real marketplace states users already see in the app.
Acceptance criteria
- Add a visible landing-page section about reviewable proof, creator review cadence, and payout readiness.
- Include guidance for both creators and contributors.
- Include an example task-health panel with reward, open status, pending count, rejected count, approved count, and stale/active language.
- Avoid promising guaranteed payment; clearly tie payout to approval.
- Keep the section responsive: three compact cards on desktop, stacked cards on mobile.
- Use existing landing-page visual patterns and copy tone.
- Do not introduce a new dependency or a major redesign.
Suggested CTAs
- Primary:
Browse funded work
- Secondary:
Create a clearer task
Summary
Add a focused landing-page section that explains how Gibwork keeps funded tasks moving after submissions arrive: clear requirements, proof quality, review cadence, creator activity, and approval expectations.
This proposal is intentionally narrower than the existing landing-page proposals about FAQ wording, proof loops, or general task quality. It focuses on a visible marketplace problem: contributors need to know what makes a submission reviewable, while creators need to know how to avoid large queues of unclear submissions.
Related funded Gibwork task:
https://app.gib.work/tasks/b7c2a3c9-c412-4613-9cfb-d8a5f54d14b7
Current observation
The funded landing-page task itself is a useful example of the problem. At the time of review, the public task page shows:
That does not mean the task is bad. It means the landing page has an opportunity to teach both sides of the marketplace how to create a healthier review loop before users enter the app.
The public homepage currently positions Gibwork broadly as "Find Talent, Find Work" and describes freelance opportunities and token payments. That is accurate, but it does not yet explain the operational layer that makes a funded task successful: precise requirements, reviewable proof, creator review cadence, and payout readiness.
Problem
New contributors can see a USDC reward and submit quickly, but may not understand:
New task creators may also under-specify:
This creates avoidable friction: many low-context submissions for creators, and unclear odds for contributors.
Proposed enhancement
Add a landing-page section called:
Suggested placement: after the first marketplace/how-it-works section, before broad CTAs.
Section copy
Three-card layout
Mobile layout
Suggested content details
Creator guidance
Contributor guidance
Marketplace health signals
Where data is already public, show or explain:
The first version can use static copy and a static example panel. A later version can use live public task data if the marketing page already has a stable data path.
Why this is different from existing proposals
Existing related issues already cover useful areas:
This proposal focuses specifically on review velocity and queue health: how creators and contributors reduce stalled or unreviewable submissions. It turns a visible marketplace pain point into landing-page education without requiring a full redesign.
Why this improves the landing page
Acceptance criteria
Suggested CTAs
Browse funded workCreate a clearer task