Thanks for the clarification. Matt Hogstrom m...@hogstrom.org
A Day Without Nuclear Fusion Is a Day Without Sunshine On Mar 22, 2012, at 6:15 PM, Alan Gates wrote: > Just to be clear, my intention was not to diminish people who only add docs, > fix small problems, etc. On the Pig project we have one committer who only > contributes documentation, which I think is great. The point I was trying to > make is that contributing five patches that fix trivial issues would not be > enough to make me vote for a person. I suppose it would be more complete to > note that if a person consistently contributed patches of this nature it > would make sense to consider adding them. > > Alan. > > On Mar 22, 2012, at 7:29 AM, Matt Hogstrom wrote: > >> I'll throw in my +1 too. Folks that provide doc are just as valuable as >> folks writing code as it delivers value for the consumer of the project. >> Its value to the project being delivered in different ways. >> >> Matt Hogstrom >> m...@hogstrom.org >> >> A Day Without Nuclear Fusion Is a Day Without Sunshine >> >> On Mar 19, 2012, at 10:47 AM, Joe Schaefer wrote: >> >>> +1 Dan, people really do learn from the codebase as they whittle >>> on it. I know when I first got commit at the ASF I knew precious >>> little about C, but after a few years of work here finally got the hang >>> of it. >>> >>> >>> >>> ----- Original Message ----- >>>> From: Daniel Kulp <dk...@apache.org> >>>> To: general@incubator.apache.org >>>> Cc: Alan Gates <ga...@hortonworks.com>; Jukka Zitting >>>> <jukka.zitt...@gmail.com> >>>> Sent: Monday, March 19, 2012 10:42 AM >>>> Subject: Re: Keeping an eye out for new committers >>>> >>>> On Friday, March 16, 2012 04:28:06 PM Alan Gates wrote: >>>>> With my mentor hat on, this is a poke to remind you (the PPMC) that >>>> it's >>>>> your job to be on the lookout for contributors that may be ready to >>>>> become committers. >>>>> >>>>> I look for several things when I consider making someone a committer: >>>>> >>>>> 1) Patches, are they contributing quality features and/or bug fixes. They >>>>> don't have to have written a new subsystem, but you want to look for >>>>> patches that demonstrate understanding in some area, not just spelling >>>>> fixes in error messages, etc. >>>> >>>> I just want to mention that patches that fix "just spelling fixes in error >>>> messages, etc." shouldn't be discounted so harshly. In CXF, one of >>>> the >>>> historically most active contributors got started by deluging us with such >>>> patches. We made him a committer (so he could fix all of that himself) >>>> which helped build his confidence and he's expanded out from there. His >>>> work just on the spelling mistakes and messages and stuff has been a big >>>> help in making things "feel" more professional, especially in a >>>> projects >>>> where a large number of people don't have english as their native >>>> language. >>>> >>>> >>>> All contributions are welcome and have value. Just because it may not be >>>> technical in nature doesn't make them have any less value from a >>>> "should >>>> this person be a committer" standpoint. >>>> >>>> But the rest of this is good. :-) >>>> >>>> >>>> Dan >>>> >>>> >>>> >>>> >>>> >>>>> One good way to find what patches a >>>>> contributor has done is to look over the contributor report from JIRA. >>>>> You can get this by going to your project's JIRA, and under the reports >>>>> drop down on the right side, click on "Contribution Report". >>>>> >>>>> 2) Emails, comments on JIRA, etc. giving others feedback, answering user >>>>> questions, etc. Again you can use the contribution report to see JIRA >>>>> comments. You can find emails in the mailing list archives for your >>>>> project. >>>>> >>>>> 3) Is this person good to work with? Do they give constructive feedback? >>>>> Do they take feedback well? >>>>> >>>>> 4) Does this person seem likely to stay involved? All Apache positions >>>>> are volunteer and so we can't ask people to sign up for a period of >>>> time >>>>> or promise to be around forever. But if I sense that a contributor is >>>>> just fixing one problem they need fixed, I usually wait to see if they >>>>> continue their involvement after that issue is addressed before >>>>> nominating them as a committer. >>>>> >>>>> Alan. >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>> -- >>>> Daniel Kulp >>>> dk...@apache.org - http://dankulp.com/blog >>>> Talend Community Coder - http://coders.talend.com >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
