Hi Raihaan, Yes, at least it is what our documentation says: *"If you work on Jenkins core on behalf of your employer, your company needs to have CCLA in place. Have CCLA printed, signed, scanned back to PDF, then send it to jenkinsci-...@googlegroups.com along with your account on Jenkins <https://jenkins-ci.org/account>."*. https://github.com/jenkinsci/infra-cla#corporate-cla
So, if you work on the Jenkins core as your wok responsibilities, it would need CCLA. If you do it during your spare time, it is not needed. Our ICLA covers the end responsibility of a contributor to ensure the permissive license anyway anyway in (4): "You represent that you are legally entitled to grant the above license. If your employer(s) has rights to intellectual property that you create that includes your Contributions, you represent that you have received permission to make Contributions on behalf of that employer, that your employer has waived such rights for your Contributions to the Project, or that your employer has executed a separate Corporate CLA with the Project.". There is "OR" in the end here. BR, Oleg On Monday, January 27, 2020 at 5:11:04 PM UTC+1, Raihaan Shouhell wrote: > > I was under the impression that a CCLA has to be filed first, is my > assumption wrong? > I'm currently in the process of getting that sorted out > > On Monday, 27 January 2020 04:31:06 UTC+8, Oleg Nenashev wrote: >> >> One thing to mention is that I will be traveling on Jan 29 ... Feb 08: >> FOSDEM and then a business trip. This time my time will be really limited, >> and it is safe to assume that I will not be available to review and merge >> pull requests. On the other hand, I also will unlikely be available for >> timely Q&A. After considering options, my preference was to add more >> maintainers and to do the best efforts on the documentation fronts before I >> go off. >> >> Regarding the permissions, I am waiting for the Weekly release with >> regression patches and for ICLA submission from Raihaan >> >> I wonder about the methodology used here though. The data is objective, >>> but do these numbers actually tell us something useful, other than that >>> Gavin's recent (awesome) contributions to the project are elsewhere? This >>> seems akin to counting lines of code changed as a proxy for productivity. >>> >> Be sure I recognize and hugely appreciate Gavin's contributions. At the >> moment they just do not go into the Jenkins core, and hence Gavin was not >> in my list for Core maintainers. If others would like to add Gavin to the >> core maintainers team, I would be happy to support it. Regarding my >> methodology, I just used the existing queries, they do not represent >> quality of the reviews and other factors. If anyone wants to introduce >> better metrics and to reconsider the list, be my guest :) >> >> I'd also like to recommend that we emphasize the need to evaluate the >>> usefulness of contributions in the maintainer guidelines. Not all >>> contributions make sense to merge, and even useful contributions might >>> result in weird inconsistencies or even problems across the whole of >>> Jenkins if accepted as submitted. There's some subjectivity here, but even >>> if you tend to be lenient on such matters, please still consider these >>> issues and don't simply focus on whether the code works in isolation; >>> that's not how it's going to affect users. >>> >> Duly noted, I will add it explicitly to the maintainer docs >> >> BR, Oleg >> >> >> >> >> On Saturday, January 25, 2020 at 11:44:10 PM UTC+1, Daniel Beck wrote: >>> >>> >>> >>> > On 21. Jan 2020, at 13:01, Oleg Nenashev <o.v.n...@gmail.com> wrote: >>> > >>> > TL;DR: I propose to expand the Jenkins Core maintainers team by >>> inviting the most active code reviewers to the team. >>> > >>> >>> I'm all for adding more active maintainers, so +1. It's been nice >>> actually getting reviews for submissions (and with this change they will >>> even be green, not grey!). >>> >>> I wonder about the methodology used here though. The data is objective, >>> but do these numbers actually tell us something useful, other than that >>> Gavin's recent (awesome) contributions to the project are elsewhere? This >>> seems akin to counting lines of code changed as a proxy for productivity. >>> >>> >>> > • We ensure that there is a knowledge transfer process established to >>> help new maintainers >>> > • We start doing regular office hours with Q&A and joint PR >>> grooming/review sessions, e.g. every 2 weeks. I am ready to run such >>> sessions >>> > • Maintainer guidelines and best practices are documented in the >>> Jenkins core repo. We will gradually create this documentation together >>> during KT sessions >>> >>> >>> I'd also like to recommend that we emphasize the need to evaluate the >>> usefulness of contributions in the maintainer guidelines. Not all >>> contributions make sense to merge, and even useful contributions might >>> result in weird inconsistencies or even problems across the whole of >>> Jenkins if accepted as submitted. There's some subjectivity here, but even >>> if you tend to be lenient on such matters, please still consider these >>> issues and don't simply focus on whether the code works in isolation; >>> that's not how it's going to affect users. >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/667197a7-00ee-42d9-8eab-f73830adb357%40googlegroups.com.
