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 <[email protected]> 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 >
