第一部分和第二部分：在Make Team Blog上交流：讨论、建议、公告
WordPress社区主要通过 松弛（Slack） 松弛（Slack） Slack是一个协作群聊平台 https://slack.com/ WordPress社区在 https://make.wordpress.org/chat/ . 和Make Team博客，通常称为“P2s”。 让团队博客特别能看到各种更新、讨论、建议和公告。 这些是如何形成的，人们如何提供反馈？ 在做出决策时，如何考虑反馈？ 本次讨论将围绕Make Team博客上的对话重点讨论最佳实践。
讨论目标
原始票据
制作团队博客的最佳实践( 第2页 第2页 P2或O2是人们用来指代Make WordPress博客的术语。 可以在以下位置找到 https://make.wordpress.org/ . )第一部分
为什么Make Blog评论不使用 块 块 块是一个抽象术语，用于描述使用WordPress编辑器组合在一起形成网页内容或布局的标记单元。 这个想法结合了过去可能通过短代码、自定义HTML实现的概念，并将发现嵌入到单一一致的API和用户体验中。 编辑（回答：最终会发生的，但如果有任何问题，请随时加入任何Slack频道进行询问） 提高（新）贡献者的盲点意识 建议–没有明确的流程。 通常，提案的提出方式使其看起来像是在进行中。 没有讨论获得提案的过程，没有循序渐进的路径，并且当帖子发送到 元 元 元是指组内部工作的术语。 对我们来说，这是一个在WordCamp Central和Make WordPress等内部WordPres网站上工作的团队。 第2页。 感觉是，有了一份发布的建议书，项目就有了一个隐含的绝对方向。 需要进行一些改进，以便为其他团队着想。 社区成员应该有考虑在某些决策和建议中应该包括哪些团队的心态 新的贡献者不知道团队博客的存在。 有一种感觉，你必须精通英语才能参与讨论。 可能的解决方案： 翻译按钮会很有帮助，这样其他人可以参与进来 懒散更难理解（因为信息总是流动的，事情总是更新的），而不是基于项目或 github github GitHub是一个提供git存储库在线实现的网站，其他开发人员可以轻松共享、复制和修改这些存储库。 公共存储库可以免费托管，私有存储库需要付费订阅。 GitHub引入了“拉请求”的概念，在将贡献者在分支中所做的代码更改合并为存储库所有者之前，可以对其进行审查和讨论。 https://github.com/ 问题 如果你在一周内只贡献了几次小增量的内容，那么很难找到Slack、GitHub和Makeconnect之间的讨论如何才能看到全貌。 没有人真正关注事物的整体。 （较新的团队代表）-什么时候保持对话，什么时候在博客上发帖。 我是否链接到松弛部分？ 我是否链接到github？ 缺乏指南或一般做法 缺乏可视性和协调其他团队工作的能力。 跨团队决策——项目范围的治理。 提案在不同的时间提出，没有顺序，并要求对提案进行反馈，但所述反馈的时间线不同（没有标准化）。在评论中，没有标准的前进方式，只需寻找批评即可。 当写建议书（功能→）以固定顶部注释（有时使用，有时不使用）时，您可以固定注释“这是所做的决定” 确保我们分配适当的时间发表评论，尤其是对于那些没有持续贡献/兼职时间更多的人 对于谁可以写评论，以及其他开源项目如何管理这一点，是否有标准？ RSS更新页面（未链接到任何地方）-任何未附加到任何团队的github回购-目前没有向任何团队报告RSS 谁是我们的受众？哪些内容属于/更新（make/latest这将为您提供RSS更新）和make/projects 谁可以访问，我们如何确保人们可以访问？ 我们能确保这种情况发生吗？ 处理工作组与团队的关系，需要一个临时网站来进行调查，（目前还没有make/blog），需要调查工具来帮助决策。 当决策仅仅是基于Slack而不是从更广泛的角度来考虑make时，这是一种耻辱。 需要提供如何编写会议记录、提案等的示例模板。可持续发展团队正在寻找这些工具。 很好，有一些关于如何运行东西的框架——集中式工具。 除了/projects博客之外，工作组没有其他地方可以发表想法，所以人们很难找到。 开始投稿太令人困惑了——谁在投稿，谁有权投稿，仍然困惑不解，人们会告诉每个人不同的事情。 反馈得到了，但事后没有采取行动，或者看起来是这样。 这可能会让社区感到被剥夺了权力——“为什么要费心评论，没有人听”，而另一个团队却在说相反的话——我们需要反馈，一旦有反馈，就需要在提案帖子的评论中综合反馈，并对所采取的行动进行注释。 基本上功能失调——有秘密会议，而不是异步会议
良好体验/积极体验
WP中的沟通涉及讨论历史。 Make Team Blogs提供了7年前的讨论，并允许人们查看当时的问题； 将其用作优秀的存档。 一些具有跨团队意识的个人能够花时间将团队聚集在一起，但这也是一个薄弱环节，因为一个人承受了太多的重量 在贡献者指导团队中，许多团队共同支持新贡献者并创建材料 学习团队的构建是天文数字，未来可以继续为更广泛的受众翻译 如果清楚团队喜欢如何联系（Slack、GitHub等），则易于与其他团队合作 本地站点现在可以拥有自己的make/blog，并与元团队合作完成这项工作。 当地社区可以利用这一点进行登录，新的贡献者可以学习如何将wp.org或make/blog中的内容翻译出来。 坚持对团队和个人来说非常重要； 这就是事情发生的原因； 这就是魔法。
团队博客最佳实践（P2）第2部分：
保持
开放性 广泛的受众参与 月度总结（人性化的总结） 跨团队沟通/协作的概念
停止
只有团队代表发帖 编写已经决定的提案 “缺乏回应”的假设是同意（缺乏参与）。 在定期会议中宣布剩余的响应时间。 如果没有共同的反对意见，那就在那之后继续前进，但总有迭代的空间 与确认的项目帖子相比，提案的内容不明确 有很多噪音
需要思考的行动
作为一个社区接受实验 其他语言的内容（MLAI服务） 自动翻译 非开发人员更容易导航 允许搜索扫描所有make/blog，同时显示GitHub门票 组织总结主题（号召行动） 跨团队协作提供更好的指导 所有团队的通用资产池 提案投票–异步和实时 显示项目中提交的所有提案的摘录/或提供摘要或概述（或在一个地方） 分享反馈（以及如何提供反馈） 有 直接还原铁 直接还原铁 直接负责人-对特定项目或功能承担所有权或责任的人。 更好 用户体验 用户体验 UX是用户体验的缩写——用户使用UI的方式。 想想“他们在做什么”，少想想他们是怎么做的。 / 用户界面 用户界面 UI是用户界面的缩写，即用户与之交互的页面布局。 想想“他们是怎么做到的”，少想想他们在做什么。 电子邮件摘要–成员订阅的团队 为新老贡献者澄清大型项目决策指南 更新的单一注册
以下讨论^^
人们对投票有什么看法？ 确保社区成员参与决策过程与确保我们向前迈进 记住读者是谁。 有时是为了团队，有时是为了更广泛的社区。 更精致的发布功能。 为什么人们开始觉得分享自己的想法不安全？ 或者他们的想法不重要？ 人们想知道这是否是他们的角色？ 我们如何知道何时发布以及发布什么？ 是什么让人发帖感到紧张？ 我甚至可以发帖吗？ 在发布帖子之前，是否应该以Slack开始对话？ Slack只会更快地得到回应，因此与make/blog相比，走这条路更容易。 为什么我们要使用其他工具？ 害怕堆积 如果一个决定在github或Slack上失败了，可能是因为它需要发布在Make Blog上，有人可能无法访问 让你的队友参与进来是一种发布帖子的方式，可以减少恐惧，让你觉得自己的想法背后有支持。 个人资料可能不一致，因此看起来您没有信用，因为它位于不同的位置 我们可以基于帖子上的想法（在那里做出决策），为未来的决策留下足迹/遗产。 例如：培训团队–WP认证（对话发生在大约3年前-没有离开，再次召开了研讨会，仍然没有去任何地方–但它是有记录的，我们能够继续。因此，它不是一个浪费的帖子。我们能鼓励那些发帖子的人吗？没有帖子就是一个无用的帖子？在那里创造更多价值 学习-我们可以提供支持：如何编写一份写得很好的提案 提示：链接到你所有相关的帖子，这样人们就可以看到已经讨论过的内容（Slack、Twitter等） 提供关于“如何启动工作组和如何提供良好反馈”的指导 虽然提案开始了，但最终以失败告终，但没有就失败的原因进行沟通（没有沟通或跟进），因此没有结束 总结思路：也许人工智能可以帮助发布此摘要。 设计——这是本周的主题，这个决定已经做出，等等。考虑到大多数贡献者没有资金，也没有志愿投入时间，需要考虑一些事情。 为什么要利用这段时间发布摘要而不是项目？ 赞助商与个人——赞助商可以协助“粘合工作”——不是真正做“工作”，而是确保某个地方有人在做工作，并让社区了解某些项目实际发生的情况。 在查看可以利用的AI工具时应该谨慎……许多工具不是 开源 开放源代码 开放源代码是指原始源代码可以免费获得，并且可以重新发布和修改的软件。 开源**必须**通过许可模式交付，请参阅GPL。 ，这与项目的精神气质背道而驰。 找到平衡点。
PHP程序 PHP程序 PHP（PHP:Hypertext Preprocessor的递归缩写）是一种广泛使用的开源通用脚本语言，特别适合web开发，可以嵌入到HTML中。 http://php.net/manual/en/intro-whatis.php . –正式征求意见 结构有助于完成任务 月底对项目进行投票（提案在当月提交），然后进行修改 我们错过了有赞成/反对票的建设性辩论 我们需要一个空间（创建一个空间）来在最后期限内进行这场“辩论” 并非总是“简单多数” 有附则（如2/3） 可以根据项目进行更改（仅限于贡献者等） 你如何克服WP是一种共识而非多数