https://issues.apache.org/jira/browse/CB-11916 proceeding with a docs PR.
On Fri, Sep 16, 2016 at 4:12 PM, Shazron <[email protected]> wrote: > Ok looks like we have consensus. I'll add a section here: > http://cordova.apache.org/contribute/ and send a PR to the cordova-docs > repo for comment. > > On Tue, Sep 13, 2016 at 11:37 AM, Steven Gill <[email protected]> > wrote: > >> +1 >> >> On Tue, Sep 13, 2016 at 11:09 AM, Simon MacDonald < >> [email protected] >> > wrote: >> >> > +1 to making it easier to allow people to contribute trivial changes. >> > >> > One thing Shaz just mentioned was adding a check box the the PR >> template so >> > that people can explicitly indicate their intent. >> > >> > Eventually it would be nice to be able to digitally sign the CLA. >> > >> > Simon Mac Donald >> > http://hi.im/simonmacdonald >> > >> > On Tue, Sep 13, 2016 at 11:01 AM, Shazron <[email protected]> wrote: >> > >> > > 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 <[email protected]> >> 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 <[email protected]> >> > 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 <[email protected]> >> > > 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 <[email protected] >> > >> > > > 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 < >> [email protected] >> > > >> > > > > wrote: >> > > > > > > >> > > > > > > > +1 >> > > > > > > > >> > > > > > > > >> > > > > > > > @purplecabbage >> > > > > > > > risingj.com >> > > > > > > > >> > > > > > > > On Tue, Sep 13, 2016 at 10:27 AM, Shazron < >> [email protected]> >> > > > 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 < >> [email protected]> >> > > > 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- >> > > > > > > [email protected] >> > > > > > > > > %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 >> > > > > > > > > > [email protected] 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. >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> > >
