Comments (37)
Today (2022-03-03) during the Steering Meeting we discussed switching over to the DCO. As part of the CNCF onboarding, we need to decide on which one we are using. Steering is leaning towards using DCO for a few reasons. Here's main reasons for switching to DCO:
- Self-service aspect. When DCO fails, the user can by looking at the error message get the cut&paste commands to fix it themselves
- Some companies can't really sign the CLA for one reason or another. This has introduced friction for new community members and adoption.
- CNCF has approved the use of DCO, which was not the case with Google due to legal concerns. With the move to CNCF, this is no longer a blocker.
from community.
Unless something else comes up, we're going to finalize the switch to EasyCLA next Thursday: 2022-03-31.
Speak up if you have grave concerns or additions to the great discussion of pros/cons above.
from community.
There's some work in redoing the robot to make it less cumbersome. @thisisnotapril to follow up with the team on rough timelines, etc.
from community.
Just a quick update on this from yesterdays SC meeting. @thisisnotapril said the target for the new CLA bot is Nov 1st. It will make multi-author / cp much easier.
Also anybody with commit rights can trigger a rescan of the CLA. Flipping the bit still requires Googler magic.
from community.
But I'm not sure there really is anyone who fits that last bucket. Using DCO is just adding a signature at the bottom of each commit, declaring yourself as the author, e.g.
The mechanical steps are one thing, whether your organization permits you to do that is another. The permission dimension is the one I was referring to. Does that make sense?
from community.
I've got it now per #952 (comment)
I have a couple of open tickets - one with the Linux Foundation and one with CNCF, to get access to the EasyCLA dashboard/portal before I can set it all up for Knative.
from community.
DCO!
from community.
@duglin I find DCO to be even more frustrating to use.
from community.
@duglin I find DCO to be even more frustrating to use.
I've contributed to envoy - it's just a matter of adding a -s
like so
git commit -s
from community.
I'm aware of a few issues with the Google CLA bot. I believe we've been working with the team that owns the tool to see if we can improve the issue for multiple owners. The good thing is that we can work around the tool as necessary. If there's more feedback we can take to the team to improve how the bot works on a project like this, I'd love to capture that feedback and share it.
With the structure of the project, the Google CLA is still required to be signed by all contributors or their organizations, which means we're not at the liberty to remove the Google CLA bot.
from community.
from community.
Yes, with Google's ownership of the project and needing contributors to grant a license of the intellectual property, we need the Google contributor license agreement to be signed by all contributors. Creating our own Knative CLA bot to enforce a Knative-specific CLA would not be something that the steering committee can decide directly.
I'd like to better understand the impact of the CLA bot not functioning well in this scenario is causing to the overall productivity for the project, since that appears to be what this issue is about. If there are concerns with the contents or requirements of the Google CLA, I'm also interested in hearing those concerns, but I think that's a separate issue from what was raised here (although the two were conflated in the original post).
We always want to do the right thing for the community -- so I do want to make sure we understand the issue clearly.
from community.
While not a blocker for IBM, I do know that having a company specific CLA on an open source project does raise some eyebrows during our internal reviews. And I have heard from other companies that they've run into similar concerns and even roadblocks over it. This falls into the category of "bad optics" when trying to convince people that this really is an open-source project and not just a Google project that allows other people to participate.
This also is related to a question that I believe has been asked before... what exactly does the SC have control over? Most of the conversations have been around Google wanting to retain trademark enforcement, and now we have this. It begs the question... what other areas of control does Google have that people might assume are community/SC owned?
I still question why we can't just use DCOs? Even with "Google's ownership of the project" (which is an interesting phrase unto itself), a DCO should be allowable and help remove some barriers for people.
from community.
The good thing is that we can work around the tool as necessary.
The only folks who can work around it are from Google. Which leads to a lot of "haallllp I need a googler..."
from community.
Couple interesting articles that came up on a recent twitter thread:
- https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
- https://opensource.com/article/19/2/cla-problems
Firecracker seems to use inbound=outbound (from the second article)
from community.
Quoting the first article:
Meanwhile, the issue of requesting the contributors' assent to the projects' license is
orthogonal to the issue of CLAs. Conservancy does encourage use of clear systems (either
formal or informal) for that purpose. One popular option is called the Developer Certificate of
Origin (DCO).
from community.
I don't understand why the CLA bot won't even rescan for non-Googlers 🙄
See here: knative-extensions/net-contour#108 (comment)
from community.
Bot issues aside; I believe everyone on the thread is covered by a corporate CLA already. Information on the Google CLA and the reasoning is here: https://opensource.google/docs/cla/policy/
from community.
I don't understand why the CLA bot won't even rescan for non-Googlers 🙄
See here: knative/net-contour#108 (comment)
That's a good point; I'll ask the team about it and see what we could potentially do to make that process easier. Has there been any success with closing and reopening PRs and force a rescan? That works in other orgs with other bots; curious if it would work here.
from community.
@thisisnotapril do you happen to have any updates on this issue?
from community.
Current ETA for the new bot is end of Q2
from community.
What's fixed in the new CLA bot?
from community.
Did the new bot get deployed? @thisisnotapril
from community.
It's exciting to see progress on this front and moving towards a better solution here!
from community.
Here is how I see the scope of choice here:
- First, and above all else, I think we should be optimizing for ease of contribution / lowest coefficient of friction in making the first PR, for the highest percentage of potential contributors
- I believe it is fair to say there is no perfect choice that will be equally usable by every potential contributor
- I believe it is also fair to say that the implications of providing a DCO versus signing a CLA are difficult for most people who aren’t IP lawyers to understand
- I believe that most current contributors to any CNCF project have signed the CLA (but I have no proof of this beyond the fact that the CNCF CLA existed before the CNCF allowed the use of DCO)
- I also believe that most organizations with people currently contributing to CNCF projects have had sufficient time to digest the implications of their people signing the CNCF CLA
Some companies can't really sign the CLA for one reason or another.
This got me thinking about how to model the choices here.
Ack that as an issue that we know was present with the Google CLA. Do we know of specific examples where potential contributors are prevented from signing the CNCF CLA? I am not attempting to express skepticism that some folks may be in that situation, but I would be willing to bet that CNCF CLA is lower friction than one specific to a particular company.
I also wonder what the relative frequency of cases where potential contributors may be prevented from using a DCO is. Do we have any idea?
I think these are the buckets of people to quantify:
- People who have already signed the CNCF CLA and would have zero friction to new contributions if we adopted the CNCF CLA
- People who have not already signed the CNCF CLA, could sign the CLA, could use DCO
- People who have not already signed the CNCF CLA, could not sign the CLA, could use DCO
- People who have not already signed the CNCF CLA, could sign the CLA, could not use DCO
Are those the right buckets? I think we should be framing our choice around the relative quantities of these different buckets. Thoughts?
from community.
I believe that most current contributors to any CNCF project have signed the CLA (but I have no proof of this beyond the fact that the CNCF CLA existed before the CNCF allowed the use of DCO)
Only a single data point, but I for one have not. I do contribute to and maintain CNCF projects that use DCO. I have signed the Google CLA as an individual contributor, however.
- People who have already signed the CNCF CLA and would have zero friction to new contributions if we adopted the CNCF CLA
I believe that the CLA / DCO requirement applies to each project. I could be mistaken, but as I understand it, there is not a blanket CLA for all CNCF projects. So there is no scenario where users have zero friction. In any case, the requirements in cncf/toc#794 say that each project in the knative
and knative-sandbox
organizations will need to enable either EasyCLA or DCO in their GitHub orgs. I'm not sure if we will be able to have a single CLA that covers all repositories, but that seems like a reasonable expectation. If this is the case, then the buckets might be more like this.
- People who could sign the CLA, could use DCO
- People who could not sign the CLA, could use DCO
- People who could sign the CLA, could not use DCO
But I'm not sure there really is anyone who fits that last bucket. Using DCO is just adding a signature at the bottom of each commit, declaring yourself as the author, e.g.
Signed-off-by: Lance Ball <[email protected]>
If we can also eliminate the group of those who cannot use DCO as a bucket, then we end up with
- People who could sign the CLA, could use DCO
- People who could not sign the CLA, could use DCO
Meaning there simply are more people who can use DCO vs CLA (if you accept all of my statements above, anyway). But the biggest bucket doesn't really mean it's the right answer, if using the DCO is considered to be too much friction. The DCO requires action on every commit, whereas the CLA is once and done. I personally don't have very strong feelings, but I use DCO for CloudEvents and --signoff
just what my fingers do naturally when I'm typing git commit
now, so I don't find it to be burdensome. That may not be the case for everyone.
from community.
I could be mistaken, but as I understand it, there is not a blanket CLA for all CNCF projects.
I believe there is one and only one. Let’s find out for sure.
from community.
I could be mistaken, but as I understand it, there is not a blanket CLA for all CNCF projects.
I believe there is one and only one. Let’s find out for sure.
If this is the case, then it does reduce friction, IMO.
from community.
There is also this: https://easycla.lfx.linuxfoundation.org/
from community.
I wrote
I'm not sure if we will be able to have a single CLA that covers all repositories, but that seems like a reasonable expectation.
Scott wrote
There is also this: https://easycla.lfx.linuxfoundation.org/
It looks like EasyCLA will allow us to have one CLA covering all repos, based on my reading of this.
Project managers and maintainers can set up EasyCLA to automatically discover and protect new repositories, or can keep direct control over which repos are protected. (https://lfx.linuxfoundation.org/tools/easycla)
This is not the same as a blanket CNCF CLA (I am skeptical about that even being a thing), but it is "once and done" for ALL Knative repos, which is appealing.
from community.
Related to [INCUBATING PROJECT ONBOARDING] Knative cncf/toc#794
from community.
I asked in the CNCF Slack #easycla
channel about the CLA vs. DCO here what I got back
-
moving to easyCLA every current active contributor will be able to onboarded/seed them to initial people into the list, or everyone would need to interact with the tool to signed the new CLA?
- Yes every current active contributor will be onboarded. We call it migration. They won't have to interact with the CLA tool. If you have CLA Managers for different companies they will also be migrated along with their approved lists.
-
Is there a global “CNCF CLA” or we need to create a specific new “Knative CLA”?
- There is a global CNCF CLA that is applicable to all projects that fall within CNCF.
-
Related to global clearance ^^ if someone that signed the easyCLA for kubernetes will not need to sign a CLA to contribute to knative since they already signed the global “CNCF CLA” or there is not such thing and what they signed is “Kubernetes CLA” only for k8s repos?
- Anyone covered under global CNCF CLA can contribute to any project within CNCF
-
When using easyCLA can manage two knative orgs? Can it be configure to handle all repos across the two orgs?
- Yes
-
If your using easyCLA and you had to go in time would you preferred DCO instead?
- If you are already on EasyCLA you wouldn't switch to DCO. Here is a link to EasyCLA webinar. At the beginning of this webinar Steve Winslow has covered some differences between EasyCLA and DCO. https://www.linuxfoundation.org/webinars/lfx-easycla-streamline-your-development-workflow/
from community.
Are we still moving forward with the switch to EasyCLA? Looks like the Google CLA is still in place here.
from community.
Yes, that was the decision.
from community.
Who is on point for the switch? Wondering what we need to do next.
from community.
@csantanapr is driving it here:
#952
from community.
@hh ^
from community.
Related Issues (20)
- PROCESS CHANGE: 🚨 Code of Conduct reporting mechanism for Knative is obsolete HOT 6
- New Repo: `autoscaler-keda` HOT 14
- UX WG designs contingency plan HOT 6
- 🚨 PROCESS CHANGE: Merging some working groups and committees to better reflect current contributor engagement HOT 21
- PROCESS CHANGE: Merge Client and Functions WG together HOT 26
- Revive Google Analytics access HOT 3
- New Repo: `func-python` HOT 6
- Need clarification on logos of 3 specific 'adopters' HOT 5
- Archive knative-extensions/net-certmanager HOT 1
- PROCESS CHANGE: Writers or WG leads should get admin powers to repos HOT 4
- PROCESS CHANGE: Introduction of Office Hours HOT 9
- PROCESS CHANGE: Enhancing Onboarding HOT 5
- PROCESS CHANGE: Improving Issue Labeling Practices HOT 1
- PROCESS CHANGE: Revamped Social Media Presence
- PROCESS CHANGE: Monthly Community Hangout Calls
- PROCESS CHANGE: Establishing Clear Growth Paths in the Community
- PROCESS CHANGE: Personalized One-on-One Meetings for New Contributors HOT 2
- PROCESS CHANGE: Anonymous Feedback Mechanism HOT 3
- Enable OpenSSF Scorecard to enhance security practices across the project HOT 3
- Where do you see Knative in 5 years? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from community.