Op ma 21 jan. 2019 om 20:25 schreef Joan Touzet <woh...@apache.org>: > "Mark Thomas" <ma...@apache.org> wrote: > > On 21/01/2019 17:59, Roy Lenferink wrote: > > > CNCF is using a bot on their GitHub repositories which adds a label > > > to > > > every pull request whether the contributor has a cla on file > > > [1][2]. > > > More info on this here [3] > > > The cla label is checked before the PR can be merged. > > > > > > As we're moving to a broader GitHub integration maybe it is an idea > > > to use > > > a technology like this as well. > > > > That would make CLAs mandatory and I disagree very strongly with any > > move in that direction. > > Absolutely agree with Mark here. >
That indeed is a huge disadvantage as well. It isn't that I'm all for requiring CLAs, as it will block simple bug fixes as well, but at least I think it would be good to maybe enhance the process, e.g. a bot adding a "cla:no" or "cla:yes" label doesn't harm anyone, and if a contributor is submitting a PR with a sufficient amount of changes it makes it easier for the committer to verify whether the contributor has a CLA filed. But that's just my opinion. It's not a problem at all if anyone thinks differently. I'm just trying to figure out what would be best ;) > > The way we see it, when we receive a PR on an Apache repo from a random > contributor that is merged by a committer, it is the committer who is > responsible for the code, and the committer who has already signed > the CLA. > IMO this is not completely true. I think it indeed is the responsibility of the committer to check whether a contributor needs to file an ICLA, but it still is the contributor who actually committed the change and it's the contributor's name and e-mail that will be listed as author for the commit. The ASF committer just simply merged the commit back to the repo (knowing he has to check licenses for used technology etc..). But again, please correct me if I'm wrong. > > This is no different from when we used to receive .patch files by > mailing list or JIRA. They arrived plenty of times from people > who didn't have signed CLAs or commit bits. It was the committer's > responsibility to review and accept the code, and it was their > liability if something went wrong. This extends to any version > controlled asset. > > Wikis are weird - we've dropped use of ours for most things, since > there was misleading, confusing, and outdated content in ours, chiefly > because there was no Review-Then-Commit model. GitHub PRs are RTC, > not CTR, so the safeguard is built in. I can see the desire for a > CLA to be signed when there is only a CTR process available. > > Communities that require CLAs to be signed before code can even be > proposed for merging in a pull request, emailed patch or simlar > definitely show a lower rate of participation than those who don't > in my experience. > > -Joan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org > For additional commands, e-mail: dev-h...@community.apache.org > >
