[PR] Adds practical community building advice. [comdev-site]
rbowen opened a new pull request, #174: URL: https://github.com/apache/comdev-site/pull/174 Adds a new document, inspired by conversations with one of our projects in this situation, suggesting practical steps that a project can take to attract new contributors. -- 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
Re: [PR] Adds practical community building advice. [comdev-site]
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 p
Re: [PR] Adds practical community building advice. [comdev-site]
justinmclean commented on code in PR #174: URL: https://github.com/apache/comdev-site/pull/174#discussion_r1547092975 ## 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. Review Comment: GitHub automatically does this for you https://github.com/apache/pekko/contribute just substitute peeks for any Apache 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
Re: [PR] Adds practical community building advice. [comdev-site]
justinmclean commented on code in PR #174: URL: https://github.com/apache/comdev-site/pull/174#discussion_r1547092975 ## 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. Review Comment: GitHub automatically does this for you https://github.com/apache/pekko/contribute just substitute pekko for any Apache 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
Re: [PR] Adds practical community building advice. [comdev-site]
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
Re: [PR] Adds practical community building advice. [comdev-site]
rbowen commented on PR #174: URL: https://github.com/apache/comdev-site/pull/174#issuecomment-2032478054 Merging as a first draft. Please do feel free to make further edits/updates. Thanks for the input, friends. -- 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
Re: [PR] Adds practical community building advice. [comdev-site]
rbowen merged PR #174: URL: https://github.com/apache/comdev-site/pull/174 -- 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