jbonofre commented on code in PR #174: URL: https://github.com/apache/comdev-site/pull/174#discussion_r1544702478
########## source/pmc/community-growth.md: ########## @@ -0,0 +1,82 @@ +--- +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 road map + +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. + +## Periodically publish the open issue list + +Your ticket tracker allows you to periodically summarize the open Review Comment: I would also to propose: 1. Tag some issues as "low hanging fruits" allowing new contributor to ramp up 2. For PR and issue, I would propose to send reminder to PRs/issues not recently updated (to avoid stale ones) 3. A good idea is also default assignee that can provide a first answer and add other people to help the contributor (mentoring process). ########## source/pmc/community-growth.md: ########## @@ -0,0 +1,82 @@ +--- +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 road map + +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. Review Comment: Concretely, it's challenging to maintain a roadmap page on website. I would propose to "tag" issues with `proposal` or `roadmap` and extract/link this on website. That's probably the best approach to keep this up to date and accurate. ########## source/pmc/community-growth.md: ########## @@ -0,0 +1,82 @@ +--- +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 road map + +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. + +## 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. + +## 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 Review Comment: I would also mention the proposal process: how to submit new ideas ? how to be sure no proposal is lost or stale for too long ? how to track the proposals under discussion ? ########## source/pmc/community-growth.md: ########## @@ -0,0 +1,82 @@ +--- +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 road map + +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. + +## 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. + +## 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 Review Comment: Big +1 on this ! That's super important to have clarity here. ########## source/pmc/community-growth.md: ########## @@ -0,0 +1,82 @@ +--- +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 road map + +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. + +## 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. + +## 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 Review Comment: Yes, having testimonials or concrete use cases from users is more than welcome and it would help to promote the project. -- 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
