This is an automated email from the ASF dual-hosted git repository.

rbowen pushed a commit to branch non-code
in repository https://gitbox.apache.org/repos/asf/comdev-site.git

commit 7fcb5568b4778ee108bb252b8e8a720c7c391585
Author: Rich Bowen <[email protected]>
AuthorDate: Wed Oct 1 12:21:54 2025 -0400

    Draft doc discussing non-code contributions.
---
 source/contributors/non-code.md | 141 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 141 insertions(+)

diff --git a/source/contributors/non-code.md b/source/contributors/non-code.md
new file mode 100644
index 00000000..de5c710d
--- /dev/null
+++ b/source/contributors/non-code.md
@@ -0,0 +1,141 @@
+---
+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
+
+Most open source projects are designed by programmers. 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 assorted 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.
+
+Working with the developers to improve the user interface of a product
+can drive greater adoption of the product. Work with testers 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
+
+## Community engagement
+
+## Vendor engagement
+
+## Marketing and promotion
+
+## Testing
+
+## Project management
+
+Apache projects are not usually tied to strict release schedules,
+feature sprints, and other strict planning regiments 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 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/[email protected]) 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
+
+* Legal
+* Trademarks
+* Accounting
+* ...
+
+# 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.

Reply via email to