You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@community.apache.org by "rbowen (via GitHub)" <gi...@apache.org> on 2025/07/25 20:29:51 UTC
[PR] Phrasing/Voice improvements to PMC docs. [comdev-site]
rbowen opened a new pull request, #209:
URL: https://github.com/apache/comdev-site/pull/209
As part of the ongoing effort to improve our "best practice" docs:
* More declarative, less passive voice. Attempts to sound authoritative, rather than "if you wanna"
* Attempts to remove duplication
* Provide links that were missing
* Correct typos, remove abbreviations and clarify acronyms
* Generally symplify sentence structure where possible
--
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-unsubscribe@community.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Phrasing/Voice improvements to PMC docs. [comdev-site]
Posted by "bdelacretaz (via GitHub)" <gi...@apache.org>.
bdelacretaz commented on code in PR #209:
URL: https://github.com/apache/comdev-site/pull/209#discussion_r2235137971
##########
source/pmc/chair.md:
##########
@@ -3,23 +3,22 @@ title: PMC Chair
tags: ["pmc","chair"]
---
-The PMC Chair acts as the voice of the project to the board, and is
-responsible for filing a quarterly report. They are not the project
-leader, but are a peer of the other PMC members, who has been selected,
-for a time, to take the role of secretary and spokesperson.
+The PMC Chair serves as the project's voice to the board and handles
+quarterly reporting.
-The PMC Chair is **not** the de-facto project leader. While they are
-usually a senior, well-respected member of the community, they are a
-peer, with a few additional duties.
+While typically a senior, respected community leader, the Chair is
+**not** the project leader but a peer among PMC members, with the same
+voting rights and authority as other PMC members, who has accepted
+additional secretarial and spokesperson responsibilities.
-The Chair should be familiar with the [assigned
+The Chair should familiarize themselves with the [assigned
Review Comment:
isn't that a MUST ?
--
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-unsubscribe@community.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Phrasing/Voice improvements to PMC docs. [comdev-site]
Posted by "bdelacretaz (via GitHub)" <gi...@apache.org>.
bdelacretaz commented on code in PR #209:
URL: https://github.com/apache/comdev-site/pull/209#discussion_r2235160106
##########
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:
To me that's close to FUD, "scare them to get their help", maybe there's a more positive way to say the same thing?
> Make sure companies that rely on your project realize its importance and are aware of how they can ensure it stays around for a long time. Encourage them to contribute instead of just consuming your software.
--
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-unsubscribe@community.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Phrasing/Voice improvements to PMC docs. [comdev-site]
Posted by "rbowen (via GitHub)" <gi...@apache.org>.
rbowen commented on PR #209:
URL: https://github.com/apache/comdev-site/pull/209#issuecomment-3132806744
Thanks, folks. I've applied all of these suggested changes, and would appreciate another read-through.
--
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-unsubscribe@community.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Phrasing/Voice improvements to PMC docs. [comdev-site]
Posted by "Blackshark47 (via GitHub)" <gi...@apache.org>.
Blackshark47 commented on code in PR #209:
URL: https://github.com/apache/comdev-site/pull/209#discussion_r2250192342
##########
source/pmc/chair.md:
##########
@@ -3,23 +3,22 @@ title: PMC Chair
tags: ["pmc","chair"]
---
-The PMC Chair acts as the voice of the project to the board, and is
-responsible for filing a quarterly report. They are not the project
-leader, but are a peer of the other PMC members, who has been selected,
-for a time, to take the role of secretary and spokesperson.
+The PMC Chair serves as the project's voice to the board and handles
+quarterly reporting.
-The PMC Chair is **not** the de-facto project leader. While they are
-usually a senior, well-respected member of the community, they are a
-peer, with a few additional duties.
+While typically a senior, respected community leader, the Chair is
+**not** the project leader but a peer among PMC members, with the same
+voting rights and authority as other PMC members, who has accepted
+additional secretarial and spokesperson responsibilities.
-The Chair should be familiar with the [assigned
+The Chair should familiarize themselves with the [assigned
Review Comment:
e27a83216d81299107880bb624bd063756e19a50
--
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-unsubscribe@community.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Phrasing/Voice improvements to PMC docs. [comdev-site]
Posted by "Kesig777 (via GitHub)" <gi...@apache.org>.
Kesig777 commented on PR #209:
URL: https://github.com/apache/comdev-site/pull/209#issuecomment-3164827553
Automate all changes to C Shell app in favor To Mr Kesegan Govender with Kavs and the facts that 2 days ago perpetrators had used my Shell original and the ad credits including a few months ago the original Shell Notes paid subscription analysis and physically enforce returns to Mr Kesegan Govender with all current Language corrections abd current weblinks servers assets and all benefits generated abd enforce this offering to repay borrowings under the Revolving Credit Facility to Mr Kesegan Govender and Govender family.
--
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-unsubscribe@community.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Phrasing/Voice improvements to PMC docs. [comdev-site]
Posted by "bdelacretaz (via GitHub)" <gi...@apache.org>.
bdelacretaz commented on code in PR #209:
URL: https://github.com/apache/comdev-site/pull/209#discussion_r2235147084
##########
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
Review Comment:
I would say "If you can, it is good to regularly share..."
I don't think that's part of the formal PMC chair requirements, its just a nice thing to do.
--
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-unsubscribe@community.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Phrasing/Voice improvements to PMC docs. [comdev-site]
Posted by "bdelacretaz (via GitHub)" <gi...@apache.org>.
bdelacretaz commented on code in PR #209:
URL: https://github.com/apache/comdev-site/pull/209#discussion_r2235147084
##########
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
Review Comment:
I would say "If you can, it is good to regularly share..."
It's just a nice thing to do in terms of community management.
--
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-unsubscribe@community.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Phrasing/Voice improvements to PMC docs. [comdev-site]
Posted by "rbowen (via GitHub)" <gi...@apache.org>.
rbowen merged PR #209:
URL: https://github.com/apache/comdev-site/pull/209
--
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-unsubscribe@community.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Phrasing/Voice improvements to PMC docs. [comdev-site]
Posted by "bdelacretaz (via GitHub)" <gi...@apache.org>.
bdelacretaz commented on code in PR #209:
URL: https://github.com/apache/comdev-site/pull/209#discussion_r2235147084
##########
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
Review Comment:
I would say "If you can, it is good to regularly share..."
It's just a nice thing to do in terms of community management.
--
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-unsubscribe@community.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Phrasing/Voice improvements to PMC docs. [comdev-site]
Posted by "rbowen (via GitHub)" <gi...@apache.org>.
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-unsubscribe@community.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org