toggle quoted messageShow quoted text
Reminder that tomorrow's meeting is on the new APAC friendly 6pm time, so we can have our Chinese language SIG contributor join us.
On Mon, May 18, 2020 at 6:19 AM Dan Lorenc via lists.cd.foundation <dlorenc=google.com@...> wrote:
I've added this to tomorrow's TOC agenda. Thanks Oleg!
Hi Dan and all,
One thing to keep in mind is that there is already a 2.0 version of Contributor Covenant. There are some differences.
Just in case, are there any plans to upgrade the Code of Conduct on the CDF side?
Once I know the target version for CDF, I will start the discussion about aligning the Contributor Covenant version in Jenkins.
Our version is old, and there are some statements in newer versions which would be a good addition.
On Thu, May 7, 2020, 02:16 Michael Galloway via lists.cd.foundation <mgalloway=netflix.com@...> wrote:
On Wed, May 6, 2020 at 2:26 PM Dan Lorenc via lists.cd.foundation <dlorenc=google.com@...> wrote:
Great points. I think we should encourage the CDF Code of Conduct by default, but allow others with good reason after a review. Project-level escalation sounds great as well. The CDF could be used as a second level of escalation if necessary.
Any thoughts from others here?
I have another question about the current graduation requirements. Currently projects are expected to adopt the CDF Code of Conduct
to graduate. In the case of the Jenkins project we have our own code of conduct
which is an adopted version of Contributor Covenant
1.3 widely used in open-source projects. CDF Code of Conduct uses version 1.4 and there are some differences.
What does "Code of Conduct adoption" mean in practice?
- Would it be enough to ensure that we use the same Contributor Covenant version in our project? Or would CDF TOC expect wider changes, e.g. replacing CoC completely by the CDF one?
- Would we be expected to switch the escalation/enforcement process to conduct@...? Currently the Jenkins project has its own escalation and enforcement process, managed by the Jenkins Governance Board.
On Mon, Apr 27, 2020 at 4:07 PM Dan Lorenc via lists.cd.foundation <dlorenc=google.com@...> wrote:
I think we'll need to quickly get a plan together for security audits at the CDF level.
I also have a question about a 3rd-party security audit defined by Dan Lopez in
. It may cost a lot for a big project like Jenkins if we want to have a formal security audit by a 3rd party. Just in case, does CDF have budget allocated for such audit in CDF projects? If not, such criteria may become a major obstacle.
Thanks in advance,
On Fri, Apr 24, 2020 at 5:29 PM Tracy Miranda <tmiranda@...
+1 good to have clarity then dog-food our own processes.
While it might be strange for some to see Jenkins 'graduate' think it will be good due-diligence and a good example for rest of the projects (not to mention more reasons to celebrate!)
On Fri, Apr 24, 2020 at 11:27 AM Dan Lorenc via lists.cd.foundation <dlorenc=google.com@...> wrote:
There's been some confusion around CDF project graduation/incubation statuses and I want to try to clear that up. If I remember correctly, when the initial projects came into the CDF we decided to keep them all at incubation status, even though some were likely to graduate quickly.
The plan was to firm up the graduation criteria, then move the more mature projects through this process as a trial run.
Does that still make sense to everyone? If so, I'd like to take a pass at the graduation criteria, then start to move Jenkins through to make sure the process makes sense and works.
Michael Galloway | Delivery Engineering
mgalloway@... | m: 408.234.5205
Engineering Manager Google Cloud