[incubator] branch master updated: Minor changes and updates (including joining lines together). update advice on raising profile.

[jm...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

jmclean pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator.git


The following commit(s) were added to refs/heads/master by this push:
     new 81523c0  Minor changes and updates (including joining lines together). update advice on raising profile.
     new 3639c54  Merge pull request #45 from justinmclean/master
81523c0 is described below

commit 81523c0ce5e8153c0c205a29918f2067e200fb60
Author: Justin Mclean <jm...@apache.org>
AuthorDate: Thu Oct 17 22:54:29 2019 +1100

    Minor changes and updates (including joining lines together). update advice on raising profile.
---
 pages/guides/community.ad | 170 +++++++++-------------------------------------
 1 file changed, 32 insertions(+), 138 deletions(-)

diff --git a/pages/guides/community.ad b/pages/guides/community.ad
index 907ed1b..64a6e3a 100644
--- a/pages/guides/community.ad
+++ b/pages/guides/community.ad
@@ -18,174 +18,68 @@ Apache Incubator PMC
 :toc:
 :imagesdir: ../images/
 
-Help to improve the system by posting a patch for
-this document to the incubator section of JIRA or a
-comment to the link:lists.html[general] list at
-incubator.
-
 == Abstract
 
-The intent of this document is to help podlings the
-importance of building an open and diverse community for
-their project. It gives guidelines on how to accept new
-committers and PPMC members, and how to enable more
-community involvement, taking off the burden of answering
-every question yourself.
+This document intends to help podlings understand the importance of building an open and diverse community for their project. It gives guidelines on how to accept new committers and PPMC members, and how to enable more community involvement, taking off the burden of answering every question yourself.
 
 == What is an open and diverse community?
 
-A major criterion for graduation is to have developed an open
-and diverse link:http://www.apache.org/foundation/glossary.html#Meritocracy[meritocratic]
-community. Time has demonstrated that these kinds of
-communities are more robust and productive than more closed
-ones.
+A major criterion for graduation is to have developed an open and diverse link:http://www.apache.org/foundation/glossary.html#Meritocracy[meritocratic] community. Time has demonstrated that these kinds of communities are more robust and productive than more closed ones.
 
 === People
 
-As a project grows, it needs to renew itself by accepting new
-committers. A project needs to learn how it can recruit new
-developers and committers into the community. Accepting new
-committers usually increases the diversity of the project. So,
-this process is very beneficial. link:#notes-community[Community building] requires energy
-which could have been spent on code development but this cost
-is an important investment for the future of the project.
+As a project grows, it needs to renew itself by accepting new committers. A project needs to learn how it can recruit new developers and committers into the community. Accepting new committers usually increases the diversity of the project. So, this process is very beneficial. link:#notes-community[Community building] requires energy which could have been spent on code development, but this cost is an essential investment for the future of the project.
 
-The openness of the community is not only measured by the
-number of contributors. Open and respectful discussions on the
-mailing lists are vital. Ways to resolve technical conflict
-without destroying personal relationships must be learned.
+The openness of the community is not only measured by the number of contributors. Open and respectful discussions on the mailing lists are vital. Ways to resolve technical conflict without destroying personal relationships must be learned.
 
 === Communication
 
+Mailing lists are the lifeblood of Apache communities. They are the primary mode of discourse and constitute a public and historical record of the project. Other forms of communication (P2P, F2F, personal emails, instant messaging platform, and so on) are secondary. There are well-founded fears about the use of other forms of project communication. Though some projects successfully blend other forms of communications, care needs to be taken since out-of-band communications have led to di [...]
+
+Apache project mailing lists are public, archived and searchable. This allows anyone to monitor (both in real-time and by browsing the archives) what's happening. Opinions expressed are in the open and poor behavior risks a poster's reputation.
+
+Private communications tend to be more candid but also more likely to be ill-judged. Backchannel communication tends to be divisive, excluding some members of the group. This tends to have a corrosive effect on the collective spirit of the community. Mistrust builds when opinions backed by blocks of developers appear form nowhere fully formed on the mailing list.
+
+Communication through other channels also reduces the chance of link:http://en.wikipedia.org/wiki/Serendipity[serendipity]. As with most social networks, most subscribers to a mailing list never post and most posts come from a tiny minority of subscribers. Some passive subscribers are just interested in where the project is going. But, others understand related fields and have a limited intersection of interest. This second group will often post when this topic arises on list. Using publ [...]
 
-Mailing lists are the life blood of Apache communities. They
-are the primary mode of discourse and constitute a public and
-historic record of the project. Other forms of communication
-(P2P, F2F, personal emails and so on) are secondary. There are
-well founded fears about use of these media for project
-communication. Though many projects successfully blend other
-forms of communications, care needs to be taken since
-out-of-band communications have led to difficulties in the
-past. The reason is that communications on other than the
-public mail aliases exclude parts of the community. Even
-publicly advertised IRC chats can be exclusionary due to time
-zone constraints or conflicting time commitments by community
-members who might want to participate.
-
-Apache project mailing lists are public, well indexed and well
-archived. This allows anyone to monitor (both in real time and
-by browsing the archives) what's happening. Opinions expressed
-are public and poor behavior risks a poster's reputation.
-
-Private communications tend to be more candid but also more
-likely to be ill-judged. Back channel communication tend to be
-divisive, excluding some members of the group. This tends to
-have a corrosive effect on the collective spirit of the
-community. Mistrust builds when opinions backed by blocks of
-developers arise fully formed on list.
-
-Communication through other channels also reduces the chance
-of link:http://en.wikipedia.org/wiki/Serendipity[serendipity].
-As with most social networks, most subscribers to a mailing
-list never post and most posts come from a tiny minority of
-subscribers. Some passive subscribers are just interested in
-where the project is going but others understand related
-fields and have a limited intersection of interest. This
-second group will often post when this topic arises on list.
-Using public mailing lists to develop designs allows the
-chance encounter of ideas which often results in innovation.
-
-If alternative forums are used by a project, it is important
-to try to minimize the chances of problems arising. All
-matters of substance need to be moved back to the mailing
-lists. Public records should be kept and posted back to the
-list. Regular reminders should be posted to remind people that
-other secondary forms of communication exist.
-
-There are a limited number of topics such as security issues
-and discussions about people which are best handled in
-private. As much business of the project as possible should
-take place on public lists but the private list is available
-for those matters of a sensitive nature. Good netiquette
-requires that permission from the poster should be sought
-before making public, posts made to a private list. Try to
-avoid cross-posting between public and private forums. Take
-care not to post a reply to a private post to a public forum
-without permission.
-
-Learning to use mailing lists effectively is very important.
-If this can be achieved, then you have shown to be a lively,
-active and successful community. The future looks bright.
+If a project uses alternative forms of communication, it is essential to try to minimize the chances of problems arising. All matters of substance need to be moved back to the mailing lists. Public records should be kept and posted back to the list. Regular reminders should be posted to remind people that other secondary forms of communication exist.
+
+There are a limited number of topics such as security issues and discussions about people which are best handled in private. As much business of the project as possible should take place on public lists, but the private list is available for those matters of a sensitive nature. Good netiquette requires that permission from the poster should be sought before making public, posts made to a private list. Try to avoid cross-posting between public and private forums. Take care not to post a r [...]
+
+Learning to use mailing lists effectively is very important. If this can be achieved, then you have shown to be a lively, active and thriving community. The future looks bright.
 
 === Community Building
 
-Before a podling graduates, it must create a diverse and
-self-sustaining community. Community building is tough: it
-takes time, effort and more than a little magic. There is no
-secret recipe, just hard work. In order to overcome this
-obstacle, committers may need to devote more time to community
-building and less to development.
+Before a podling graduates, it must create a diverse and self-sustaining community. Community building is tough: it takes time, effort and more than a little magic. There is no secret recipe, just hard work. In order to overcome this obstacle, committers may need to devote more time to community building and less to development.
 
-The link:mailto:community@apache.org[community mailing list] is open to all Apache committers. This is the right
-list for questions about community and on community building.
-Subscriptions should be from an Apache email address.
+The link:mailto:community@apache.org[community mailing list] is open to all Apache committers. This list is the right list for questions about the community and on community building. Subscriptions should be from an Apache email address.
 
 ==== Raising The Profile
 
-Sometimes, a podling is just not well-enough known. There
-are simply not enough users to allow new developers to be
-recruited. Overcoming this means finding ways to raise the
-profile of the podling. Some ideas:
+Sometimes, a podling is just not well-enough known. There are  not enough users to allow new developers to be recruited. Overcoming this means finding ways to raise the profile of the podling. Some ideas:
 
 - Improve the website
-- Improve the information provided within each release and release more often
-- Committers who blog should join link:http://www.apache.org/dev/committers.html#planetapache[PlanetApache]
+- Improve the information provided within each release 
+- Release more often
+- Simplify the build
+- Improve the documentation
+- Provide getting started examples and documentation
 - Use grassroots media
 - Encourage downstream distributions to include a packaged version
 - Submit talks to conferences
 - link:http://www.feathercast.org[Feathercast]
-- Write articles
+- Write blogs and articles
 
 ==== Building a community by stepping back a little
 
+If the podling has lots of users but very few new developers, then this means that more work is required to encourage users to become developers. A common cause of this is that committers are too quick to create code to solve user problems. It's good to respond quickly to requests by users. However, once a project gains momentum, it may be more productive for the long term health of a project to encourage users to become more involved.
 
-If the podling has lots of users but very few new
-developers then this means that more work is required to
-encourage users to become developers. A common cause of
-this is that committers are too quick to create code to
-solve user problems. It's good to respond quickly to
-requests by users. However, once a project gains momentum,
-it may be more productive for the long term health of a
-project to encourage users to become more involved at the
-expense of user satisfaction.
-
-Try to encourage expert users to answer questions. This
-may mean intentionally allowing a time gap before
-answering user questions. Encourage users to post by
-taking the time to deal politely and positively with
-misunderstandings and by replying to threads which have
-been answered well by a user to confirm that they are
-right. Avoid engaging in flame wars on user lists. Ignore
-trolls.
-
-Try to encourage users to become developers. When they
-give a good answer that isn't covered in the
-documentation, ask them to submit a patch. When users
-suggest a good design or extension, ask for volunteers to
-help implement rather than just coding it up.
+Try to encourage expert users to answer questions. This may mean intentionally allowing a time gap before answering user questions. Encourage users to post by taking the time to deal politely and positively with misunderstandings and by replying to threads which have been answered well by a user to confirm that they are right. Avoid engaging in flame wars on user lists. Ignore trolls.
+
+Try to encourage users to become developers. When they give a good answer that isn't covered in the documentation, ask them to submit a patch. When users suggest a good design or extension, ask for volunteers to help implement rather than just coding it up.
 
 ==== Helping Developers Become Committers
 
-If a podling has no trouble attracting developers but
-trouble retaining them long enough for them to become
-committers then this highlights an issue with the
-recruitment process. To become an Apache committer, a
-developer needs to hang around long enough to accumulate a
-track record of contributions. This often requires
-encouragement and help from existing committers.
-
-Promptly reviewing patches is important. The way that
-patches are applied is also important. Provide credit in
-the commit message and when closing the JIRA. It's also
-good to encourage developers by suggesting new related
-work they may like to volunteer for.
+If a podling has no trouble attracting developers but difficulty retaining them long enough for them to become committers, then this highlights an issue with the recruitment process. To become an Apache committer, a developer needs to hang around long enough to accumulate a track record of contributions. This often requires encouragement and help from existing committers. It may also be that the committer bar has been set too high.
+
+Promptly reviewing patches or pull requests is essential. The way that patches are applied is also important. Provide credit in the commit message and when closing the issue. It's also good to encourage developers by suggesting new related work they may like to volunteer to work on.
\ No newline at end of file


---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org