source/contributors/non-code.md

---
title: Non-code contributions
tags: ["contributor","non-technical","non-code"]
---

While most people think of contributing *code* when they think of open
source participation, and most project contribution guides focus on
code contributions, there are many other ways to contribute to an open
source project.

{{% toc %}}

# Ways to contribute

There are many broad categories of non-code contributions. This list is
not comprehensive. Indeed, whatever your passion or expertise, there is
probably a place for you to participate in some Apache project, or at
the Foundation level.

## Documentation

All software needs some level of documentation. And documentation needs
writers, as well as readers. If you are a writer, particularly one with
an eye for information organization, your contributions will be welcome
in almost any project community.

There are often easy starter contributions, such as grammatical or
spelling improvements.

Great value to the project can come from
collaborating directly with the software developers to explain features
more deeply and create examples and demos. You can work with users to
help them describe their use cases.

Working with [testers](#testing) to describe their failure scenarios
and desired new functionality is a way to accelerate innovation, and
help developers understand vague tickets.

## Translation and localization

Most documentation of Apache projects is written in English. Providing
translation and localization of these documents is a great service to a
project, and helps adoption across a broader part of the world.

Translation and localization of the user interface helps
users have a better experience with the product, and that, in turn,
speeds adoption and user feed back, and, thus, further innovation.

Start by having a conversation with the project about whether they have
a translation/localization process in place. Tell them what language(s)
you speak, and, if possible, give some examples of your work.

Projects should consult with [Infrastructure](https://infra.apache.org/)
about what translation/localization tools are available and recommended.

## Design

Programmers usually design their project website, and the user interface
of their projects. There are opportunities for anyone with an artistic
eye to improve the user experience, both of the product itself, as well
as the website, logos, and other imagery around the project
ecosystem.

Designing banners for conferences, mascots, promotional materials, and
blog posts can make a project more engaging and welcoming. If the
project does not have a logo, work with the community to suggest
possible designs.

Helping improve the user interface of a product can result in more users
adopting it. Work with [testers](#testing) and
users to understand which parts of the product are harder to use or
understand.

Read through the website, and suggest places where images might make the
flow more attractive. Be sure that you use only images that you have an
appropriate license to use. For example, you can use images from
[photos.apachecon.com](https://photos.apachecon.com/) under a Creative
Commons license.

## Event support

Many ASF projects host their own events, either specific to one project,
or across several related projects. These events often rely on external
vendors or conference planners, but there is almost always an
opportunity for volunteer support in planning, promoting, and executing
these events. This may involve site planning, design and promotion,
speaker relations, sponsor acquisition and relations, or University 
outreach, among many other details.

If you have experience running events of any scale, your expertise will
be greatly appreciated by these projects.

You can see a list of approved upcoming events on the [Apache
events](https://events.apache.org/) website, or by searching for
`meetup` or `conference` on
[lists.apache.org](https://lists.apache.org).

## Community engagement

One of our mottos at Apache is "Community Over Code." A strong community
produces better software. Strong community is built on trust, respect,
and communication. These things don't just happen - they take hard work.

An important contribution that almost anyone can make is investing in
that community. A community engagement contribution might look like one
of the following:

* Identify first-time contributors and welcome them. Report (on the
  mailing list) each month which contributors had their first PR accepted;
  their first ticket opened; their first review to an open PR.
* Contact a new contributor after their second PR and try to understand
  who they are, why they are contributing, and what their goals are.
  Offer to review their PRs or introduce them to individuals who can.
* Celebrate contribution milestones. Use the GitHub API to determine
  when contributors make their 10th, or 100th, or 1000th commit.
* Be the first to answer user questions on the mailing list, with a
  friendly voice and helpful pointers. Encourage others to do the same.
  Quietly, off-list, admonish anyone who responds rudely, and
  encourage them to either do better, or let someone else answer those
  questions.

Friendly communities grow faster, and retain people longer.

## Vendor engagement

Many Apache communities rely on participation from the various vendors
that rely on our projects. While we recognize individual contributors
rather than their employers, it can be very valuable to do proactive
outreach to vendors to encourage them to participate in
community-friendly ways.

You can help by identifying companies that have products or services
that depend on a particular project, and reach out to them to understand
their needs, their frustrations, and their goals. Encourage them to
participate in the open to achieve those goals, and to talk about what
they are working on.

Projects should not be expected to care about a company's timelines,
customers, or product milestones. But understanding what those are may
result in helpful collaboration, either between individual contributors,
or between interested companies.

Have friendly conversations with the marketing departments from
interested companies about appropriate use of trademarks. This avoids
unpleasant situations later on, and thus helps avoid a company having a
negative interaction with our Trademarks team.

Identify a contact inside each participating vendor who is friendly to
Apache community norms, and offer to help them make the case for
upstream engagement -- sometimes an outsider voice can be more
persuasive.

Encourage your contacts to submit talks to the project's summit,
meetups, or other conferences, about their work in the project. That, in
turn, will help individual contributors to raise their profile within
their employer, and demonstrate the value of earning trust in open
source communities.

## Marketing and promotion

Getting the word out about a project is critical to building your
project's community. There are many ways to do this, and this is a
fantastic way to contribute to a project.

Does the project have a social media presence? Offer to help schedule
and produce content for those channels. Use those channels to promote
releases, features, and volunteer opportunities, as well as to
celebrate individual contributor milestones.

Conduct interviews with users who have interesting use cases, or vendors
who offer interesting services based on the project. Publish these
interviews (with [pictures](#design)!) on your project website or blog.

Work with Marketing & Publicity to find ways to promote your project.
Volunteer to do an interview with [PlusOne](https://plusone.apache.org)
and coordinate with the dev list to find the right people to be the
voice of your project.

## Testing

Your project probably has automated testing of some kind, but nothing
beats a human tester. Test, and [vote on](https://www.apache.org/legal/release-policy.html#release-approval), 
each release candidate, even if your vote isn't binding (i.e., if 
you're not a PMC member).

Download and try out the product, naively following the documentation to
ensure that it accurately represents how to get it working. Report your
findings in detail - what you tried, what happened, and how it differed
from what you expected to happen.

Try out documented features, and see if they work how you expect them
to. Report your findings.

Offer to interview new users to find out their experience - the
beginner's first experience with your project's product can be very
eyeopening to people who have been using it for years and know how to
get around limitations.

## Project management

Apache projects are not usually tied to release schedules,
feature sprints, and other strict planning that you see in
commercial software development efforts. However, there's often value in
having someone who tracks what is being worked on, what's next on the
roadmap, and what is intended to be in upcoming releases. Having project
management skills can be a real benefit to a project that has a diverse
set of developers all working on different things. A project manager can
coordinate communication to ensure that everyone is aware of priorities,
and help avoid conflicts.

If you're good at this kind of thing, come [talk with
us](https://lists.apache.org/list.html?dev@community.apache.org) and
we'll try to help you find a good match with a community seeking those
skills. If you're a project that needs this kind of help, let us know!

## Others

This is not an exhaustive list. There are other places that you can get
involved in a project, or in the Foundation. If you have expertise in
[law or trademarks](https://www.apache.org/legal/),
[accounting](https://treasurer.apache.org/), or public policy, your
expertise is welcome and sought after. Come talk to us about your
skills, and how you would like to participate, and we'll try to make
introductions.

# A word about AI

It can be tempting to use AI to analyze some portion of a project,
whether that's code or documentation, and then submit patches based on
what the AI says. We request that you carefully read the [ASF Generative
Tooling Guidance](https://www.apache.org/legal/generative-tooling.html)
before doing so. We also request that you remember that whatever the
source of your contribution, you are personally responsible for the
quality of that submission.

Many open source projects receive a huge number of AI-generated
contributions, and find that many of them are poor quality, or just
wrong. While it may be fine to use gen-ai as a starting place, **do
not** simply submit patches without first reviewing them yourself for
correctness and quality, as this will likely result in future
contributions being rejected, or even in your being blocked from further
participation.

# Recruiting and encouraging non-code participants

Projects should:

* Identify non-code contributions that are needed/wanted.
* Recognize and celebrate non-code contributors. Committer status is
  *NOT* just for coders!
* Consider giving specific titles to leaders in non-code areas. For
  example, identify (by name) your documentation team. Identify (by
  name) your community leadership team. Identify (by name) your social
  media coordinator.