Linux Foundation 项目

本页面包含有关 Google 文档季可接受的技术写作项目的详细信息。

项目摘要

开源组织:
Linux 基金会
技术文档工程师:
jaskiratsingh2000
项目名称:
CHAOSS:创建 CHAOSS 社区手册
项目时长:
标准时长(3 个月)

Project description

项目摘要:

目前,CHAOSS 社区的工作组已经制定了自己的工作方式,并在不同的程度上记录了他们不同的流程。 工作组包括通用指标工作组、多元化和包容性工作组、发展、风险和价值工作组,这些工作组建立了自己的参与和工作方式,并调整了不同的沟通和工作文化。根据指标,这些工作组的关注领域和背景不同,对于适当的指标,这些工作组主导了相应工作组类别下的各种研究和开发,并且知道在各自类别下主导各种研究和开发的正确途径,但对于新人和现有贡献者的参与流程可能不知道如何参与或采取相应工作的正确途径。

因此,CHAOSS 社区中的事还没有标准化。因此,为了了解社区工作文化的正确流程和基本基础,社区手册的目标是在整个 CHAOSS 项目中集中汇总关键信息并对部分信息进行标准化。关键信息和标准化部分主要侧重于 CHAOSS 采用的流程,以便 CHAOSS 就社区工作方式达成一致,新人如何参与并遵循社区的基本情况,以及新人或现有成员在利用 CHAOSS 社区领导力时必须遵守哪些流程和路径。

该手册应作为社区成员和新成员的指导手册,指导他们完成 CHAOSS 项目。该项目涉及一个创意组件(用于收集和整理手册内容),以及一个用于定义如何呈现手册内容的技术组件。

您需要满足什么要求?

《社区手册》是一份文档,定义了社区的关键政策和程序,并概述了社区的使命、价值观和工作方式。

本手册清晰地介绍新加入社区成员,并介绍他们的工作。 目前,CHAOSS 社区手册位于 GitHub 代码库上,需要改进和重构,为新社区成员和现有社区用户提供更多相关信息。因此,本 CHAOSS 社区范围内的手册将通过以下方式为新成员和现有社区成员提供帮助:

  • 规范并组织 CHAOSS 社区的政策,并将其放在一个地方
  • 传达社区的简介、使命、愿景和领导力
  • 了解 CHAOSS 社区做法
  • 贡献准则
  • 定义项目工作流
  • 介绍 CHAOSS 社区文化
  • 一般常见问题解答
  • 指导

项目说明:

《社区手册》分为多个“版块”,其中包含针对特定主题的适当且详细的信息。这些部分可通过以下方式划分:

  • 简介
  • CHAOSS 社区的方式
  • 领导之路
  • 术语
  • 贡献准则
    • 开发者
    • Designer(设计师)
    • Writer
    • 营销者
  • 指标
  • CHAOSScon
  • CHAOSScast
  • 会议视频
  • 常规常见问题解答
  • 指导
    • Google 编程之夏
    • 主动联系
    • Google 文档季

详细的项目交付项

1.) 简介:

此部分是 CHAOSS 社区手册的第一页,其中会介绍该手册的详情、概述和用法。以下内容如下:

A.) 其中包含欢迎辞,其中包含对 CHAOSS 社区的简要说明,这有助于说服读者通读该手册。我还将上传从 https://chaoss.community/chaoss-photo-album/ 获取的图片拼贴,其中重点介绍了该社区的各种运动。 B.) 该页面还将包含所有部分的详细信息,其中一行说明解释每个部分,并提供正确的链接。 C.) 手册用法:这里已经存在手册用法 (shorturl.at/cqQU6),但我将对现有的手册用法进行改进和重构,以更好地进行降价,其中包括手册流(我还会说明当某人想要添加、删除或讨论与手册相关的内容时,是如何发生的)。对于任何与手册相关的事项,该团队可能会跟进沟通过程。)手册指南(包括其在社区和范围内的使用)、对手册的贡献(包括应如何使用代码库进行更改、制定 PR、更改手册和风格指南时要遵循的模板)以及分享有关手册的反馈。在“分享反馈”部分,我会添加一个模板以及各种不同的方式,以便用户后续提供或使用 GitLab 问题接收反馈。

2.) CHAOSS 社区的方式:

CHAOSS Community 方式对人们理解社区做法和准则非常重要。Workflows 将能够更加强调社区活动,并以最佳方式概述社区实践。此部分包括以下内容:

A.) 一般价值:概述如何在 CHAOSS 社区中处理可持续性、开放性和透明度。我会说明这些价值,说明新用户或现有用户在与社区合作时应如何理解和考虑这些价值。 B.) 社区准则:这包括人们实际应如何参与 CHAOSS 社区并遵循一些基本条款。这也能解释社区内部所遵循的工作文化。(正确做法和错误做法)。其中将包括核心贡献者/维护者核对清单,并告知其他人他们应该如何与维护者合作,以及他们的核对清单是什么。 C.) 工作组:此页面( https://chaoss.community/participate/ ) 包含工作组的相关信息,例如工作组说明、代码库链接和会议信息,但在手册中,我会说明如何参与不同的工作组,了解评估指标的流程、了解各工作组的工作文化,以及如何成为不同工作组的核心贡献者。

3.) 领导之路:

不过,在开源项目中获得领导对于社区自身在商业领域取得成功至关重要。考虑到这一点,我将介绍以下内容:

A.) 技术领导层:其中包括 Repo 维护者、文档编写者和网站维护者的流程和职责 B.)治理领导:这将包括董事会成员和决策者 C.)运营领导层:此课程包含面向社区管理者的学习路线

4.) 术语:

术语有助于描述 CHAOSS 社区中经常使用的术语和相关资产。此外,我还会添加“大写”“缩写”和“应避免使用的字词”等术语使用准则,并说明原因。 将包含的条款包括:CHAOSS 项目、开源社区健康、代码审核、工作组、开源软件指标、通用指标、多元化和包容性指标、演变工作组、风险工作组、价值工作组、指标发布、关注领域。

5.) 贡献准则:

这是所有开源社区的主要背景,因为大多数开源社区都依赖于贡献或志愿者的工作,因此这有助于加入社区的任何新用户/用户了解他们必须遵守的基本必要性和准则。因此,其中包括以下详细信息:

A.) 了解社区的路线图:本主题将简要介绍 CHAOSS 社区的路线图,这可帮助用户了解应该以哪种方式或流程来确定 CHAOSS 项目中各种工作的优先顺序。 B.) 说明做出任何实操贡献(例如开发、文档、设计、测试等)所需的必要内容 C.)简要介绍 GitLab 的工作原理 D.)审核者/维护者指南

本部分还将包含每个贡献类别的“角色和责任”,如下:

a.) 设计:这一部分包括“CHAOSS 设计工作流程”和“设计准则”,其中包括设计原则、流程和所使用的工具,贡献者在为设计领域做出贡献时必须遵守这些准则。 b.)DEVELOPMENT(开发):包含针对代码库做贡献的指南。其中包括技术要求、项目结构、项目设置(Augur、Cregit、GremoireLab) c.)文档:其中包括文档资源,包括工具和风格指南。 d.)联络:这将包括贡献者如何支持 CHAOSS 社区发展 - 撰写博客、使用社交标识名、组织聚会和活动

6.) 指标

目前,CHAOSS 社区网站包含 Metric Releases( https://chaoss.community/metrics/ ) 的信息,对于人们来说,更重要的是了解如何按照流程在该网站上显示其指标网站。因此,本部分将提供一些信息,帮助用户了解发布指标的过程和工作。

7.)CHAOSScon:

GitHub( https://github.com/chaoss/governance/blob/master/community-handbook/chaosscon.md ) 和网站( https://chaoss.community/CHAOSScon-2020-NA/ ) 上已经有关于 CHAOSScon 的信息,但在手册中添加说明 CHAOSScon 流程和管理方式的详细信息和信息更合适。手册中将包含以下信息:

A.) 有关组委会的详细信息:其中介绍了参加 CHAOSScon B 组委会的流程。管理提案请求流程:其中包括管理作者注册、提交提案和文档、审核和批准流程。 C.) CHAOSScon 计划的管理和发布 D.)如何管理广告和营销资料 E.)如何处理包天提案和资金(包括资源包)

8.)CHAOSScast:

CHAOSScast 信息位于 https://github.com/chaoss/governance/blob/master/community-handbook/chaosscast.md 中。这些信息将包含在手册中,其中包含一些额外的详细信息,例如参与情况、组织委员会、广告和营销材料。

9.)会议视频:

其中包含过去在 YouTube 上提供的所有会议视频以及相关说明,例如参加者、日程等。

10.)一般常见问题解答:

其中将包含社区内经常被问及的常见问题,帮助新手和现有社区成员回答其中一些问题。

11.)Google 编程之夏:

此部分将包含 Google 编程之夏、资格标准以及人们如何在 Google 编程之夏参与 CHAOSS 社区的相关信息。此部分还包含提案模板,人们可以使用此模板来起草他们的提案、角色和职责。 此外,本演示文稿中也会包含相关信息,帮助现有社区成员学习成为组织管理员和导师的流程。

  1. 主动联系:

本部分将介绍“主动联系”和“资格条件”的相关信息,以及人们如何才能参与 Outreachy 社区的 CHAOSS 社区。其中将包含角色和职责,包括成为组织管理员和导师的过程。

  1. Google 文档季:

本部分将介绍 GSoD、资格标准,以及人们该如何参与 GSoD 中的 CHAOSS 社区。其中将说明相关角色和职责,包括成为组织管理员和导师的过程。

项目预期结果:

手册在任何社区中都发挥着重要作用。同样,本 CHAOSS 社区的手册可以为 CHAOSS 社区提供更有条理、更加详细的文档。无论是任何加入社区的新人,还是社区内的现有成员,都能轻松了解 CHAOSS 社区的基础知识和工作方式。 此外,该手册还将为 CHAOSS 社区中的不同工作文化提供不同的流程和途径。

技术详情:

我提议使用 Gitbook 平台维护该手册,因为它是一个方便用户使用的协作项目,可帮助团队更加高效地工作。 GitBook Platform 的部分功能:

  • 所见即所得:强大而美观的文本编辑器
  • Markdown:对 Markdown 快捷方式提供强大且高效的支持
  • 富媒体嵌入:嵌入外部网络内容,如视频、代码段、文章、音乐等
  • 面向作者的信息中心:为作者提供智能信息中心,支持可视化编辑
  • 草稿:草拟新更改并异步协作
  • 支持意见:讨论和查看更改草稿
  • 曲目写入记录:记录全部内容。查看并还原更改
  • 数据分析:它还支持跟踪流量、评分和内容质量的数据分析
  • GitHub Sync:保持工作流并与 GitHub 保持同步
  • 自定义 品牌 :自定义网域、自定义徽标、字体、颜色、主题、标题等

这里是几张图片,可让您大致了解该平台

  • shorturl.at/GNQR4
  • shorturl.at/gATZ8
  • shorturl.at/qrE57
  • shorturl.at/rFRX6
  • shorturl.at/eyLW1
  • shorturl.at/rwHS8

-- 手册将在哪里托管?

该手册将托管在 GitBook 上,GitHub 为自定义网域、常见错误和 SEO 提供了适当的机制。

自定义网域: 如果 CHAOSS 社区希望将其托管在自定义网域上,则其显示方式如下:docs.chaoss.community。组织只需要构建他们希望拥有的任何子网域。 要设置组织域名,请在 Gitbook 平台上前往相应组织的设置。 图片示例:shorturl.at/GNQR4

GitBook 空间通过我们自己的 CDN 提供,默认启用 HTTPS。证书由 LetsEncrypt 颁发

支持的网域:

  • 子网域:www.example.com
  • 自定义网域:docs.example.com

- 如何将 Gitbook 与 GitHub 同步,以便在这两个平台上有效地执行修改?

与 GitHub 的集成非常易于使用:如果有人更改了 GitBook 上的一些内容,他们的修改内容会推送到 GitHub 代码库。相反,推送到 GitHub 代码库的提交内容会导入到 GitBook 中。

设置 GitHub 集成:

  • 在您的 GitBook 平台内部,依次点击“Integration”(集成)标签页 > GitHub
  • 授权 GitBook 访问与贵组织关联的 GitHub 帐号
  • 转到贵组织的 GitHub 并为“HandBook”创建一个代码库,例如 chaoss-handbook
  • 现在,选择要在 GitBook 平台内的授权选项中关联的名为 chaoss-handbook 的代码库。

完成这些步骤后,GitBook 会向 chaoss-handbook 代码库添加一个 webhook,以便在代码库每次发生更改时提取内容。更改 GitBook 时,系统会推送新评论。

就这么简单!任何人都可以通过 GitBook 或 GitHub 代码库继续编辑。

-- 如何在 GitBook 平台上修改页面?

任何想要在 GitBook 平台中修改任何内容的人都必须通过邀请或加入链接加入 GitBook 平台。GitBook 支持可视化编辑,用户可以直接在页面内撰写内容。

草稿是用户内容的可编辑版本,仅供作者访问,且在您开始撰写内容(编辑器上的首字母、新页面创建、图片上传等)后自动创建。

对草稿所做的更改是合适的,这让用户可以与其他成员同时对同一文档进行协作,而不会产生任何冲突!这就是我们所说的异步修改和冲突解决。

草稿的第一个版本并非总能立即发布。如果您想稍后继续处理,或者您的内容尚未准备好“合并”,请使用“保存”。

修改完毕后,你可以“合并”草稿。随后,您的团队成员将可以查看您撰写的内容或所做的更改,并且/或者公开发布。

图片示例:shorturl.at/gATZ8 和 shorturl.at/qrE57

-- 内容结构:

目录:每个空间可以包含您撰写文档所需的任意数量的页面。所有这些网页都显示在屏幕左侧的“目录”中。通过目录,您可以管理自己的页面:创建新页面、页面组、添加外部链接、添加变体、导入外部文档(如 Markdown(.md 或 .markdown)、HTML (.html)、Microsoft Word (.docx) 等网站或文件。

初始页:初始页是文档的首页或根目录,基本上是文档中所有页面的母版。由于该页面是文档和空间的主要入口,因此无法移动、删除、包含子页面或位于某个组之下。

页面:页面有一个标题,在编辑器顶部还可以选择显示说明。然后,您可以编写任意种类的内容并添加到其中。通过将页面拖放到另一页面下方,即可嵌套页面。网页的子项将处于隐藏状态,但可以收起。

外部链接:这些条目是外部链接,编辑器中没有任何内容。其主要功能是链接到外部网站。

变体:您可以通过制作变体来创建文档的替代内容。这对于记录一个 API、库或翻译的多个版本非常有用。

图片示例:shorturl.at/eyLW1 和 shorturl.at/rFRX6

-- 如何向客户展示该手册?

《Chaoss 社区手册》可通过子网域(可以是 https://docs.chaoss.community)访问,在用户端通过以下方式查看:

  • Mattermost 手册 - https://handbook.mattermost.com/
  • Linux Foundation 社区桥文档 - https://docs.linuxfoundation.org/docs/ 等等

项目时间安排:

1.) 社区凝聚阶段(8 月 17 日至 9 月 13 日)

A.) 第 1-4 周:

  • 与导师讨论项目
  • 研究并收集项目各个部分所需的信息,向社区提出澄清性问题
  • 向社区明确说明该手册使用的平台(我建议使用 GitBook)并进行相关设置
  • 协助解决文档问题

2.) 文档制作阶段(9 月 14 日 - 11 月 30 日)

A.) 第 5 周(9 月 14 日 - 9 月 20 日)

  • 草稿”

B.) 第 6 周(9 月 21 日 - 9 月 27 日)

  • 起草“CHAOSS Community Way”版块

C.) 第 7 周(9 月 28 日 - 10 月 4 日)

  • 起草“成为领导之路”部分
  • 起草“术语”部分

D.) 第 8 周(10 月 5 日 - 10 月 11 日)

  • 起草社区路线图
  • 设计贡献准则草稿

E.) 第 9 周(10 月 12 日 - 10 月 18 日)

  • “草稿开发”部分

F.) 第 10 周(10 月 19 日 - 10 月 25 日)

  • “写作和主动联系”部分指南

G.) 第 11 周(10 月 26 日 - 11 月 1 日)

  • “草稿指标”部分
  • “CHAOSScon”版块草稿

H.) 第 12 周(11 月 2 日 - 11 月 8 日)

  • 设计会议版块
  • 起草社区常见问题解答

    I.) 第 13 周(11 月 9 日 - 11 月 15 日)

  • GSoC 准则草稿

J.) 第 14 周(11 月 16 日至 11 月 22 日)

  • 主动联系指南草稿

K.) 第 15 周(11 月 23 日 - 11 月 29 日)

  • 缓冲时间;完善和改进整个文档

3.) 评估阶段(11 月 30 日 - 12 月 5 日)

A.) 第 16 周:

  • 起草项目报告
  • 填写项目的评估

社区互动

1.) 参与社区讨论和参与讨论。

从 2020 年 4 月开始,我一直在 CHAOSS 社区中冲浪,还与社区成员和我的特定项目导师(Georg Link 和 Armstrong Foundjem)进行了各种讨论。引起社区成员更关注的一个讨论是“提议将 Gitbook 作为托管社区手册的平台”,该讨论可以在 CHAOSS 归档邮寄名单邮件中找到,名为“提议将 Gitbook 作为托管社区手册的平台”。我还参加了社区每周通话,为我向社区更新了最新动态。

2.) 您将如何收集此项目所需的信息?

由于这个项目需要设置整个社区的手册,应向社区成员收集其中需要访问的信息,并与他们进行讨论。我在上方提议了我的时间安排,因此,根据我的建议,我能够在社区凝聚阶段讨论和收集所需的信息。

我会按照 CHAOSS 来研究各个部分,并持续跟进邮件列表。我会试着根据具体要求向我的导师和社区提出澄清性问题。

为了进行简要的讨论,我还会参加每周的通话。

3.) 您打算如何让社区了解您的进度,以及在项目过程中遇到的任何问题或疑问?

为了提高灵活性和透明度,我会试着通过邮件列表讨论来询问我的疑惑。

我会以博文的形式分享我的每周进度,其中包括 Scrum 文档和所面临的挑战,这些内容将会通过社区邮寄名单单独分享,以便吸引开源组织内的更多受众。

我还会参加每周的社区通话,就主要问题提供适当的建议和讨论。

我还打算创建一个 Trello 图板,其中包含可以完成的每周任务。然后,导师可以使用此面板清晰简明地了解当前存在的问题和功能。

4.) 如果你在进行项目时遇到问题,并且导师不在场,你会怎么做?

我认为导师的职责是引导学生朝着正确的方向前进,而不是向学生解释每个循环角落。项目的研究和实现是学生全权负责。记住,只有在万不得已时,我才会尝试向导师寻求帮助。

但是,如果导师在我需要帮助时不在线/忙碌,我将继续在 CHAOSS 社区中分享我遇到的问题。我相信有人能帮助我解决遇到的任何难题。我还会在线论坛/开发者社区(例如 dev.to)分享问题

此外,我会尝试参加每周在 CHAOSS 社区中寻求帮助的电话,以便解答我的疑问。