22 年春季开源软件设计与开发课程仓库。

• 期末作业成绩：40%
• 其中作业成绩：30%
• 平时作业成绩：20%
• 课堂考勤成绩：10%

习题地址：Learn Git Branching

要求范围：主要部分的 “基础篇”、“高级篇”、“移动提交记录”

提交地址：Issues · X-lab2017/22-Spring-OSDD (github.com)

提交形式：在 issue 的页面开启一个新的 issue，命名格式：Assignment-1 <学号>。此后每完成一个任务点，就截取网页的图像发到 issue 中。（注意网页数据存储在浏览器，如果有清理浏览器缓存的习惯可能会丢失，所以请及时截图记录）

截止时间：当周周日晚上 24:00 点前，按时提交作业将作为平时成绩的参考。

实验目的：帮助同学复习常见的 Git 指令。作为课程任务会给大家合适的练习量，其余未指定的部分我也十分建议有时间都尝试一遍。

想要完整系统地了解 Git 的全部知识，助教个人还是推荐阅读开源教材 Git - Book (git-scm.com) （全书文本开放在线阅读，有社区提供的中文翻译）

接续作业 1 “Push & Pull —— Git 远程仓库”。

实践概述：参考教材 G4D 第四章至第五章，选择自己喜欢的静态网站生成方案，部署自己的 Github Pages。

具体要求：

1. 包含任意一篇自己任意内容的文档。
2. 安装个性化的样式。

提交地址：Issues · X-lab2017/22-Spring-OSDD (github.com)

提交形式：在指定 issue 内 评论自己 GitHub Pages 的链接与学号。

截止时间：下周周日晚上 24:00 点前。（暂定给两周的时间）

备注：假如同学已经提前有了自己的博客，可以提交自己已有的技术博客的链接。

作为工作量的替代，我们会邀请已有博客的同学上台来与大家分享以下几点：

• 什么时候开始的？
• 驱动自己去折腾个人博客的动力是什么？
• 采用了什么样的技术方案？
• 最近写了哪些内容，简单介绍介绍。

实验概述：挑选开源项目，从一些角度进行分析，准备下次课堂的 5 分钟左右的分享。

提交形式：在指定 issue 内 评论自己选定的仓库链接与学号。（早点选定防止和他人重复）

截止时间：当周周日晚上 24:00 点前。（一周时间）

切入点：

• 仓库的主要内容
• 仓库的主要贡献者
• 仓库在当时火热的原因

以下表是 Open Digger 社区提供的 2021 年每个月份热度较高项目的名单，同学可以用来参考：

也可以参考一些网站提供的热度排名，比如 GitHunt – Trending Github Repositories，有更具体的时序数据。

实践概述： 创建一个仓库，存放至少一个 markdown 文件，借助 Github Action 的功能来实现自动格式转化。

具体表现为：每次 push 更新 markdown 的时候，Action 自动重新转换这个文件构建新的 pdf 存放到项目的 release 当中。

实践步骤：

• 创建仓库，命名不限。
• push 一个 markdown 文件到当前仓库中，内容随意，不建议太短。
• 在 .github/workflows 目录下创建 your-action.yml 配置本项目的流水线。（这一步会比较花时间）
• 在正确配置以后，push 更新 markdown 的内容，查看 Actions 页面是否增加了流水线的记录。（类似这样）

参考资料：

• GitHub Actions 的工作流程语法 - GitHub Docs
• 助教曾写过的一份流水线配置

提交形式：在指定 issue 内 评论自己的仓库链接与学号。

截止时间：下次课程前一天晚上 24:00 点前。（一周时间）

其他信息：

Action 可以理解为一次性地租用 Github 的服务器，你可以配置这个服务器安装什么环境，执行什么命令。并且默认地，你的仓库的代码会存在于这个服务器当中。

当你有了环境和执行命的条件，就可以把许多重复性的任务从本地转移到服务器上。

比如要构建一个 release，可能每次更新都要重新构建，如果手动操作再上传的话，会有本地环境的不确定性，并且很麻烦。Action 就能解决这个问题。

当然，转化 markdown 并不复杂，当项目的编译过程更加复杂的时候，手动的代价就更高了。

网络上进行转化的方案有很多，甚至有现成的 Action 可以直接调用，同学可以根据自己情况选择适合的方案。常见的方案是借助 python 或者 pandoc 的 Action 指令。

感兴趣的话，而可以尝试更进阶的主题：借助脚本，合并多个 md 文档，产出一个 pdf。

实践概述：

GitHub 开源项目分析报告

内容包括但不限于以下几点，可以根据自身情况，添加其他有趣内容。

1、项目基础数据分析

项目简介，Star/Frok 数量，累计 Issue/PR 数量，累计贡献者数量，主要开发语言。

2、项目协作数据分析

列出 Top5 开发者/Top5 关联项目。（可借助 Hypercrx 插件）

并分析 top5 关联项目与本项目的关联原因。

3、项目文档内容分析

该项目是否有明确的 README/贡献指南能够让新手快速了解并明确向项目的贡献方式。

可以提出对项目文档和参与流程的建议。

4、项目实际体验分析

如果这个项目有落地的产品：例如在线网页/开源软件等，可以介绍产品的使用流程。

如果用流程较难描述，可以尝试观察这个开源项目的 github issues，总结近一个月内社区内最讨论最热烈的 3 个议题，附上 issue 链接和自己对该 issue 的简单看法。

如果条件允许，也可以提出自己的 issue 作为上述 3 个议题之一。

5、社区/项目推荐列表

GSoC 项目：https://summerofcode.withgoogle.com/programs/2022/organizations

开源软件供应链点亮计划：https://summer-ospp.ac.cn/#/org

提交形式：

向助教邮箱([email protected])发送本实验报告。

文件格式 <学号>-<姓名>.pdf

邮件标题 OSDD-6-<学号>-<姓名>

截止时间：下一周周末（五月八日）23:00 点

根据官方的解释，归档（Archive）是指当项目停止维护后将其设置为“只读”状态。

附录中提供了一批曾高度流行的 GitHub 归档项目列表，每位同学从其中选择一个项目进行分析，不能重复选择。

选择项目：

Assignment-7 · Issue #27 · X-lab2017/22-Spring-OSDD (github.com) (#27)

回复 issue 以选用项目，格式为 <序号> <项目id> <项目名>，例如：3 2935735 adobe/brackets

提交文件：

• <学号>-final-report.md
• <学号>-data.ipynb （根据选做情况可以没有）

请在 5 月 30 日（最后一次课之后）前提交到课程仓库。

提交形式：

• fork 课程仓库。
• clone 自己的 fork 到电脑。
• 创建分支 <学号>-final-report。
• 把文件加入到 ./final-report 目录下。
• commit， push。
• 在 GitHub 上上传分支，等待助教合入。

报告内容：

通过项目仓库的查阅，以及搜索引擎上项目的相关资料，给出项目一些基本的介绍：

• 技术类型
• 版本发布历史
• 主要贡献者的构成（国家、区域和组织等）
• CI/CD 的使用
• 其他有价值的信息

本节可以选做（0~8 个），本次作业会按照做的数量给予更高的评分。

基于给出的镜像数据和 OpenDigger，完成项目 2015 年/创建 - 归档期间的以下数据分析任务：

1. 每月新增 Star 和 Frok 的个数
2. 每月打开 Issue 和 关闭 Issue 的个数
3. 每月打开 PR 和 合入 PR 的个数（注意，关闭 PR 不等于合入）
4. 每月在仓库中活跃（只要有日志产生就算）的不同开发者（也就是一个 GitHub 账号）总数
5. Issue 从打开到关闭的平均时长和中位数（单位：天）
6. PR 从打开到合入的平均时长和中位数（单位：天）
7. Issue 和 PR 从打开到第一次有人回复（非本人回复）的平均时长和中位数（单位：天）
8. 根据你观察到的仓库的历史数据，尝试找到几个你认为关键或值得注意的时间节点 说明：

• 对于任务 1-4，数据结果展示以月为单位，给出每月数量的曲线图和表格
• 对于任务 5-7，数据结果展示以天为单位，仅给出数值即可
• 对于第二块的数据分析内容，交付形式为一份 jupyter 文件
• 镜像中提供了一共 172 个归档项目数据，有兴趣的话欢迎探索单个项目以外的横向对比分析

数据镜像的获取方式：（前提: 本地需要安装 docker 环境）

docker pull xlab-registry.cn-shanghai.cr.aliyuncs.com/opendigger/github-log-archive:202204

• 阅读分析项目的相关信息：
  • 主页、主要贡献者发表的相关技术博客
  • Issue 和 PR 中的相关讨论
  • README 文件，贡献者指南，Code of Conduct 及其他可能有的相关文档
• 结合一和二中得到的信息和分析结果，尝试总结项目可能的归档原因
• 结合你搜集到的信息，尝试分析项目归档后可能产生的影响（对开发者和用户）
• 表述你对开源项目如何可持续发展的理解

https://github.blog/2017-11-08-archiving-repositories/

https://docs.github.com/en/repositories/archiving-a-github-repository/archiving-repositories

https://tommcfarlin.com/why-im-archiving-my-github-repositories/

https://iliana.fyi/blog/everything-that-lives-is-designed-to-end/

开源课程实践指南 (shimo.im)

GitHub 协作指南.pdf - (shimo.im)