justinmclean commented on code in PR #174: URL: https://github.com/apache/comdev-site/pull/174#discussion_r1547094290
########## source/pmc/community-growth.md: ########## @@ -0,0 +1,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. + +## 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. + +This also gives a clear sense that the project has ambitions, and is +going somewhere, rather than that it is stagnating. + +It can be very challenging to keep a roadmap current. Having a mechanism +for tagging open issues with `proposal` or `roadmap` and +automatimatically extracting that into a web page can help with this. + +## 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. + +Consider creating [good first +issues](/committers/good-first-issues.html) as a place for new +contributors to get started. + +## 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. + +Encourage newcomers to talk about, and document, their pain points +during their first contributions, and work towards fixing, or at least +documenting, those things. + +## 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. + +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. + +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. + +## 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. Review Comment: Perhaps also list ways companies to help out by providing in-kind contributions e.g. testing infrastructure), developer time or help with marketing/website? -- 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
