Hey Csaba,
I think you might be falling into a common-trap :). A committer's
"status" is often acquired via repeated contributions of code to a
project -- you're absolutely right. This stems from the fact that, most
times, people contribute to a project via code. Committership (for
HBase) is commonly helping contributors do more without needing the help
of others. Committership can also be looked at as a stepping stone
towards PMC.
This discuss was more about how the HBase project acknowledges that
contributions can come in various forms. As such, the path to "merit"
doesn't have to only be achieved via code contributions. There's nothing
wrong with this, from both an HBase and an ASF perspective. I think you
have a good number of people here that would happily vote in the
positive for individuals who contribute (in some of the ways listed
below) to become a PMC member, charged with the guidance and health of
the project.
In short, "committer" and "PMC" are really just plateaus given to folks
in recognition of their contributions, regardless of form. What were
trying to do was be more explicit about the various definitions of
"contribution" we hold. Does this help clarify it?
- Josh
On 11/9/17 11:41 AM, Csaba Skrabak wrote:
Wow, this list just made me think. Is the Committer status clearly a reward for
contributing in any way? Or is it a very pragmatic decision by the PMC that
some fellow needs right to commit? I think it's kind of both but the ratio
should be clear and consensual.
People who answer questions, file issues, write blogs, demo applications and do
stuff that does not involve coding, they can continue helping the community
just fine without a Committer title. Maybe PMC could invent a Big Thank You
event for them but not give the Committer status. Or just give them a Committer
status because why not?
On 21/09/17 22:41, "Misty Stanley-Jones" <[email protected]> wrote:
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
