On Mon, Jan 30, 2017 at 10:50 AM, Jim Apple <[email protected]> wrote:
> Thank you for the advice, Todd. I will take it to heart. > > Could you share with us a little about how Kudu set standards that > were more actionable than our existing rather vague > https://cwiki.apache.org/confluence/display/IMPALA/Committer+Criteria > ? > > This kind of question has come up in every ASF PMC that I've been a part of -- and every time the answer has been that it's difficult to come up with objective standards, and that's OK. The communities typically "decide not to decide" or the discussion just peters off (as it sort of did here). Everyone always learns a bit from each other during the discussion though, so the fact that it doesn't yield an actionable set of bylaws is not all a loss. After seeing a bunch of these discussions happen, it seems that the common ground everyone always finds is this: A person should be made a committer if: 1) they seem committed to the project (i.e. they seem likely to stick around and continue to contribute, rather than just submit a few drive-by patches) 2) they are a net positive to the project (e.g. their patches, reviews, evangelism, points in discussion, etc are beneficial to the health of the code, its users, its release cycle, etc) 3) they are trusted by others to use their privileges within their abilities and knowledge scope (e.g. if they're still not an expert at code review, they keep their +2s to changes that are trivial, and defer more complex issues to others who know better, etc) The above are obviously subjective, which is why it resists the ability to write them down in any kind of "check the boxes and become a committer!" kind of fashion. But that's why the PMC is a group of folks with equal votes, and discussion threads are useful. The above are also very "coachable" -- eg if someone is net positive and trusted, but not very committed, a note of encouragement may get them to stick around longer. Or if someone is strong in their specific area but occasionally "oversteps" by giving +1s on code they don't truly understand, they could be guided away from that behavior gently. Every time the discussion veers towards "you need to have 12 small patches, or 3 big patches, or one complex feature", it gives the illusion of objectivity but in fact remains subjective. What's complex? What's big? What's valuable? If someone spends 3 weeks to reproduce a tricky race that has been crashing users for months, and it yields a two-line patch, maybe that "small patch" is more valuable than someone else's 2kloc of new SQL syntax. Or maybe not, if you are really excited about that new SQL syntax. Value's in the eye of the beholder. I just recalled that the Hadoop PMC eventually did write down some of this. Here's what they've got: https://hadoop.apache.org/committer_criteria.html I do think that it's nice to write something down in that style, but it seems you've already done that. Trying to get too actionable is a noble but perhaps unattainable goal. -Todd > On Fri, Jan 6, 2017 at 12:29 PM, Todd Lipcon <[email protected]> wrote: > > On Fri, Jan 6, 2017 at 8:53 AM, Jim Apple <[email protected]> wrote: > > > >> My feeling is similar to Tim's: > >> > >> It's the PPMC's responsibility, but a contributor is welcome to plead > >> their case, ask for a mentor, and so on. I think we shouldn't consider > >> it rude or pushy or aggressive to request committership. It is a > >> compliment to Impala and the Impala community that the contributor > >> want to be more involved. > >> > >> > > Agreed that it's first and foremost the PPMC (later PMC)'s responsibility > > to identify and proactively encourage committer candidates. If a > > contributor is having to "plead their case" or "request committership" > that > > to me is an unhealthy sign. Perhaps a contributor might email the mailing > > list (or privately email committers they've worked with) and ask for > > feedback on how to improve their contributions, but I think that's a bit > > different than trying to argue/request for committership. > > > > Perhaps it's just a semantic distinction or I'm being picky about > wording, > > but to me "plead" signifies some kind of disagreement and negativity on > > what should be more like a mentorship relationship. > > > > My experience on other PMCs (Hadoop and HBase in particular) is that > people > > often start threads on the private@ list regarding new contributors > fairly > > early on (say after 5-10 patches). Those threads are not VOTE threads, > but > > rather a discussion to try to identify one or two PMC members who will > > agree to mentor and encourage the new contributor towards committership. > > Usually the expectation is that those mentors will later be the ones to > > propose the person for committership and make a case, and will often take > > it upon themselves to ensure rapid reviews of patches the person is > > contributing, etc. > > > > When I've acted as a mentor in this respect, I typically email the person > > to let them know that the PMC has identified them as someone doing good > > work and contributing positively to the project. If the discussion thread > > has identified any constructive feedback, I let them know, and also offer > > myself as a resource as someone to ping about code reviews that need > > attention, questions about the project, etc. I've found that the positive > > feedback of being recognized by the PMC often encourages continued > > contributions, and that the constructive feedback/criticism usually has a > > good effect. > > > > In practice, the "mentors" will often be colleagues of the new > contributor > > or have some other "in-real-life" relationship to make it easier to give > > constant feedback, but of course that's in no way a requirement. > > > > -Todd > > > > > >> On Fri, Jan 6, 2017 at 8:36 AM, Tim Armstrong <[email protected]> > >> wrote: > >> > Hi Michael, > >> > My two cents is that the PMC should be proactive about identifying > >> > potential committers and working with them to address any gaps. We > >> haven't > >> > done a good job of that so far but we've started up some discussions > on > >> the > >> > private list to get better at that. > >> > > >> > You should feel free to ask anyone on the PMC about any of the above > >> > questions. Ideally that wouldn't be necessary, but in practice it may > >> help > >> > move things along, particularly if you have someone who will advocate > for > >> > you and wrangle the PMC to come to a consensus. It's definitely on us > to > >> > communicate to you what gaps (if any) there are - it shouldn't really > be > >> a > >> > black box. > >> > > >> > - Tim > >> > > >> > On Fri, Jan 6, 2017 at 8:24 AM, Michael Brown <[email protected]> > >> wrote: > >> > > >> >> You've done a great job highlighting some example scenarios. Here are > >> some > >> >> questions that aren't addressed in your writeup. > >> >> > >> >> What are contributors' responsibilities to move toward > committership? In > >> >> particular, I'm talking about process, not the nuts and bolts of > >> >> contributions (including patches, bugs, reviews). For example: > >> >> > >> >> Should a contributor who wants to be a committer find a "mentor"? > >> >> > >> >> Should a contributor who wants to be a committer be lobbying for > >> >> committership to someone who has reviewed his patches, or dealt with > >> bugs > >> >> he's filed, or otherwise interacted with? > >> >> > >> >> Should a contributor nominate himself on this list? Must he cite > >> examples > >> >> of his contributions? > >> >> > >> >> How can a contributor who wants to be a committer receive good > feedback > >> for > >> >> areas of improvement if his committership is rejected? > >> >> > >> >> > >> >> On Thu, Jan 5, 2017 at 1:41 PM, Jim Apple <[email protected]> > wrote: > >> >> > >> >> > I think it would be helpful to non-committer contributors (and > non-PMC > >> >> > committers (just me right now)) if PPMC members would muse a bit > about > >> >> > what they believe the bar is for committership or PPMC membership. > >> >> > > >> >> > I am not suggesting that the PPMC write a document with so much > detail > >> >> > that you are hamstrung when looking at contributors in the future > and > >> >> > decising if they did 6 hard code reviews and 5 medium or 7 hard > code > >> >> > reviews and 4 medium ones. > >> >> > > >> >> > However, multiple people have pinged me asking how to become a > >> >> > committer, asking what work products are sufficient. > >> >> > > >> >> > I don't have a foolproof way of describing the possible bars, so > let > >> >> > me give a few examples for feedback from the PPMC. > >> >> > > >> >> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> >> > Potential committers: > >> >> > > >> >> > Alice started contributing 4 months ago. She fixes at least one > style > >> >> > issue or typo every weekend. > >> >> > > >> >> > Bob started contributing a year ago. We uses Impala to organize his > >> >> > VHS collection, and he regularly reports scaling bugs as his > >> >> > collection grows to more and more impalad nodes. His reports are > often > >> >> > out of date, since he runs an old Impala, but some are still bugs > in > >> >> > the latest version. His bug reports are of very high quality. > >> >> > > >> >> > Carol started contributing six months ago. She helped design one > >> >> > tricky feature. It took her six months and 27 revisions to get the > >> >> > patch in. She also helps other users a lot with their issues. > >> >> > > >> >> > Dave has been contributing for 18 months. He helped design a tricky > >> >> > feature, too, but his code was not high quality enough to check > in. He > >> >> > did document the feature while a PPMC member wrote the code. Since > >> >> > then, he's been helping users on the mailing lists and filing UI > bugs, > >> >> > especially with the REPL. > >> >> > > >> >> > Eve used to contribute before Impala was with Apache, and she was > not > >> >> > listed as a committer/PPMC member when incubation started. Since > then, > >> >> > she does code reviews, only commenting on style issues. She does 3 > or > >> >> > 4 a month. > >> >> > > >> >> > Frank has been contributing for three months. He writes 3-4 patches > >> >> > every weekend. They are all tests, query generation, or > >> >> > impala-shell.sh work, and they are almost uniformly high-quality. > >> >> > > >> >> > My personal feelings: Yes on Bob, Carol, Eve, and Frank. Alice is > not > >> >> > on track. Dave is on track but should do more design work and doc > >> >> > writing. > >> >> > > >> >> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> >> > Potential PPMC members, all of which are already committers. > >> >> > > >> >> > Gertrude has been a contributor for 18 months. She spends most of > her > >> >> > efforts on backend performance in-the-small - a few microops saved > per > >> >> > row per patch. She helps review patches in this area. She doesn't > >> >> > participate much on governance. > >> >> > > >> >> > Harold has been a contributor for a 30 months. He works > exclusively on > >> >> > performance, but he writes very little code. All of his effort is > >> >> > devoted to understanding Impala performance issues, which he writes > >> >> > and and files as high quality bug reports. He does not review code > and > >> >> > he does not write code or documentation. He participates in > discussion > >> >> > and consensus-building on design. > >> >> > > >> >> > Imelda has been a contributor for 12 months. She also does not > write > >> >> > code. She is focused only on community outreach, writing blog posts > >> >> > and doing the simplest code reviews for her recruits to the > project. > >> >> > She posts or gets a new contributor once a month. > >> >> > > >> >> > Jules has been a contributor for 40 months. He only reviews code, > but > >> >> > he gives outstanding reviews of both design and style. He managed > two > >> >> > releases last year. > >> >> > > >> >> > Kim has been a contributor for 55 months. She used to write a lot > of > >> >> > code but now she is focused on keeping infrastructure ship-shape, > >> >> > mainly flaky test fixing and Jenkins wrangling. She rarely votes. > >> >> > > >> >> > My personal feelings: No on Gertrude and Kim, yes on Harold, > Imelda, > >> >> > and Jules. G+K may be outstanding committers and members, but are > not > >> >> > on track for PPMC membership. However, they could get on track very > >> >> > easily by focusing some small part of their effort on governance > work. > >> >> > > >> >> > +++++++++++++++++++++++++++++++++++++++++++++++++++ > >> >> > > >> >> > BTW, if you don't know if you already are a PPMC member, here is > the > >> >> list: > >> >> > > >> >> > http://incubator.apache.org/projects/impala.html > >> >> > > >> >> > If you are a PPMC member, please subscribe to private@, where > votes > >> on > >> >> > committership and PPMC membership will be held. > >> >> > > >> >> > This general discussion should happen in public; private is for > >> >> > discussion of real people, not these fake names. > >> >> > > >> >> > >> > > > > > > > > -- > > Todd Lipcon > > Software Engineer, Cloudera > -- Todd Lipcon Software Engineer, Cloudera
