确定 2024 年春季学期开源课程的评价方式 about oss101 HOT 8 OPEN

先上个语雀画板~

素材区：

1、多个人一起完成PR的例子：hypertrons/hypertrons-crx#477 (comment)
2、为OSS101创建的label：

from oss101.

根据 2023 年的方案：

• 课堂签到：10%
• 平时作业：30%
• 期中测试：10%
• 期末大作业：50%

可以考虑将 2024 年的做如下优化：

• 签到，10%，不定期三次或以上的随堂签到
• 平时作业，30%，总共三次，在仓库中按时提交完成即可拿到相应分数
• 期末大作业，60%，其中
  • 人工评审，30%，教师和助教根据大家作品完成情况主观给分
  • OpenRank 贡献度评价，30%，根据大家本学期在课程范围内的活跃情况，由算法自动给分

平时作业说明如下：

• 作业 1：静态网页部署
• 作业 2：GitHub 基本协作
• 作业 3：GitHub Action 实践

期末大作业的几个要点说明如下：

• 选定 GitHub 上面的若干开源项目，在每个开源项目下面设置 5 ~ 15 个任务
  • OpenDigger（数据与算法类型项目），拟设计 15 个任务
  • HyperCRX（前端插件项目），拟设计 15 个任务
  • OpenLeaderboard（前端 Web 项目），拟设计 10 个任务
  • OpenPerf（科研类项目） ，拟设计 5 个任务
  • X-lab 官方网站，拟设计 5 个任务
• 同学自由组队参与 1 个或多个任务
  • 每位同学至少完成 1 个任务
  • 每个任务/模块的参与人数不限
  • 可以同时参与到多个任务中，OpenRank 贡献度评价部分可以累加，人工评审部分取所有参与的任务中最高分数

from oss101.

• 可以同时参与到多个任务中，OpenRank 贡献度评价部分可以累加，人工评审部分取所有参与的任务中最高分数

感觉还是要限制一下每个人参与的任务数量，担心会出现一个人参与10多个项目，就是为了最后拿人工评审部分取所有参与的任务中最高分数。
为了避免出现上面的问题，或者可以自己参与哪些任务一开始应该就定好，不能再加了。如果开发的过程中发现自己的任务和别的小组有重叠(比如都选了opendigger中的同一个任务)，可以允许两组合并为一组。不能出现自己选的opendigger的任务做不成了，期末最后没几天了，发现另一个组hypercrx做的很好，就加入另一组，混个高分。

from oss101.

• 可以同时参与到多个任务中，OpenRank 贡献度评价部分可以累加，人工评审部分取所有参与的任务中最高分数

感觉还是要限制一下每个人参与的任务数量，担心会出现一个人参与10多个项目，就是为了最后拿人工评审部分取所有参与的任务中最高分数。 为了避免出现上面的问题，或者可以自己参与哪些任务一开始应该就定好，不能再加了。如果开发的过程中发现自己的任务和别的小组有重叠(比如都选了opendigger中的同一个任务)，可以允许两组合并为一组。不能出现自己选的opendigger的任务做不成了，期末最后没几天了，发现另一个组hypercrx做的很好，就加入另一组，混个高分。

这可肯定也是可以设置的。就看必要性是否需要，有几个点可以参考：

• 所有的行为都是公开的，一个同学参与很多项目，大家都看得到；
• 如果这种参与式正向的，例如教师或助教的行为就会这样，也没问题；
• 如果是为了高分，这种在算法上就应该能够避免，例如大家可以通过👎进行减分操作；
• 所以这里面会比较考验老师和助教的协调与管理工作，同时也可以发动积极的学生参与管理工作，这个也是开源社区的一种属性；
• 如果只是最后几天加入某个组，这种事情可以让那个组自行裁决，但他对应的 OpenRank 值肯定是不高的；
• 同样，这些行为因为都是公开的，我们可以及时发现及时讨论，甚至迭代课程评分的策略

from oss101.

• 同样，这些行为因为都是公开的，我们可以及时发现及时讨论，甚至迭代课程评分的策略

是的，可能有不少问题我们现在还无法完全预知，我们在实践的过程中再慢慢优化

from oss101.

这两天对“开源教育”做了个总结，如下图所示：

本学期课程实践部分，主要就是红框中的内容，对应到本 Issue 上面的内容就是：

• 做贡献：通过三次平时作业，学习并实践基于 Git/GitHub 的开源贡献模式，内容已经确定
• 实践教学：基于项目的教学实践方法（PBL），又包括三种模式，EOSS 1.0、EOSS 2.0、和社区实习，这块需要进行选择

1、EOSS 1.0 模式

基于“完形填空”形式的简化版开源项目实训，例如 TinySQL、TinyKV、MiniOB。

• 优点：a) 某一开源项目的简化版本，学员易于理解并参与；b）任务和目标明确，能对应到细粒度的知识点与能力点
• 缺点：需要专业人员来制作简化版本，制作与学习均有一定的门槛；由于不需要实际的开源贡献，无法核算 OpenRank 贡献量

2、EOSS 2.0 模式

基于“历史版本”形式的历史版开源项目实训，目前还处于一个空白阶段，属于首创行动。

• 优点：a) 某一开源项目的历史版本，项目制作相对简单；b）任务和目标明确，能对应到细粒度的知识点与能力点
• 缺点：虽然项目直接采用某一历史版本，但任务的选取与设置，还是有一定的门槛，需要对项目有深刻了解；同样，由于不是当下版本，属于某一历史时刻上的开源贡献，OpenRank 贡献量核算效果大打折扣

3、社区实习模式

基于“当下版本”形式的真实版开源项目实训，又可以分为两种：

（1）当下版本 + 规定任务

在当下版本的基础上，设置若干具体明确的任务，学生以参与并完成这些任务，GSoC 和 OSPP 就是其典型代表。

• 优点：a) 直接用当下真实的项目仓库开展工作，任务和目标明确；b）能够为项目带来真实的贡献，能够核算一定程度的 OpenRank 贡献量
• 缺点：需要基于当下版本设计任务列表，需要较强的专业度，完成过程也需要项目核心成员作为导师全程参与，并对完成效果做出评价

（2）当下版本 + 自选任务

在当下版本的基础上，不设定具体明确的任务，学生和项目成员自发讨论，并形成需要完成的任务，例如 XSOSI、阿里开源贡献榜。

• 优点：这是最接近理想阶段的开源贡献场景，和真实的开源项目贡献完全一致，项目发起方不需要额外的花费，做平常该做的事情，并能够通过 OpenRank 贡献量核算工具，对项目进行运营
• 缺点：对参与学员有较高的要求，需要主动和项目核心成员进行频繁互动，形成共识性任务，并最终贡献到仓库中

目前看上去，“当下版本 + 规定任务”，在高校教学场景中是一个可行的选择，且满目实验室的各种诉求：

• 学以致用，基于课堂上学到的内容，参与真实开源项目的贡献
• 能够进行 OpenRank 贡献量核算
• 能够为目标开源项目，带来真实的贡献

另外，从课程教学设计的角度，一个相对完整的开源教育（开发者成长）路径大致是：

1. 拥抱开源-A：学习基本的数字素养与编程技能
2. 拥抱开源-B：学习开源基础知识（开源爱好者，Hobbyists，H）
3. 贡献开源-A：学习并实践 Git/GitHub 基础操作（成为社区参与者，Community Participant，P）
4. 贡献开源-B：在 EOSS 1.0 或 EOSS 2.0 中选择一个，开展基于某一具体项目的实践教学（成为项目参与者，Project Participant，PP）
5. 发展开源-A：基于规定任务的项目社区实习模式（成为项目短期的普通贡献者，Contributor，C）
6. 发展开源-B：基于自选任务的项目社区实习模式（成为项目长期的核心贡献者，Committer，CC）

学校阶段的课程教育，大概能否覆盖到 1-4 阶段；5-6 阶段则需要企业、社区或基金会等组织，联合开展一些专项活动来达成。

from oss101.