+1 I'm very glad to hear this news and looking forward to participate it.
---Original--- From: "Mingyu Chen"<morning...@163.com> Date: Sun, Jul 10, 2022 23:20 PM To: "dev"<dev@doris.apache.org>; Subject: Re:[Discuss] Apache Doris Bi-Weekly Community Sync And I would like to host the first meeting at 2022-07-13(Next Wednesday). The Call-For-Topics can be found here[1] and everyone is free to edit it. [1] https://docs.google.com/document/d/1JR-cSic9M5Hf6ehiB4ZwMjgaQoClSWS7y6dt62fNYCo/edit -- 此致！Best Regards 陈明雨 Mingyu Chen Email: morning...@apache.org At 2022-07-10 23:18:16, "Mingyu Chen" <morning...@163.com> wrote: >Hi all, >I'm going to launch a Bi-Weekly Sync Meeting for the Doris community. > >Motivation: > >1. Provide a platform for Doris developers to communicate. > >2. Align community development progress to facilitate developers to know community development trends. At the same time, ensure feature scheduling and release progress. > > > > >Meeting time and location: > >1. Location: Online with Tencent Conference > >2. Time: 20:00(GMT+8). every biweekly Wednesday (tentative) > > > > >Meeting process: > >1. Call for topics: > > The host will prepare google doc and release them in the dev@doris, WeChat group and other public channels two weeks before the meeting to solicit topics for the next meeting. > > Topics include but are not limited to: > > 1. Discussion on new feature requirements. > > 2. Suggestions for current functions, development progress, etc. > > 3. Version release progress. > > > > Not suggested topics: > > 1. Usage issues: The conference is mainly for developers and in principle does not deal with user usage issues. > > 2. Unthought functional requirements: For new feature requirement, the submitter needs to give at least the motivation, scenarios and general solution ideas of the feature. > > 3. Pure bug feedback: Bug feedback should be translated into suggestions for current functionality, or an appropriate solution. > > > > > The submitter of the topic needs to prepare the materials of the relevant issue and initiate the discussion of the relevant issue at the meeting. > > > > >2. Arrangement and freezing of topics > > The day before the meeting starts, the host closes the issue solicitation channel and organizes the issues. > > > > >3. Host the meeting > > The host presides over the meeting and discusses the topics in order. > > In principle no unregistered topics will be discussed. > > If the submitter does not attend the meeting, the host needs to deal with the issue or postpone it to the next meeting. > > The meeting time is about 1 hour. The host needs to control the meeting time and try not to discuss technical details. > > Record the minutes of the meeting, some unfinished technical details, etc., you can continue the discussion after the meeting according to the minutes of the meeting. > > > > >4. End of the meeting > > Before the end of the meeting, the host of the next meeting shall be confirmed on a voluntary basis. > > The host of this meeting needs to sort out the meeting minutes and release them in both Chinese and English on the dev@doris. > > The host of the next meeting starts to collect topics for the next meeting. > > > > >5. PMC > > PMC members should consult the meeting minutes from time to time, and organize requirements into development progress and publish them in RoadMap in due course. > > > >Please feel free to discuss. >======================================================= >我准备发起Doris社区的双周同步会议。 >会议主旨： >1. 为 Doris 开发者提供一个交流的平台。 >2. 对齐社区开发进度，方便开发者知晓社区开发动态。同时确保功能排期和发版进度。 > > >会议方式： >1. 地点：腾讯会议 >2. 时间：每双周周三晚8点（暂定） > > >会议流程： >1. 征集议题 > 由主持人准备好 google doc 并于会议开始前两周在dev邮件组、微信群等公开渠道放出，征集下次会议的议题。 > 议题包括但不限于： > 1. 新功能需求讨论 > 2. 当前功能的建议、开发进度等 > 3. 版本发布进度 > > 不建议议题： > 1. 使用问题：会议主要面向开发者，原则上不处理用户使用问题。 > 2. 未经思考的功能需求：对于新功能寻求，提交者至少需要给出功能的动机、场景和大致的解决思路。 > 3. 单纯的bug反馈：bug 反馈应转换为对当前功能的建议，或给出适当的解决方案。 > > > 议题的提交者需准备相关议题的资料，并在会议上发起相关议题的讨论。 > > >2. 议题整理和冻结 > 会议开始前一天，主持人关闭议题征集通道并整理议题。 > > >3. 主持会议 > 主持人主持会议，按照整理后的议题顺序依次进行讨论。 > 原则上不讨论任何未登记的议题。 > 如遇议题提交者未参会，则主持人需处理该议题，或延期至下次会议。 > 会议时间约1小时，主持人需要把控会议时间，尽量不讨论技术细节。 > 记录会议纪要，一些未讨论完的技术细节等，可以根据会议纪要在会议后继续讨论。 > > >4. 会议结束 > 会议结束前，通过自愿原则，确认下一次会议的主持人。 > 本次会议主持人需整理会议纪要，并在dev邮件组和github上以中英文的形式放出。 > 下次会议的主持人开始进行下次会议的议题征集工作。 > > >5. PMC > PMC 成员应不定期查阅会议纪要，并将需求整理为开发进度，并适时发布在 RoadMap 中。 > > > >-- > >此致！Best Regards >陈明雨 Mingyu Chen > >Email: >morning...@apache.org
