Source: https://www.drips.network/blog/posts/creating-meaningful-issues Source: https://docs.drips.network/wave/maintainers/participating-in-a-wave/#adding-issues-to-a-wave-program
- Real Impact — Must meaningfully improve the product, developer experience, or user outcomes. No filler work.
- Clear Context — Include the problem statement and "why" so contributors don't need to ask for clarification.
- Appropriate Scope — Completable within a single Wave cycle. Break large work into smaller related issues.
- Implementation Guidelines — Point to key files, edge cases, design constraints. Don't micromanage — give direction.
- Explicit Expectations — Define what "done" looks like: review criteria, required PR elements, acceptance conditions.
| Level | Points | When to Use |
|---|---|---|
| Trivial | 100 | Typos, small bug fixes, minor copy changes |
| Medium | 150 | Standard features or involved bug fixes |
| High | 200 | Complex features, refactors, or new integrations |
Tag honestly — inflated complexity repels serious contributors.
- Dashboard method: Maintainers → Issues dashboard → select issues → assign complexity.
- GitHub label method: Apply the Wave-specific label (e.g.,
Stellar Wave) directly on GitHub — only works after the repo is approved for that Wave.
- Issues not resolved in one Wave cycle automatically carry over to the next.
- Repo must be approved/onboarded before issues appear in the dashboard.
- Low-quality issues weaken the project's standing in the program.