Open-Source Web3 Project

Server structure

Overview

For a codebase with outside contributors, where the hard problem is not attracting them but keeping them. #good-first-issues is read-only and curated, holding only issues a maintainer has actually confirmed are self-contained and currently accurate, because the fastest way to lose a first-time contributor is a starter issue that turns out to need three days of context. #contributing-help is where they ask, and #claim-an-issue prevents two people silently doing the same work. RFCs is how design happens in the open: #rfc-drafts for proposals in progress, #rfc-discussion, and #accepted-rfcs as a read-only record, so the reasoning behind an architectural decision survives the people who made it. Development splits by area — #core, #tooling, #clients and #testing — and #maintainer-calls carries agendas and notes, published so contributors outside the call are not second-class. Grants and Funding is the part specific to this ecosystem: #grant-opportunities, #grant-applications where teams write in public, and #funded-work with progress reports, because grant work done privately is how an ecosystem loses track of what it paid for. Security has its own boundary: #security-policy states how to report privately and what never to post publicly. Nothing here discusses price, and the rules say so plainly.

When to use it

Open-source projects in this ecosystem attract drive-by contributors and lose them: the starter issues are stale, two people do the same work, design decisions happen in a call nobody outside heard, and grant-funded work disappears into private repositories. This layout curates first issues, has contributors claim work, keeps design in public RFCs with a permanent record, and requires funded work to report progress where the ecosystem can see it.

What makes it different

• Good first issues are curated and confirmed current, which is what retains a first contributor.
• Issues are claimed in public, so two people never silently build the same thing.
• Accepted RFCs are a permanent record, so architectural reasoning outlives its authors.
• Grant-funded work reports progress publicly rather than disappearing into a private repository.

Recommended Vetox setup

• Notifications

  Point Notifications at the repository so #commits-and-releases fills without a maintainer relaying every merge.

• Self-Roles

  Post a Self-Roles panel in #your-area so an RFC in tooling pings the people who work on tooling.

• Tickets

  Point Tickets at #security-policy so a vulnerability report reaches maintainers privately rather than in public.

• Auto-Mod

  Run Auto-Mod across public channels, since open-source project servers attract impersonation and fake-airdrop links.