This URL is contribute without coding: issue triage, a design the ticket asked for, community answers, a named translation string. The merge or the accepted comment is still a contribution.
It is not a documentation PR. Named holes in docs/ live on make documentation your first open source contribution. This page will not rewrite that article.
You still need a specified thread, an unclaimed task, and a repo that still reviews. Unasked “I redesigned your logo” is not a strategy.
What non-code actually is
Application code is not the only merge.
Triage. Reproduce the bug, add the missing environment, close a duplicate with a link, confirm the issue is still valid. That work lives on the issue thread. Some projects merge a small repro fixture; most just need a comment they can act on.
Design. A mock, an icon, a screenshot of a broken layout, alt text they named. Only if an issue asked for that artifact. Drive-by Figma dumps get ignored.
Community. Answer a Discussions question you actually know. Welcome a newcomer the way CONTRIBUTING already described. Moderate spam if they gave you that role. “I can help with community” with no thread is not a PR.
Translation / i18n. One locale file or one string the issue named. Not a volunteer to “translate the whole app.” A later page owns the translation how-to; here it is just a lane.
Support that they asked for. A reproduction matrix, a “still fails on 3.2” note, a checklist they pasted in the template. You are filling their form, not inventing a support product.
It is not:
- Unasked README rewrites (that is the docs page if they named a hole; otherwise leave it)
- Restyling the marketing site because you have opinions
- A new mascot, color system, or “brand refresh”
- Opening twenty “is this still an issue?” comments as a portfolio
- AI-generated issue summaries nobody requested
Triage is a first contribution
Read the issue template. Then do one of these, once:
- Run the repro steps. Comment: OS, version, exact command, pass or fail. Attach the log they asked for.
- Mark a duplicate: link the older issue. Do not close unless they said contributors may close.
- Confirm the bug is gone on latest main. One line. Then stop.
Do not file a “meta” issue about how messy the tracker is. Do not re-label unless you have permission. Do not mass-close stale tickets.
A triage comment that a maintainer used is real work. Treat it like a small PR: specified, on-thread, done.
Design only on a named ticket
Look for labels like design, ui, ux, needs mock, plus a body that says what to produce.
Ship the file they named (PNG in docs/, SVG in assets/, a link they already use). Keep their existing visual language. Do not attach a 40-frame prototype for “the button is misaligned.”
If there is no issue, there is no design contribution. Pitch in Discussions only if they invite pitches.
Community and translation, kept small
Community work is on their Discussions, Discord, or issue tracker — not a blog post about the project on your site.
Answer the question. Link the docs page if it already exists. Do not become unofficial support for a product you do not run.
For translation: one .po / locale JSON / named string. Follow their i18n guide. Do not machine-translate the README and open a PR. Skip the whole-app offer.
Find the thread on a live hub
Non-code tickets still show up next to code tickets. Filter, then read the body for triage / design / i18n / “needs reproduction”:
How to hunt labels: how to find good first issues. How to know it will land: how to pick an issue that will get merged. If the work is a docs file, switch to documentation-first contribution.
When the artifact is a PR, use the first pull request guide. When it is a comment, one comment is the patch. Claim only if they want a reservation.
Related
- Make documentation your first open source contribution — named hole in
docs/, not this roundup - How to find good first issues — live hubs, then the thread
- How to pick an issue that will get merged — specified, unclaimed
- First pull request guide — when the non-code work is still a diff
FAQ
Does a comment count as a contribution? Yes if the project used it: a repro, a duplicate link, a confirmed-fixed note they asked for. A “following” comment does not.
Can I skip Git entirely? For triage and Discussions, often. For design assets and locale files you still open a PR.
Is rewriting the README non-code? If they named a hole, that is documentation-first. Unasked README nits still get closed.
Should I offer to “handle community”? No. Answer one named thread. Roles come later.
Where do I look? Live hubs on Help Wanted, then read for triage, design, i18n, or needs-repro — not a gist of famous names.
The job is: one specified non-code task, not a docs rewrite, not a surprise rebrand. That is the whole page.