Following up... The Committers at Geode ended up choosing a fairly liberal criterion for nomination and voting new Committers, as is stated here: https://cwiki.apache.org/confluence/display/GEODE/Becoming+a+committer
Specifically here: > 1. Committers should nominate fellow contributors when a candidate has > shown a consistent history of participating in the development process or > community, and has demonstrated that they understand and follow the > development > process and community standards of the Apache Geode project. > > > 1. The members on the PPMC will consider both the history and quality > of the contributors' participation, and vote whether to grant commit > privileges to the candidate, or provide feedback and mentoring to the > candidate to help further groom them to become a Committer in the future. > > > 1. Contributors who have shown a consistent history of participating > in the development process or community, and have demonstrated that > they understand and follow the development process and community > standards of the Apache Geode, and who show promise for future > contributions should generally be accepted by the PPMC as a new Committer. > > On Wed, Jan 6, 2016 at 5:48 PM, Gregory Chase <[email protected]> wrote: > This discussion just came up in Apache Geode as well, and I suggested the > following: > > <snip> > > 1. "The Committers" are currently the same as "The PPMC". So at this > > point, voting someone as a committer is voting them as the potential > future > > PMC of Apache [HAWQ]. > > > > > > 2. Becoming a committer should be used to recognize a contributor as > having > > further potential to contribute even more, and to encourage them to > > participate with and collaborate more with the community. > > > > > > In my personal opinion, contributors who show themselves as > collaborative, > > community building, or supportive of users with a likelihood of > > contributing even more should be nominated and likely voted by the PPMC > to > > be a contributor. > > > > > > While not the only source, many behaviors related to being collaborative, > > community building, or supportive of users is captured by our community > > dashboard: [http://projects.bitergia.com/apache-hawq/browser/] > > > > > > Thus I'd expect high contributors in these areas to rank in top lists as > > follows: > > > > > > Collaborative: > > Jiras: open, comment, close > > Dev mail list: open threads, reply > > Git: commits > > Code reviews > > > > > > Someone who does not collaborate and only develops would likely only show > > up in pull requests, but not other collaborative infrastructure. > > > > > > Community building would include: > > Dev & user mail lists > > Wiki / confluent editing > > > > > > User supporting would include: > > User mail list responses > > Jiras opened and commented on > > > > > > I'm sure these lists can be better refined. > > > > > > While I wouldn't quantify this, I would argue that if someone shows up in > > multiple categories of contribution on top lists for more than one 30 day > > period, they are likely candidates to be nominated as a committer. > > > > > > I know of at least a couple of companies that pay their employees to be > > contributors to Apache [HAWQ]. If their job changes, or they move to a > > different company, will they stay as a contributor if we make them a > > committer? I'd argue this is much more likely if we see them > contributing > > in multiple categories rather than just a single way. > > > > > > Finally, we need to create a model and standard of how we want our > > community to act. By being more specific about asking for broader > > contribution to be recognized as a committer, this will help train new > > members of this community how to participate fully. > > > > > Regards, > > -Greg > > On Wed, Jan 6, 2016 at 11:21 AM, Caleb Welton <[email protected]> wrote: > > > Good suggestion, updated along with a couple other little adjustments for > > clarity and excess redundancy. The last paragraph could still use a bit > > more work. > > > > On Wed, Jan 6, 2016 at 4:47 AM, Justin Erenkrantz <[email protected] > > > > wrote: > > > > > Thanks for the writeup. One minor suggestion: > > > > > > Code contributions (patches submitted to JIRA or PRs) committed by > > > existing committers. > > > > > > I would probably rephrase as "merged by" - the use of commit > > > everywhere gets a bit confusing if you don't understand the process. > > > > > > Cjeers. -- justin > > > > > > On Sun, Jan 3, 2016 at 10:31 PM, Lei Chang <[email protected]> > > wrote: > > > > Greetings. > > > > > > > > I have added a page that summarizes all the discussions so far for > any > > > > further comments. > > > > > https://cwiki.apache.org/confluence/display/HAWQ/Becoming+a+committer > > > > > > > > Cheers > > > > Lei > > > > > > > > > > > > > > > > On Mon, Dec 28, 2015 at 9:17 AM, Lei Chang <[email protected]> > > > wrote: > > > > > > > >> > > > >> Hi Justin, > > > >> > > > >> Thanks for the great suggestions and references. > > > >> > > > >> I will add more information around sustained contributions for > further > > > >> discussions. > > > >> > > > >> Cheers > > > >> Lei > > > >> > > > >> > > > >> On Sun, Dec 27, 2015 at 4:31 AM, Justin Erenkrantz < > > > [email protected]> > > > >> wrote: > > > >> > > > >>> Hi Lei, > > > >>> > > > >>> I have two additional comments to add to what Roman and Cos already > > > said. > > > >>> > > > >>> In the early stages of the Incubation process, it's probably better > > to > > > >>> err on the side of inclusion. Especially given the early adoption > of > > > >>> RTC, code contributions will be vetted. Not everyone is going to > be > > > >>> able work on HAWQ full-time - nor should that be a gatekeeper for > > > >>> commit access. Chances are that folks who contribute at this early > > > >>> stage could be nurtured into being fantastic contributors. As a > > > >>> mentor, this is one of the criteria I'd like to see before > graduation > > > >>> - are projects accepting of contributors who show up and recognize > > > >>> them accordingly? > > > >>> > > > >>> I would also think it'd be a good idea to think - and document - > what > > > >>> the definition of sustained contributions are. While it doesn't > have > > > >>> to be concrete (e.g. number of patches or months), there should be > > > >>> some guidance available. > > > >>> > > > >>> Subversion has some useful docs that may be worth perusing at: > > > >>> > > > >>> http://subversion.apache.org/contributing.html > > > >>> > > > > http://subversion.apache.org/docs/community-guide/roles.html#committers > > > >>> > > > >>> Cheers. -- justin > > > >>> > > > >>> On Thu, Dec 24, 2015 at 9:30 PM, Lei Chang <[email protected] > > > > > >>> wrote: > > > >>> > @konstantin, concur with you on the contribution scope, not > > everyone > > > >>> can do > > > >>> > all of the things or want to do everything, contributors that > have > > > >>> > contributed a lot to one area should be welcomed as a committer. > > > >>> > > > > >>> > Cheers > > > >>> > Lei > > > >>> > > > > >>> > > > > >>> > On Fri, Dec 25, 2015 at 1:57 AM, Konstantin Boudnik < > > [email protected]> > > > >>> wrote: > > > >>> > > > > >>> >> It's up to the community to decide what's the entry barrier, but > > > here > > > >>> a few > > > >>> >> points to consider: > > > >>> >> - not everybody worthy a committer-ship might be interested in > > > doing > > > >>> the > > > >>> >> whole laundry list below > > > >>> >> - Apache projects are collectives of volunteers, contributing > > where > > > >>> there > > > >>> >> want to and when they have time for it. Expecting every and > > each > > > >>> one of > > > >>> >> them to cover 27 different areas of possible contributions > will > > > >>> slow the > > > >>> >> community growth to halt > > > >>> >> - IIRC, this project decided to stick to RTC, which is proven > to > > > have > > > >>> a > > > >>> >> slow-down effect on the participation rate, so be extra > careful > > > >>> setting > > > >>> >> such a high bar > > > >>> >> > > > >>> >> None of what I said means that sloppy coders or arrogant > > jack-asses > > > >>> should > > > >>> >> be > > > >>> >> welcomed with open arms. Say, there's someone who's doing great > > job > > > in > > > >>> the, > > > >>> >> say, query optimization part of the project, helps others to > > > understand > > > >>> >> his work and gives feedback to other contribution in the same > > area. > > > If > > > >>> the > > > >>> >> same time the guy doesn't give a hoot about anything else in the > > > >>> project - > > > >>> >> he > > > >>> >> should be invited as a committer. But per the following > > guidelines, > > > he > > > >>> >> would > > > >>> >> never be welcomed here. > > > >>> >> > > > >>> >> Something to think about, perhaps. > > > >>> >> Cos > > > >>> >> > > > >>> >> On Thu, Dec 17, 2015 at 02:50PM, Lei Chang wrote: > > > >>> >> > We do not have a finalized answer for this yet. I summarized > the > > > >>> points > > > >>> >> > from previous discussions. > > > >>> >> > > > > >>> >> > There are no hard and fast rules, but here are a few things > that > > > >>> >> typically > > > >>> >> > would prompt considering somebody a candidate for a committer > > > >>> >> > 1. participation in the mailing list conversations > > > >>> >> > 2. code contributions (patches submitted to JIRA or PRs) > > > committed > > > >>> >> > by existing committers > > > >>> >> > 3. documentation contributions > > > >>> >> > 4. wiki/social media contributions > > > >>> >> > 5. review of patches submitted by others > > > >>> >> > 6. reviews of release candidates > > > >>> >> > 7. bug reports > > > >>> >> > 8. work with peers collaboratively and potentially as a > > mentor > > > to > > > >>> new > > > >>> >> > contributors > > > >>> >> > > > > >>> >> > More discussions are welcomed :-) > > > >>> >> > > > > >>> >> > Cheers > > > >>> >> > Lei > > > >>> >> > > > > >>> >> > > > > >>> >> > > > > >>> >> > On Tue, Dec 8, 2015 at 1:15 PM, Lei Chang < > > [email protected] > > > > > > > >>> >> wrote: > > > >>> >> > > > > >>> >> > > > > > >>> >> > > My thought is that a committer should be able to act as a > > > mentor, > > > >>> work > > > >>> >> > > with peers collaboratively and contribute to the project > > > >>> continuously > > > >>> >> or a > > > >>> >> > > long time period. > > > >>> >> > > > > > >>> >> > > What do you guys think? > > > >>> >> > > > > > >>> >> > > Cheers > > > >>> >> > > Lei > > > >>> >> > > > > > >>> >> > > > > > >>> >> > > > > > >>> >> > > On Tue, Dec 8, 2015 at 6:38 AM, Roman Shaposhnik < > > > >>> [email protected] > > > >>> >> > > > > >>> >> > > wrote: > > > >>> >> > > > > > >>> >> > >> Lei, what are your thoughts on the required level of > > > >>> >> > >> contribution to be considered? > > > >>> >> > >> > > > >>> >> > >> Thanks, > > > >>> >> > >> Roman. > > > >>> >> > >> > > > >>> >> > >> On Sun, Dec 6, 2015 at 11:57 PM, Lei Chang < > > > >>> [email protected]> > > > >>> >> > >> wrote: > > > >>> >> > >> > add the link: > > > >>> >> > >> > > > > >>> > http://community.apache.org/newcommitter.html#new-committer-process > > > >>> >> > >> > > > > >>> >> > >> > On Mon, Dec 7, 2015 at 3:57 PM, Lei Chang < > > > >>> [email protected]> > > > >>> >> > >> wrote: > > > >>> >> > >> > > > > >>> >> > >> >> > > > >>> >> > >> >> Here is the common apache process for becoming a new > > > committer. > > > >>> >> > >> >> > > > >>> >> > >> >> Cheers > > > >>> >> > >> >> Lei > > > >>> >> > >> >> > > > >>> >> > >> >> > > > >>> >> > >> >> > > > >>> >> > >> >> On Mon, Dec 7, 2015 at 11:07 AM, Roman Shaposhnik < > > > >>> >> > >> [email protected]> > > > >>> >> > >> >> wrote: > > > >>> >> > >> >> > > > >>> >> > >> >>> Hi Xin! > > > >>> >> > >> >>> > > > >>> >> > >> >>> this is a great question. Certainly this is something > > that > > > >>> HAWQ > > > >>> >> > >> >>> community has to ponder soon enough. There are no hard > > and > > > >>> >> > >> >>> fast rules, but here are a few things that typically > > would > > > >>> prompt > > > >>> >> > >> >>> considering somebody a candidate for a committer: > > > >>> >> > >> >>> 1. participation in the mailing list conversations > > > >>> >> > >> >>> 2. code contributions (patches submitted to JIRA or > > PRs) > > > >>> >> committed > > > >>> >> > >> >>> by existing committers > > > >>> >> > >> >>> 3. documentation contributions > > > >>> >> > >> >>> 4. wiki/social media contributions > > > >>> >> > >> >>> 5. review of patches submitted by others > > > >>> >> > >> >>> 6. reviews of release candidates > > > >>> >> > >> >>> 7. bug reports > > > >>> >> > >> >>> > > > >>> >> > >> >>> If the behavior of contributing to the project in a > > > variety of > > > >>> >> > >> different > > > >>> >> > >> >>> ways > > > >>> >> > >> >>> continues for a few months I think it is reasonable to > > > expect > > > >>> that > > > >>> >> > >> your > > > >>> >> > >> >>> merit should be considered as a basis for commitership. > > > >>> >> > >> >>> > > > >>> >> > >> >>> Thanks, > > > >>> >> > >> >>> Roman. > > > >>> >> > >> >>> > > > >>> >> > >> >>> On Fri, Dec 4, 2015 at 5:49 PM, Xin Zhang < > > > [email protected]> > > > >>> >> wrote: > > > >>> >> > >> >>> > Hi HAWQ devs, > > > >>> >> > >> >>> > > > > >>> >> > >> >>> > I recently started contributing to apache-hawq. > > > >>> >> > >> >>> > > > > >>> >> > >> >>> > I am wondering what's bar to be considered at a > > > committer, > > > >>> and > > > >>> >> > >> what's > > > >>> >> > >> >>> the > > > >>> >> > >> >>> > process to submit a request, and when PMC can review > > the > > > >>> >> request. > > > >>> >> > >> >>> > > > > >>> >> > >> >>> > I am pretty new to OSS as well as this project, and > any > > > >>> >> guidance is > > > >>> >> > >> >>> greatly > > > >>> >> > >> >>> > appreciated. > > > >>> >> > >> >>> > > > > >>> >> > >> >>> > -- > > > >>> >> > >> >>> > Thanks, > > > >>> >> > >> >>> > Shin > > > >>> >> > >> >>> > > > >>> >> > >> >> > > > >>> >> > >> >> > > > >>> >> > >> > > > >>> >> > > > > > >>> >> > > > > > >>> >> > > > >>> > > > >> > > > >> > > > > > > > > > -- > Greg Chase > > Director of Big Data Communities > http://www.pivotal.io/big-data > > Pivotal Software > http://www.pivotal.io/ > > 650-215-0477 > @GregChase > Blog: http://geekmarketing.biz/ >
