2019年KubeCon + CloudNativeCon提案征集(CFP)的新优化安排

2023-11-22 12:50

本文主要是介绍2019年KubeCon + CloudNativeCon提案征集(CFP)的新优化安排,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

2019年KubeCon + CloudNativeCon提案征集(CFP)的新优化安排

KubeCon + CloudNativeCon从2015年开始的500名与会者,扩展到成为有史以来规模最大,最成功的开源会议之一。随着这种增长带来了挑战,CNCF渴望随着时间的推移优化会议,最好地服务云原生社区。我们在西雅图举行的活动(2018年12月10日至13日),是我们规模最大的,提前几周售罄,共有8,000名与会者。

从一开始到整个增长,我们都非常感谢社区分享的反馈和意见。我们仔细审查事后调查,并仔细聆听建议和新想法。这种反馈循环至关重要,可以让我们进行迭代和改进。

当我们开放巴塞罗那(2019年5月20日至23日)提案征集(CFP)时,我们希望分享我们计划在2019年做出的一些改变,以及一些考虑过,但决定不在此时实施的改变。CNCF是Linux基金会(LF)的一部分,利用LF十多年来开展开源活动的经验,包括2018年的100多个,来自11,000多个组织,113个国家的30,000多名与会者。我们也从之前的活动中收到了很多反馈,其中大部分都是赞美的,有些提出了具体的改进建议。

以下是我们计划在2019年实施的一些变更:

  • CFP将接受更长的提交内容,以鼓励演示者在其提案中分享其他背景和技术信息。
  • 我们愿意为未获选提案的提交者提供额外的反馈。此反馈将属于某一类别,而不是个人化。
  • 我们改进了工具,将提交者在CFP的提交总量限制为两(2)个。具体地说,我们将作为联合演讲者作为半个(0.5)提交,单独的演讲作为一(1)个提交,并且将提交总量限制在两(2)个。所以,你最多只能以1)联合演讲者或小组成员的身份提交四(4)份提案,2)单独演讲者提交两(2)份提案,3)单独演讲者提交一(1)份提案,联合演讲者或小组成员提交两(2)份提案。注意:维护者‎专题不受此政策约束。
  • 在为CNCF托管项目、Kubernetes SIG和工作组,以及CNCF工作组提供的维护者‎专题中,我们提供机会将简介(Intro)和深入了解(Deep Dive)结合到更长的80分钟。(请注意,维护者专题演讲不计入每个演讲者的单个CFP演讲配额。)
  • 我们将在2019年推出两种新的小型活动。Kubernetes Days将是单日活动,针对拥有大量开发者的地区的单专题活动,这些开发者无法轻松前往我们在欧洲、中国和北美的盛会。Cloud Native Community Days将是社区成员开展的区域活动,将为演讲者、从业者和最终用户提供更多会面机会。
  • 我们鼓励任何想要尝试双盲提案提交流程(double-blind talk submission process)的合作伙伴峰会。

以下是我们不打算更改的一些核心要素:

  • KubeCon + CloudNativeCon是一个面向开发者和最终用户(广泛定义)的会议,旨在就开源、云原生技术进行沟通。
  • 会议联合主席组织的计划委员会,包括社区领导人和来自过去会议获得好评的演讲者,对提交进行评级。计划委员会由会议联合主席选出,他们也选择专题,并进行最终的提案选择。
  • 无论公司是该活动的赞助商还是CNCF的成员,都不会影响他们的开发者的提案是否获选。例外的是每个钻石赞助商(共6个)获得5分钟的赞助主题演讲。联合主席与所有主题演讲者(包括赞助商)合作,避免供应商宣传,以便演讲与社区观众产生共鸣。
  • 所有演讲都是关于使用和/或开发开源软件。尽管软件供应商雇用了许多演讲者,但会议内容主要集中在开源,而非供应商的产品。
  • 演讲可以讨论CNCF的19个毕业/孵化项目,或11个沙箱项目,或任何其他为云原生生态系统增加价值的开源技术。
  • 我们仍然致力于增加在传统上在技术方面代表性不足的人的声音。

我们选择社区领导者担任会议联合主席并代表云原生社区。巴塞罗那的联合主席是Google的Janet Kuo和Heptio的Bryan Liles。他们正在选择一个由大约80名专家组成的计划委员会,其中包括项目维护人员、活跃的社区成员以及过去活动中评价很高的演讲者。计划委员会成员登记他们所熟悉的主题领域,CNCF工作人员随机为每个成员分配相关提案的子集。然后,我们整理所有的评论,会议联合主席度过一个非常具有挑战性的一周,从评价最高的提案汇集一系列连贯的专题和主题演讲。我们为计划委员会提供的评分指南。演讲主题与专题之间没有一对一的映射。我们期待会议联合主席制定一个反映云原生社区当前趋势和兴趣的计划。

上述过程用于选择~180个在~10个房间内提供的CFP演讲。主题演讲由会议共同主席从高评级的CFP提交作品中选出,或者在极少数情况下,由联合主席邀请特定演讲者参加。

此外,KubeCon + CloudNativeCon还包括~90个维护者专题,分布在~5个房间。这是由CNCF托管项目的维护者生成的内容,通知使用者有关项目、添加新的采用者,以及将其中一些从用户转化为贡献者。维护者专题对CNCF的每个(29)托管项目、Kubernetes SIG和工作组、以及CNCF工作组开放。每个都可以进行一次35分钟的简介(Intro)会议和一次35分钟的深入了解(Deep Dive)会议。2019年的新优化,我们安排提供一个80分钟的会议。

KubeCon + CloudNativeCon的另一个快速发展的部分是活动前一天举行的合作峰会。这是云原生社区中的项目和公司与KubeCon + CloudNativeCon与会者互动的机会。在西雅图,有27个单独的活动!他们的范围从社区组织的活动,如Kubernetes贡献者峰会和EnvoyCon,到成员组织的峰会,到邻近社区的开源项目,如网络计划FD.io和Tungsten Fabric。这些活动的内容和定价由举办每个活动的组织决定。

审阅流程

CFP的提交是通过单盲(single-blind)过程选择。也就是说,审阅者可以看到谁在提出提案,但提交者不会看到谁审审阅了他们的提交。一些学术会议已经转向双盲(double-blind)提交,提交者从提交中删除所有识别信息,审阅者仅根据内容的质量来判断。缺点是它需要更详细的提交。

巴塞罗那提交的提案包括一个标题和最多900个英文字符的描述,如果获选为演讲,会在时间表中使用。还有一个对生态系统的好处额外部分,最多可以提供1,500个英文字符,以便为提交说明情况(这与2018年允许的300个英文字符有很大提升)。要支持双盲(double-blind)选择,我们需要提交9,000个英文字符(约3页)或更多,这是典型的学术式会议,以鼓励有效的审阅。我们相信这会打击云原生技术的许多从业者和最终用户提交提案,更多的将来自学者和那些有时间和倾向于提交更长的人。

这有利有弊,但在由LF举办的开源会议中,这将是一个非常重大的变化。我们考虑使用一个主题区域(例如服务网格)测试双盲(double-blind)过程,但认为对于未知的改进来说,这将是一个太大的变化。作为代替,我们鼓励任何想要尝试双盲(double-blind)提案提交流程的合作伙伴峰会。LF Events工作人员很乐意与他们合作,为巴塞罗那或未来的活动组织这样的流程,如果结果顺利,我们可能会在未来的KubeCon + CloudNativeCon上扩展到一个或多个专题。

西雅图的接受率仅为13%,我们理解如果非常好的提案不能获选,会产生很多失望和挫败感。在2019年,我们将向未获选题案的提交者提供额外的反馈。这些反馈将属于一系列类别,例如“不在提交的分数的上半部分”和“高评级但已经接受了类似的提案”。

如何让你的提案获选

无论公司是CNCF的成员还是最终用户支持者,或者赞助活动,都不会影响他们的开发者的提案是否会被选中。例外的是6个钻石赞助商,各自获得5分钟的赞助主题演讲。然而,作为社区领导者确实会有影响,因为计划委员会成员通常会更高度地评价来自开源项目的创建者或领导者的提案。

避免为你的产品或服务提交销售或营销宣传的常见问题,无论它有多么引人注目。专注于你在开源项目中的工作,无论是CNCF的29个托管项目,还是为云原生生态系统增值的新项目。

KubeCon + CloudNativeCon基本上是一个社区会议,专注于云原生开源项目的开发和部署。因此,请相应地选择你的演讲者和目标受众。我们的参与者包括顶级专家和初学者,因此我们明确询问你的演讲所针对的技术难度(初级、中级、高级或任何),并提供范围。

我们经常会收到很多涉及几乎相同概念的提交,所以即使有几个很好的提交,联合主席也可能只选择一个。考虑选择一个更独特的相关的主题,但不会有多人提交的。

我们的社区对采用云原生技术的最终用户特别感兴趣。最终用户是在内部使用云原生技术,但不在外部销售任何云原生服务的公司。最终用户通常在Cloud Native Landscape上的没有商业产品,尽管可能创建了一个开源项目来共享他们的内部技术。有关更多信息,请参阅CNCF最终用户社区中的各类公司。如果你不在最终用户公司工作,请考虑与采用你的技术的最终用户联合演讲。

鉴于YouTube和腾讯视频上可以找到演讲视频,而且议程上的空间非常有限,请避免在之前的KubeCon + CloudNativeCon或任何其他活动中提交过的提案内容。如果你的提交与之前的演讲类似,请提供有关此版本如何与众不同。确保你的演讲是及时、相关和新颖。

我们已经改进了我们的工具,只接受每个演讲者单个CFP提案,并且限制提交者提交两(2)个提交。具体来说,我们计算作为联合演讲者作为半个(0.5)提交,并限制提交总量在两(2)个。所以,你最多可以作为联合演讲者提交四(4)个演讲;单独演讲者提交两(2)份提案;或单独演讲者提交一(1)份和作为联合演讲者提交两(2)份提案。

查看哥本哈根和西雅图获择的提案,并注意大多数都有清晰、引人注目的标题和说明。CFP表格包含一个部分,用于方便审阅者评估你提交的资源。如果你之前发表过演讲视频,请附上指向该演讲的链接。博客帖子、代码仓库和其他贡献也有助于建立你的凭据,特别如果这是你的第一次公开演讲(而我们鼓励首次演讲者提交申请)。

最后,我们明确感兴趣的是增加传统上在技术方面代表性不足的人的声音。所有提交的内容都会根据优点进行审阅,但我们仍然致力于举办多元化和包容性的会议,我们将在最终确定演讲者名单和总体时间表时继续积极考虑这一点。例如,我们不接受所有演讲者均为男性的小组提案。我们还提供多元化奖学金以抵消出差费用。

其他云原生会议

2019年,我们计划继续在巴塞罗那(2019年5月20日至23日),上海(2019年6月24日至26日)和圣地亚哥(2019年11月18日至21日)举办三场KubeCon + CloudNativeCon活动。此外,我们支持38个国家的160个Meetup小组,他们已经举办了1,600多场活动,拥有超过80,000名会员。

我们也帮助CNCF托管的项目举办他们自己的专有活动,无论是同场与KubeCon + CloudNativeCon(包括EnvoyCon和Observability Practitioner's Summit),还是独立举办(包括PromCon)。

我们将在2019年推出两种新的小型活动。Kubernetes Days将举办为期一天的单轨活动,针对拥有大量开发者的地区,他们无法轻松前往我们在欧洲、中国和北美的盛会。第一次将于2019年3月23日在印度班加罗尔举行。

此外,我们计划支持一系列社区组织的活动,称为Cloud Native Community Days。这些将是社区成员在这些领域开展的区域活动,并为发言人、从业者和最终用户聚集在一起提供额外的机会。我们将在2019年初提供有关这些计划的更多详细信息。

巴塞罗那和上海的提交

巴塞罗那的CFP现已开放,截止日期为太平洋标准时间2019年1月18日。KubeCon + CloudNativeCon上海(2019年6月24日至26日)提案征集的截止日期为太平洋标准时间2019年2月15日。提交和选择流程是分开的。如果你向两者提交相同的谈话并且一方接受,则会被另一方拒绝,因此我们建议你向每个会议提交不同的内容。

跟进

如果你对我们如何选择演讲的过程有任何疑问或改进方法,或对CNCF活动有其他想法,请联系Dee Kumar <dkumar@linuxfoundation.org>,或在https://calendly.com/deekumar预约我们讨论。


2019年KubeCon + CloudNativeCon中国论坛提案征集(CFP)现已开放

KubeCon + CloudNativeCon 论坛让用户、开发人员、从业人员汇聚一堂,面对面进行交流合作。与会人员有 Kubernetes、Prometheus 及其他云原生计算基金会 (CNCF) 主办项目的领导,和我们一同探讨云原生生态系统发展方向。

2019年中国开源峰会提案征集(CFP)现已开放

在中国开源峰会上,与会者将共同合作及共享信息,了解最新和最有趣的开源技术,包括 Linux、容器、云技术、网络、微服务等;并获得如何在开源社区中导向和引领的信息。

大会日期:

  • 提案征集截止日期:太平洋标准时间 2 月 15 日,星期五,晚上 11:59
  • 提案征集通知日期:2019 年 4 月 1 日
  • 会议日程通告日期:2019 年 4 月 3 日
  • 幻灯片提交截止日期:6 月 17 日,星期一
  • 会议活动举办日期:2019 年 6 月 24 至 26 日

2019年KubeCon + CloudNativeCon + Open Source Summit China赞助方案出炉啦

这篇关于2019年KubeCon + CloudNativeCon提案征集(CFP)的新优化安排的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/410276

相关文章

Vue3 的 shallowRef 和 shallowReactive:优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉,那么对 shallowRef 和 shallowReactive 是否了解呢? 在编程和数据结构中,“shallow”(浅层)通常指对数据结构的最外层进行操作,而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素,而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层(Shallow) 定义

HDFS—存储优化(纠删码)

纠删码原理 HDFS 默认情况下,一个文件有3个副本,这样提高了数据的可靠性,但也带来了2倍的冗余开销。 Hadoop3.x 引入了纠删码,采用计算的方式,可以节省约50%左右的存储空间。 此种方式节约了空间,但是会增加 cpu 的计算。 纠删码策略是给具体一个路径设置。所有往此路径下存储的文件,都会执行此策略。 默认只开启对 RS-6-3-1024k

使用opencv优化图片(画面变清晰)

文章目录 需求影响照片清晰度的因素 实现降噪测试代码 锐化空间锐化Unsharp Masking频率域锐化对比测试 对比度增强常用算法对比测试 需求 对图像进行优化,使其看起来更清晰,同时保持尺寸不变,通常涉及到图像处理技术如锐化、降噪、对比度增强等 影响照片清晰度的因素 影响照片清晰度的因素有很多,主要可以从以下几个方面来分析 1. 拍摄设备 相机传感器:相机传

MySQL高性能优化规范

前言:      笔者最近上班途中突然想丰富下自己的数据库优化技能。于是在查阅了多篇文章后,总结出了这篇! 数据库命令规范 所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库对象名称禁止使用mysql保留关键字(如果表名中包含关键字查询时,需要将其用单引号括起来) 数据库对象的命名要能做到见名识意,并且最后不要超过32个字符 临时库表必须以tmp_为前缀并以日期为后缀,备份

BUUCTF靶场[web][极客大挑战 2019]Http、[HCTF 2018]admin

目录   [web][极客大挑战 2019]Http 考点:Referer协议、UA协议、X-Forwarded-For协议 [web][HCTF 2018]admin 考点:弱密码字典爆破 四种方法:   [web][极客大挑战 2019]Http 考点:Referer协议、UA协议、X-Forwarded-For协议 访问环境 老规矩,我们先查看源代码

SWAP作物生长模型安装教程、数据制备、敏感性分析、气候变化影响、R模型敏感性分析与贝叶斯优化、Fortran源代码分析、气候数据降尺度与变化影响分析

查看原文>>>全流程SWAP农业模型数据制备、敏感性分析及气候变化影响实践技术应用 SWAP模型是由荷兰瓦赫宁根大学开发的先进农作物模型,它综合考虑了土壤-水分-大气以及植被间的相互作用;是一种描述作物生长过程的一种机理性作物生长模型。它不但运用Richard方程,使其能够精确的模拟土壤中水分的运动,而且耦合了WOFOST作物模型使作物的生长描述更为科学。 本文让更多的科研人员和农业工作者

从状态管理到性能优化:全面解析 Android Compose

文章目录 引言一、Android Compose基本概念1.1 什么是Android Compose?1.2 Compose的优势1.3 如何在项目中使用Compose 二、Compose中的状态管理2.1 状态管理的重要性2.2 Compose中的状态和数据流2.3 使用State和MutableState处理状态2.4 通过ViewModel进行状态管理 三、Compose中的列表和滚动

构建高性能WEB之HTTP首部优化

0x00 前言 在讨论浏览器优化之前,首先我们先分析下从客户端发起一个HTTP请求到用户接收到响应之间,都发生了什么?知己知彼,才能百战不殆。这也是作为一个WEB开发者,为什么一定要深入学习TCP/IP等网络知识。 0x01 到底发生什么了? 当用户发起一个HTTP请求时,首先客户端将与服务端之间建立TCP连接,成功建立连接后,服务端将对请求进行处理,并对客户端做出响应,响应内容一般包括响应

DAY16:什么是慢查询,导致的原因,优化方法 | undo log、redo log、binlog的用处 | MySQL有哪些锁

目录 什么是慢查询,导致的原因,优化方法 undo log、redo log、binlog的用处  MySQL有哪些锁   什么是慢查询,导致的原因,优化方法 数据库查询的执行时间超过指定的超时时间时,就被称为慢查询。 导致的原因: 查询语句比较复杂:查询涉及多个表,包含复杂的连接和子查询,可能导致执行时间较长。查询数据量大:当查询的数据量庞大时,即使查询本身并不复杂,也可能导致

MySQL 数据优化

MySQL 数据优化的指南 MySQL 数据库优化是一个复杂且重要的过程,它直接影响到系统的性能、可靠性和可扩展性。在处理大量数据或高并发请求时,数据库的优化尤为关键。通过合理的数据库设计、索引使用、查询优化和硬件调优,可以大幅提高 MySQL 的运行效率。本文将从几个主要方面详细介绍 MySQL 的优化技巧,帮助你在实际应用中提升数据库性能。 一、数据库设计优化 1. 数据库的规范化与反规