[comdev-site] branch main updated: Advice around adding new committers.

[rb...@apache.org]

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

rbowen pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/comdev-site.git


The following commit(s) were added to refs/heads/main by this push:
     new 28af6ad  Advice around adding new committers.
     new c46ccad  Merge pull request #115 from rbowen/20230515-pmc
28af6ad is described below

commit 28af6ad19cf0f4a65817fd4679cea9f17b224b65
Author: Rich Bowen <rb...@rcbowen.com>
AuthorDate: Mon May 15 14:09:17 2023 -0400

    Advice around adding new committers.
---
 source/pmc/adding-committers.md | 73 ++++++++++++++++++++++++++++++++++++++---
 1 file changed, 69 insertions(+), 4 deletions(-)

diff --git a/source/pmc/adding-committers.md b/source/pmc/adding-committers.md
index 70be7f5..0b0aad6 100644
--- a/source/pmc/adding-committers.md
+++ b/source/pmc/adding-committers.md
@@ -7,10 +7,75 @@ The addition of new committers is essential to the long-term
 sustainability of an open source project. The PMC is responsible for
 determining who will be added as a committer.
 
-* Who should be a committer?
-* Vote process
-* What to do when a committer is elected
+Note that the formal policy and process document around adding 
+committers is 
+[here](https://www.apache.org/dev/pmc.html#committer-management). 
+This page discusses best practices in how to think about new committers.
 
-Note: Formal policy/process document is here: https://www.apache.org/dev/pmc.html#committer-management
+## Who should be a committer?
 
+Each project must decide what is the correct measure for inviting a new
+committer to their project. There are, however, several things that we
+encourage you to consider.
 
+Any PMC member can (and should!) nominate project contributors for a
+committer vote. Don't assume that the PMC chair, or some senior project
+member, will do this. Watch the contributors, and nominate promising
+participants.
+
+Remember that we do all of our development in revision control.
+Errors are reversible learning opportunities. Thus, inviting someone
+"too early" has very little risk associated with it. On the other hand,
+inviting someone too late has the very real risk that they'll get
+frustrated and leave, and you'll have missed that opportunity forever.
+Setting the bar too high has been the eventual death of many projects.
+
+Think of adding committers as an investment in the future of your
+project, rather than as a reward for good behavior. Committers that you
+add today will be the backbone of your project tomorrow, or five years
+from now. New committers are the only way to ensure the long-term
+sustainability of your project. Look for contributors who seem to have
+new ways of thinking.
+
+Think of a committer as someone who is committed to the project, rather
+than just someone who writes code. Contributions in other areas, such as
+design, end-user support, event management, documentation, or project
+promotion, should also be welcomed into the project by inviting them as 
+committers, and, eventually, as PMC members.
+
+Finally, if you have specific requirements for committers (such as a
+period of time, or number of contributions) we encourage you to document
+that on your website. People like to know what their "career path" is in
+a project, rather than feeling that it is merely at the whims of a
+secret committee. If you see someone that seems to be on the path, point
+them to this document, so that they know what to expect, and what they
+can do to become a better contributor. See also [Becoming A
+Committer](https://community.apache.org/contributors/becomingacommitter.html)
+for general advice you might offer.
+
+## Vote process
+
+The complete policy and procedure around *how* to vote for a committer,
+and how to add them to the relevant rosters if and when they are voted
+in, is covered in the [PMC policy
+document](https://www.apache.org/dev/pmc.html#committer-management). As
+a PMC member, you should read and understand that document.
+
+## What to do when a committer is elected
+
+Once a committer has been added to the roster, be sure that they
+understand how things work in your project, rather than leaving them to
+figure this out on their own.
+
+Point them to specific review processes that they are expected to abide
+by before committing or merging a change.
+
+Point new committers to [Infra's guide for new
+committers](https://infra.apache.org/new-committers-guide.html) which
+has general information for all ASF committers.
+
+Consider clearly documenting the development environment that a
+committers should have to be successful. This might include a
+recommended IDE, how to interact with your CI/CD stack, how to build and
+test locally, and any common problems they might encounter with their
+first few commits.