An easy definition of trivial IMO is "if they decide to pull this code away from us, is it not a big deal?"
The reasons why the code needs to be pulled, who knows what lurks in the minds of lawyers. Typos, doc changes, one liners, are not a big deal usually. On Tue, Sep 13, 2016 at 10:53 AM, Jesse <purplecabb...@gmail.com> wrote: > Yes, that is the point. Sending a PR is intent! > BUT if it is a large change, we need insurance that it is the work of the > contributor, and not copy/pasted from somewhere else, and that they cannot > retract it later. This is what the CLA offers us. > Currently, as Shaz pointed out above, we state firmly that we require an > iCLA, so this will simply state more clearly how we work with PRs. > > > @purplecabbage > risingj.com > > On Tue, Sep 13, 2016 at 10:46 AM, Joe Bowser <bows...@gmail.com> wrote: > > > So, it's basically the same system that we have now. I still think we > > should get clear intent from the author, since that's more useful and > easy > > than determining whether it's trivial. I mean, isn't sending a PR > through > > GitHub already clear intent? > > > > On Tue, Sep 13, 2016 at 10:41 AM, Jesse <purplecabb...@gmail.com> wrote: > > > > > You decide per pr if you think it is trivial. > > > > > > > > > @purplecabbage > > > risingj.com > > > > > > On Tue, Sep 13, 2016 at 10:36 AM, Joe Bowser <bows...@gmail.com> > wrote: > > > > > > > I'll agree to this, since I don't know what the definition of trivial > > is > > > > w.r.t. Apache. > > > > > > > > +1 > > > > > > > > On Tue, Sep 13, 2016 at 10:30 AM, Jesse <purplecabb...@gmail.com> > > wrote: > > > > > > > > > +1 > > > > > > > > > > > > > > > @purplecabbage > > > > > risingj.com > > > > > > > > > > On Tue, Sep 13, 2016 at 10:27 AM, Shazron <shaz...@gmail.com> > wrote: > > > > > > > > > > > Bump. There can't be lazy consensus on this. Before I potentially > > > waste > > > > > > time on drafting a proposal, trying to feel the temperature on > this > > > > > change. > > > > > > > > > > > > On Fri, Sep 9, 2016 at 3:34 PM, Shazron <shaz...@gmail.com> > wrote: > > > > > > > > > > > > > It's up to us to decide, and right now we require the iCLA > except > > > for > > > > > > > trivial contributions. > > > > > > > > > > > > > > I want to change this to a more relaxed requirement: > > > > > > > 1. Non-committers do not require an iCLA (you need one anyway > to > > > get > > > > an > > > > > > > account, so that's really a non-issue) > > > > > > > 2. Require a clear intent by the author to contribute under our > > > > normal > > > > > > > terms, for a non-trivial change > > > > > > > > > > > > > > So some of you will be wondering, what does Apache say about > > this? > > > > > > > From: http://mail-archives.apache.org/mod_mbox/www-infrastru > > > > > > > cture-dev/201112.mbox/%3CA603FFCE-623B-43E9-87F8- > > > > 39baa51c7...@gbiv.com > > > > > > %3E > > > > > > > > > > > > > > Roy Fielding: > > > > > > > "Yes, that opinion comes from me speaking as a board member and > > > > > > > author of the Apache License, and has previously been cleared > > > > > > > with Apache's legal team for a long ago discussion with > > Incubator. > > > > > > > We don't need a CLA on file to accept contributions from > > > > > non-committers. > > > > > > > We just need a clear intent by the author to contribute under > > > > > > > our normal terms." > > > > > > > > > > > > > > Other opinions: http://apetro.ghost.io/apache- > > contributors-no-cla/ > > > > > > > > > > > > > > We need to change our Contribute page: > > > > > > > http://cordova.apache.org/contribute/ > > > > > > > > > > > > > > ... as well as any PR templates: > > > > > > > https://github.com/apache/cordova-plugin-media/blob/master/. > > > > > > > github/PULL_REQUEST_TEMPLATE.md > > > > > > > > > > > > > > This declaration of intent, if posted on Github, will be > > reflected > > > on > > > > > > > dev@cordova.apache.org since Apache sends out an email on each > > PR > > > or > > > > > > > comment to a PR, so we will be able to track it in our > archives. > > > > > > > > > > > > > > As usual it is always the committer's responsibility to make > sure > > > > that > > > > > > all > > > > > > > code they push to a repository is compliant with ASF policies. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >