To bounce off of what Yu Li said earlier - I see Hadoop has adopted very similar language to the Spark list: http://hadoop.apache.org/committer_criteria.html
I especially like the examples at the bottom. They are four diverse paths, and there is no expectation that this is an exclusive list. If we were to write our own, I think it should reflect Andrew's highlighting of the non-professional contributor's path. And also important is to include the soft skills from Misty's list. Mike On Sat, Sep 23, 2017 at 5:07 PM, Stack <st...@duboce.net> wrote: > Good discussion. Thanks Mike for kicking it off. > > The Misty list is great. > > I find myself giving double kudos for non-code or feature contribs; e.g. > stuff like test-fixing, patches that fix bugs found in production or > patches from operators that ease their day-to-day burden, voting on > releases, doc., (useful, encouraging, deep, helpful) review of the work of > others, etc. (I'd love it if someone took ownership of our website -- hint, > hint). > > Sean has a dictum, paraphrasing, "...the fastest route to commitership is > doing what no one else wants to do" (Did I mangle that Busbey?), which I > like. > > While Andrew may have misjudged Mike Drob's original intent, I appreciate > his rallying to the cause of the non-professional contributor and his > reaction to (mis-perceived) call for quantification (For a classic on the > problems that arise when hard-and-fast rules, see [2]). I'm with him > defending PMC right to give 'spirit' and 'gut' precedence over 'rules' > (Often, it *is* just a case of you know it when you see it). And as per > Andy, if perceived injustice or bias, please write here or private@hbase. > > Lets keep dumping on this thread. We can then summarize and make it easy > for prospectives to find (can also add links to stuff such as the recent > Wang+Leblang talk at ApacheCon [1] and Andrew's write up for how to be a > committer on Hadoop as background). > > Thanks, > St.Ack > > 1. > https://apachecon2017.sched.com/event/9zv3/a-tale-of-two- > developers-finding-harmony-between-commercial-software- > development-and-the-apache-way-andrew-wang-alex-leblang-cloudera > 2. > https://books.google.com/books/about/Seeing_Like_a_ > State.html?id=PqcPCgsr2u0C > > > > > > On Fri, Sep 22, 2017 at 4:08 PM, Zach York <zyork.contribut...@gmail.com> > wrote: > > > bq. As a > > relatively new member in the HBase community and a non-committer, once > the > > new member decides that he/ she wants to become a Committer, it will be > > helpful to have a list of PMC members that he/ she can communicate with > and > > get feedback from time to time. Feedback may include potential > adjustments > > and rough idea about progress towards the goal. > > > > This sounds like a good idea! Ideally, if you interact with the community > > often enough, you should be building connections, but it nevers hurts to > > have someone to check how they perceive your work. > > > > bq. For others, having > > this list of volunteer mentors, will surely help. > > > > Again I agree. This part is especially important as it is hard to judge > > your progress if you don't have someone at the same company to converse > > with. > > > > On Fri, Sep 22, 2017 at 3:38 PM, Umesh Agashe <uaga...@cloudera.com> > > wrote: > > > > > Hi, > > > > > > Thank you all for a good discussion here. Issues with both having and > NOT > > > having documented specific criteria are well articulated here. As a > > > relatively new member in the HBase community and a non-committer, once > > the > > > new member decides that he/ she wants to become a Committer, it will be > > > helpful to have a list of PMC members that he/ she can communicate with > > and > > > get feedback from time to time. Feedback may include potential > > adjustments > > > and rough idea about progress towards the goal. Paid professionals who > > are > > > working with PMC members, can talk to their colleagues. For others, > > having > > > this list of volunteer mentors, will surely help. IMHO, this will make > > > process a bit more transparent. I would like to know your thoughts on > > this. > > > > > > Thanks, > > > Umesh > > > > > > > > > > > > > > > On Thu, Sep 21, 2017 at 1:41 PM, Misty Stanley-Jones <mi...@apache.org > > > > > 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 <md...@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 > > > > > > > > > > > > > > >
