Compensation Request - Onboarding Project (Sleety)

Requesting: $18,300 USDC

  • Project: Onboarding
  • Contributor: Sleety (Gavin)
  • Original approval: February 2025 (via Snapshot)
  • Period covered: March 2025 – April 2026

Overview

This is a request to draw the $18,300 originally approved for the Onboarding Project in February 2025. No payments have been drawn from this allocation to date; the funds have remained in the project wallet throughout.

The project ran ~13 months against a ~5-month proposal, and the original funding window expired June 15, 2025. This document describes what was delivered, where the work diverged from the original proposal, and how the budget breaks down.


Deliverables

Milestone 1 - Website

Updates across Arrow-air/website, Website, including the foundational structure and dedicated page templates for Homepage, Community, DAO Governance, Engineering, Bounties and Quiver.

Milestone 2 - Documentation Platform

The Arrow docs site is built and staged at stg.arrowair.com/docs, ready to go live. It runs on a custom Docusaurus 3 instance with a design language developed specifically for Arrow - utilitarian, retro-technical, and on-brand. The build includes:

  • Custom navbar, sidebar, and content layout
  • Full dark mode with theme toggle
  • Mobile-responsive layout
  • Custom animated icons and back-to-top component
  • Bespoke styling for code blocks, tables, images, and admonitions
  • Multi-instance tabbed setup designed to scale across future Arrow projects

Milestone 3 - Onboarding Documentation

28 pages across 5 sections - Overview, Contributing, Community, Guides, DAO - each with a section landing page and child pages beneath. Existing material has been reviewed, restructured and brought in line with the style guide. Ongoing per-page maintenance sits outside this scope and is best handled as a distributed community practice. I am satisfied we have an industry-leading foundation on which to build our future docs.

Quiver Website

Not part of the original proposal. I picked up its development as an extension. Roughly one month of additional work.


Variances From the Original Proposal

A few notable deltas between what was proposed and what was built:

  • Documentation platform. The original proposal specified a hosted GitBook instance. Mid-project we moved to Docusaurus 3 - open source, self-hosted, no recurring subscription. The build is fully custom: bespoke design system, dark mode, mobile responsiveness, and a multi-instance setup intended to scale across Arrow projects. The trade-off is more development labor up front in exchange for no ongoing subscription cost and full control over the design and architecture.
  • Information architecture. The docs work expanded beyond a content refresh into the structure of a multi-project future for Arrow - section organisation, navigation patterns, and templates that other projects can plug into.
  • Quiver website. Added during the project as described above; ~1 month of additional work.
  • Timeline. ~13 months vs. ~5-6 proposed.

Budget Reconciliation

Category Budgeted Notes
Labor (Milestone 1 - Website) $4,500 Delivered
Labor (Milestone 2 - Docs) $4,000 Delivered (staged, ready to deploy)
Docs Development Labor $3,800 Reallocated from GitBook subscription (see below)
Labor (Milestone 3 - Onboarding Docs) $4,000 Delivered
Contributor Incentive Pot $600 Available for distribution
Miscellaneous $1,400 Webflow, tooling
Total $18,300

The original proposal budgeted $3,800 for an annual GitBook subscription. With the move to Docusaurus, that line has been reallocated within the same budget to cover the additional development labor a custom implementation requires. The total remains $18,300.

Note: $600 contributor pot will be allocated (by Sleety) within one week of disbursement of funds for a number of contributors who helped with copy and media for the site and docs.


What’s Next

Taking the docs site live is the immediate next step. Beyond this request, I’ll be happily continuing my contributions to Arrow’s documentation UX, contributor onboarding, and community infrastructure. If there are no immediate objections to this proposal, I would like to take this to a Snapshot vote 3 days from the date of this forum post.

3 Likes

A few things I’ve taken away from this one.

The biggest thing for me is how much my own proposal grew and shifted from what was originally written down. The docs work in particular needed way more back-and-forth with the community/tech-specialists than I’d budgeted for. Writing copy that speaks for everyone in Arrow turned out to be genuinely hard, and I underestimated how much of the project that would end up being.

I also ended up working all three milestones in parallel rather than sequentially, which was bad planning on my side, although honestly I’m not sure it was fully avoidable given how the pieces leaned on each other. Either way, it’s a big part of why the timeline slipped.

What’s been on my mind more than any of that, though, is whether hard deadlines are the right primary rail for projects this size. If a contributor ends up three months past their expiry, the DAO is in an awkward spot: pay for work that’s outside the window, or walk away from work that’s already been done. Neither feels great, and I think there’s a cleaner way.

Roughly: break grants of this size into smaller sprint-sized deliverables, each scoped to a single PR (or equivalent). Have the acceptance criteria for each one written into the proposal itself, tied to something visible. Funds unlock per-PR as each lands, rather than against one end-date (maybe something v2 tokenomics could even automate). And a mandatory check-in every week or two, via PR, for the life of the grant. In the age of AI this is more important then ever, since even though amazing things can be produced quickly, it can come with an amazing amount of slop that can be hard to review. Smaller chunks makes this manageable for both the contributor and the reviewer. Also, they give more contribution/collaborations opportunities for other contributors because the work is live, fresh and interactive.

If work is completed this way, nobody’s holding a big lump sum against a slipping deadline, and if the work starts drifting from the proposal it gets caught early rather than at expiry.

These come from someone who learned them the hard way on this project, for what that’s worth. They’re the things I’d have wanted to know going in, and I hope they’re useful as we keep working out better guardrails for grants and bounties. :seedling: