yingjie@memoir
Yingjie的回忆录

中文

English

中文

English

Appearance

2026-05-15 ​

首要满足的聚合指标：统计 Issue 响应时间、PR 合并效率、贡献者活跃度

  • 统计Issue响应时间：
    • 最初的想法：仓库管理员回复的时间 - Issue发起的时间
    • 发现好像进入误区了，我现在看的是issue的开始时间和关闭时间，和目标关系不大……不过关闭也算一种响应吧，最好和PR结合起来，就是解决问题的时间么
    • 所以仓库管理员第一次回复的时间 - Issue发起的时间
      • 无法通过gitlink-cli获取互动的元信息
      • 发现很多数据似乎是有问题的。closed_on时间是空的。
      • 似乎只能用created_on和due_time来计算了……
      • 有的比较新的仓库，issue的详细信息中created_at和closed_on都是可以用的
    • 目前的想法：计算平均数、中位数？
      • 1天完成的50%，7天完成的10%，>7天10%……
      • 计算平均时间
  • PR合并效率：？

    • 效率是什么？效率p=工作量w➗时间t

    • 具体来说：合并PR的数量➗所需时间

    • PR的详细信息和列表信息里均缺少合并的时间……

    • 合并的数量/开启的数量

    • pr的合并时间merged_at是没有的，或许可以用issue_closed_at来代替？

  • 贡献者活跃度：一段时间内提PR的人数？
    • 一段时间内创建PR的人数，通过pr_full_time确定时间
users(id, user_name)
repos(id, repo_name)
issues(repo_id, creater_id, processor_id, create_time, close_time)
pulls(repo_id, creater_id, processor_id, create_time, close_time)

思考 ​

我发现gitlink-cli可以调整输出格式为表格，正在思考是否能将数据直接存到数据库里。但是感觉这样并不能有效降低复杂度，因为要分析的数据是有限的，这样会引入其他无关数据，带入的过程会增加成本。

我打算先把表设计一下，让目标数据存到对应的字段里，做分析就可以了。 比如对于Issue响应，关注的就是时间，做几个时间字段，将JSON中相关的内容存进去即可。

在任务进行的过程中，发现很多数据是不全的，怎么办？ 不能直接放弃，我觉得靠谱的解决方式应该是继续推进，把基础设施，把工作方法、流程探明，即便现在条件不成熟，未来会成熟的。

是否要做Query？也就是数据的清洗在什么时候进行。 在提取数据的时候，可以使用query来缩小范围。（发现api文档和cli文档中均没有关于query的说明） 也可以在分析数据的时候圈定范围。

目前基本把可以拿到的数据和可以计算的汇聚指标确定好了，下一步就是设计数据库表结构了。

当前要做的事情 ​

  • 根据官方提出来的聚合指标，研究需要哪些原子数据
  • 建设数据分析基础设施
    • 采集脚本
    • 转化
    • 存储到sqlite

结论 ​

  • 统计Issue响应时间
    • 从issue的详细信息获取：closed_on、created_at
    • Issue处理耗时：closed_on - created_at
  • PR合并效率
    • 从PR列表获取：search_count、merged_issue_size、close_count
    • 已合并率：merged_issue_size / search_count
  • 贡献者活跃度：
    • 一段时间内提PR的数量

提示词 ​

prompt
我的判断是否准确，设计是否可行？我认为只需要users、repos、issues、pulls四个表就能支撑下面的任务。

四个表的大概逻辑设计如下：
users(id PK, user_name)

repos(id PK, repo_name, owner(users.id))

issues(id PK, repo_id(repos.id), number, creater_id(users.id), 
processor_id(users.id), create_time, close_time, status('close', 'open'))

pulls(id PK, repo_id(repos.id), number, creater_id(users.id), status('merged', 'close', 'open'), 
processor_id(users.id), create_time, close_time)

issues和pulls表中的processor意思是最终完成PR或Issue的人，在实践中，返回的目标字段可能不叫processor。

任务1：统计issue解决时长，通过gitlink-cli issue +view -owner OWNER -repo REPO -i ISSUE_NUMBER获取issue的详细信息，其中会有closed_on和created_at。计算一个issue的完成时间，用closed_on减去created_at。
任务2：计算PR合并率，通过gitlink-cli pr +list -owner OWNER -repo REPO获取目标仓库PR列表，返回数据中会有search_count、merged_issue_size、close_count。计算PR合并率，使用merged_issue_size 除以 search_count。
任务3：计算贡献者活跃度，统计一段时间内提PR的数量即可。

说明：对于PR和Issue的获取，可以配合--page来控制页数，--size来控制每页的拉取数量，目标是拉取仓库中所有的。

学习对标账号 ​

发现一个名为“白日梦想家”的博主，抖音数据很不错，不过我似乎是通过“萝卜乔乔”认识他的。 目前看了一些分析。

  • 有说他是接地气人设，和观众交朋友。
  • 反差？标题是《挥霍教程》，但视频所展示的日常生活非常节约甚至是homeless
  • 说话声音不高，强迫观众集中精神听， 萝卜乔乔的开头极速报幕和这个可能是类似的

思考 ​

我目前已经结束留学生活回国了。 怎么拍？怎么剪？ 我感觉可以拍回忆录，用积累的素材，拍过去的VLOG，加入现在的想法与当时想法的对比。