Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: <CAFAMeYL_t0Bndt6jXiCKLH4F0mRTHg_mMmUo4E3qQmU=rPSQFQ@mail.gmail.com>
References: <CAFAMeYL_t0Bndt6jXiCKLH4F0mRTHg_mMmUo4E3qQmU=rPSQFQ@mail.gmail.com>
From: Misty Stanley-Jones <misty@apache.org>
Date: Thu, 21 Sep 2017 13:41:31 -0700
Message-ID: <CADvPUpv6mJjMNkfx6nikGtd5bsnbm2LZg43YvxjYBWYpPFTTHQ@mail.gmail.com>
Subject: Re: [DISCUSS] Becoming a Committer
To: HBase Dev List <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary="94eb2c1953dc437f450559b91f75"
archived-at: Thu, 21 Sep 2017 20:42:02 -0000

--94eb2c1953dc437f450559b91f75
Content-Type: text/plain; charset="UTF-8"

I feel like I inject this note into all discussions like this, but I'm
going to do it again. "Act like a committer" does not ONLY mean to produce
code for HBase. It means to support the project. This may mean any of the
following, plus a long list of other things I'm sure I'm not thinking of
right now:

- Contribute to the docs (yay!)
- Help fix and improve testing
- Participate in release candidate votes, even if non-binding
- Review other people's work
- Help newbies
- Answer questions
- Update the website
- File issues
- Mentor new contributors of all sorts
- Give talks about HBase
- Write blogs about HBase
- Participate in design discussions
- Provide UX feedback
- Write demo applications
- Help us attract and retain a diverse community
- Interact with other projects in ways that benefit HBase and those other
projects

I would personally consider all of these bullet points to be super
significant in "act like a committer" type discussions. I think that
contributing code is only one aspect. For some reason it seems to be the
most appealing aspect to lots of people, but IMHO that makes for a poor
community experience.

On Wed, Sep 20, 2017 at 11:48 AM, Mike Drob <mdrob@apache.org> wrote:

>  Hi folks,
>
> I've been chatting with folks off and on about this for a while, and was
> told that this made sense as a discussion on the dev@ list.
>
> How does the PMC select folks for committership? The most common answer is
> that folks should 'act like a committer' but that's painfully nebulous and
> easy to get sidetracked onto other topics. The problem is compounded
> because what may be great on one project is inconsistently applied on other
> projects in the ASF, and yet we are all very tightly coupled as communities
> and as project dependencies.
>
> Ideally, this is something that we can document in the book. Misty gently
> pointed out http://hbase.apache.org/book.html#_guide_for_hbase_committers
> but
> also noted that it's for what happens after somebody becomes a committer.
> Still, if the standard is "act like one until you become one" then it's
> useful reading for people. Also, there doesn't seem to be any guidelines
> like this for PMC.
>
> Is the list of prerequisites possible to articulate, or will it always boil
> down to "intangibles?" Is there a concern that providing a checklist
> (perhaps a list of items necessary, but not sufficient) will lead to folks
> motivated wrongly, similar to oft maligned "resume driven development?"
>
> I'll kick off the discussion by saying that my personal yardstick of "Can I
> trust this person's judgement regarding code/reviews" is probably too vague
> to be useful, and even worse is impossible for others to apply.
>
> Curiously,
> Mike
>

--94eb2c1953dc437f450559b91f75--