rbowen commented on code in PR #209:
URL: https://github.com/apache/comdev-site/pull/209#discussion_r2239850089
##########
source/pmc/community-growth.md:
##########
@@ -3,90 +3,90 @@ title: Community Growth
tags: ["pmc","committers","community"]
---
-Growing your project community takes work. This document makes practical
-suggestions of how to encourage people to get involved in your project.
+Building a thriving project community requires intentional effort.
+This guide provides practical strategies to attract and engage
+contributors in your project.
{{% toc %}}
## Publish a roadmap
-Volunteers can work on whatever they want, and so we have a tendency to
-not want to tell them what to work on. However, publishing a roadmap, or
-even a wishlist of features or improvements that are desired, can give
-people an idea of where they might be able to get involved.
+While volunteers choose their own contributions, providing direction
+helps them find meaningful ways to get involved. Publishing a roadmap
+or wishlist of desired features and improvements gives potential
+contributors clear entry points.
-This also gives a clear sense that the project has ambitions, and is
-going somewhere, rather than that it is stagnating.
+A roadmap demonstrates that your project has clear goals and
+momentum, signaling growth rather than stagnation.
-It can be very challenging to keep a roadmap current. Having a mechanism
-for tagging open issues with `proposal` or `roadmap` and
-automatically extracting that into a web page can help with this.
+Keeping a roadmap current can be challenging. Consider implementing
+a mechanism for tagging open issues with `proposal` or `roadmap`
+labels and automatically extracting them into a web page to
+streamline this process.
## Periodically publish the open issue list
-Your ticket tracker allows you to periodically summarize the open
-issues. Sending this to the dev@ list reminds people that there are
-things to work on, and gives them permission, and encouragement, to do
-so.
+Regularly share summaries of open issues from your ticket tracker
+with the dev@ list. This reminds contributors that work is available
+and encourages them to get involved.
Consider creating [good first
-issues](/committers/good-first-issues.html) as a place for new
-contributors to get started.
+issues](/committers/good-first-issues.html) as entry points for new
+contributors.
## Clearly document contribution processes
-Double-check that your "how to contribute / build / test / submit PR"
-documentation is super clear and easy to follow. Long-time committers
-on a project often forget all the institutional knowledge they just
-"know", so ensuring the "getting started" document actually works
-for newcomers is always worth looking at.
+Ensure your contribution documentation -- covering how to contribute,
+build, test, and submit pull requests -- is clear and easy to follow.
+Experienced committers often overlook the institutional knowledge
+they take for granted, so regularly review your "getting started"
+documentation from a newcomer's perspective.
-Encourage newcomers to talk about, and document, their pain points
-during their first contributions, and work towards fixing, or at least
-documenting, those things.
+Encourage new contributors to share and document their pain points
+during their first contributions. Work toward addressing or at least
+documenting these challenges to improve the experience for future
+contributors.
+
+Do not neglect non-code contributions as you think about where people
+can get involved.
## Publish your contributor ladder
-A [contributor ladder](/contributor-ladder.html) is a description of
-various levels of access and responsibility a contributor can progress
-through in your project. This is typically the path from contributor, to
-committer, to PMC member.
+A [contributor ladder](/contributor-ladder.html) describes the various
+levels of access and responsibility contributors can progress through
+in your project -- typically from contributor to committer to PMC member.
-Explicitly publish your requirements for each step. For example, if you
-require ten non-trivial patches accepted, or perhaps 3 months of
-involvement, document this on your website so that people don't feel
-that it's random, or that they are driving in the dark.
+Clearly document requirements for each level. For example, if you require
+ten substantial patches or three months of involvement, publish these
+criteria on your website. This prevents contributors from feeling the
+process is arbitrary or unclear.
-Consider lowering your bar to entry. Remember that while the risk of
-inviting someone "too early" is that they'll break something, that's why
-you have version control - so you can revert those changes. However, the
-risk of inviting someone too late is that they'll give up and go away
-forever.
+Consider lowering your entry barriers. Remember that inviting someone
+"too early" risks temporary issues that version control can fix, but
+inviting someone too late risks losing them permanently.
## Engage with big users
-If you are aware of companies that rely on your project, encourage them
-to think about what they would do if the project retired. This often
-leads to those companies realizing the value they get "for free", and
-starting to contribute in some way.
+Reach out to companies that depend on your project and ask them to consider
Review Comment:
That's fair. I'll attempt to rephrase that.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@community.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
