"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. The way we see it, when we receive a PR on an Apache repo from a random ontributor 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. 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
