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 > > > > > >
