【讨论】GitHub Star 管理，GitHub Repository Search

[ecmadao]

总能看见有人抱怨 GitHub Star 难以管理，并建议官方推出 Tag 管理 Star 功能，当然官方很痛快的拒绝了🌚。
之前在做 hacknical 的时候，也有很多人建议我在网站上推出 Star 统计与管理功能。虽然当时也很心动，满口答应，但之后想想，这些功能会带偏 hacknical 本身的重点，所以也就一拖再拖。

当然人们群众的力量是无穷的，借助 GitHub API，各类 Star 管理工具层出不穷。

• astralapp 目前看来颜值最高的 Star 管理网站
• Github Star 管理工具 Star Order
• ohmystar 算是颜值最高的 Star 管理 App
• 强烈推荐!自己用的 GitHub Star 分组工具,开源的
• 写了一个 App，用于管理 Github 的 Star，大家请随意吐槽
• 快速查找和管理 GitHub 上 Stars 的一个新轮子
• gitconstellation 网站很大方，配色很瞎眼

... 以及一大波移动端 App（貌似我没见过 Chrome 插件做 Star 管理的？）

但他们的思路其实差不多，大抵都是通过 API 抓取用户 Star，用户可以给各项目打标签，或者加星标，之后通过 App 进行 Star 的项目的管理。

---

先撇开 Star 管理不说，还有一种需求貌似也很旺盛：GitHub 上开源项目的搜索加强。

找不到合适的包、找不到高质量的包、找不到满足自身需求的包。这些因素促成一些 GitHub Repository 搜索增强网站、插件的诞生（此时它们针对的已经不只是 GitHub 搜索了，也有 npm 包的搜索）。比如：

• npms 搜索后对每个包进行质量评估（根据 issue 数、star 数、测试覆盖率等）
• awesomes 网站混杂各种插件，已经不只是库搜索的程度了。。
• awesomes - extension 属于上面那个网站出品，专门搜索前端插件
• awesome-autocomplete-for-github 一个 Chrome 插件，用于 GitHub 搜索的自动补全 + 仓库联想
• npmarket - 更高效的 Node 模块搜索工具（基于 npms.io API）

应该还有好多，一时想不起来了。但是总体上感觉，这些工具的出现都是因为开发者想在项目里引入第三方依赖，但是现有的搜索工具却无法帮助他们快速找到合适自己的仓库。很多时候仓库的名称和描述无法清晰的传达出其用处；除此以外，包的质量评估也是一个缺失的部分，人们通常只能通过下载量和 star 数进行判断。

---

那么 BS 一下：

• 对于 Star 管理而言，有必要通过一个额外的网站或者 App 进行管理吗？会不会浏览器插件才是更好的选择？
• 各个用户对于 Star 项目的管理（标签也好，标注也好，或者是评分制度也无所谓），能否集中在一起，成为一个项目评估的一部分，并以此增强搜索的命中率？

@n41l @wnz27

[n41l]

你看你总是想着来用用户的信息来做分类跟挑选🌚gist那边说到的笔记app中，我有过一个想法也是、给用户一个选择、是否愿意公开笔记、公开后的笔记大家在快速搜索中都是可以根据关键字跟分类搜索的到、打开后可以给予评分帮助优化相关关键字搜索精度

[ecmadao]

@n41l
那也是综合各个用户的行为来增加系统的精准度。。市场上的其他 App 都只是玩单机所以我才这么想了嘛

[n41l]

这两个可以做整合、star不需要一个单独处理、我们服务器上获取到用户star之后、基于相关词生成笔记、每个用户都有自己的一份笔记数据、可以做编辑，这样我们这里也可以用这些数据来做个搜索分类优化 @wnz27 cmadao

[ecmadao]

@n41l
star + gist ?

[n41l]

这个笔记应用的发展方向就是一个极简社区、用户间的交互止步于对共享笔记的评分、收藏、而对于github上star对于所有用户都可以编辑，不过是自己本地的、 @ecmadao

[ecmadao]

@n41l
觉得笔记 + star 管理有些太重，两者的场景和展现形式通常还是不同的。但是就我们上面说的那些，其实它们的数据可以共享，用户对它们的标记和备注这些数据在底层可以通过一个服务共享起来，并以此完善自身

[n41l]

不会太重、star在这个应用里的表现形式就是一条特殊笔记、只有一个可编辑的title、内容就是GitHub地址、分类就只有tag @ecmadao

[n41l]

表现形式上、star这个就是一个浏览器插件、点一下自动生成一条 @ecmadao

[ecmadao]

@n41l
要这么说倒也挺有意思的。。那就是转变了 star 的展现形式，star 和 gist 都是以笔记的形式展示和管理

[n41l]

对、我们可以设立很多类似的扩展、用笔记的形式来做数据分类管理。举个例子、比如star这个、我们在快速启动菜单里（就类似小帽子）、输入star、然后会输出你自己所有的star tag、你再输入tag名、就会显示该tag所有内容。我们需要一个笔记主类型、tag、详细内容，其他的没了 @ecmadao

[n41l]

最后、我们可以把这些讨论换到private repo里、我给我那个同事说一声、如果开做的话、他也可以参与到里面来、笔记应用我跟他也讨论过 @ecmadao

[ecmadao]

@n41l
好，不过具体实施不急，我们有充足的时间去考虑它的展现形式、组织架构。等觉得各方面都 ready 了再开工吧

[ecmadao]

补充 GitHub star 管理插件：

• github-stars-tagger 利用浏览器插件在页面上给项目增加 Tag

对于 star 管理的浏览器插件，我还有一种想法是 hack 用户对 star 按钮的点击，点击后要求用户对该项目增加 Tag 或描述（通过 Modal 或者其他什么鬼的展现形式），来完成从 star 的入口处进行管理的功能

@n41l @wnz27

[n41l]

这个可以、但是有点隐性、可以做两手。其一是这种，其二是存在一个按钮、执行添加tag的操作并且自动加star @ecmadao

[ecmadao]

@n41l
对对，在 star fork watch 那排按钮中增加一个一毛一样的，比如叫 mark 什么的

[ecmadao]

新增一个网站，可以通过图表的形式来展现自己 star 的项目的分布，但其只能在时间轴上展现出 star 的项目语言的分布：

• https://starred.jjperezaguinaga.com

[ecmadao]

GitHub 对 项目 label 的支持，仓库管理员可增删 label：

[ecmadao]

@n41l @wnz27

现在 JARVIM 可收集的数据有：

从用户的角度出发，使用插件的过程中，他可以为自身的数据带来：

• 新的 mark

  • 仓库的描述
  • 仓库的标签
  • 仓库所属的语言

• 一次搜索

  • 搜索的描述
  • 搜索的反馈（点击任意一个搜索的结果，都会向 server 发送通知）

从仓库角度出发，被 mark 或搜索以后，能够获取的信息有：

• label
• keyword（由 description 分词解析而来）
• hits（用户搜索后点击某个仓库的次数）

---

目前，我们使用多维空间向量来进行仓库的搜索。当用户输入值后：

1. 句子分词解析
2. 在数据库里索引解析到的各个关键字，每个关键字对应了数个仓库
3. 各个仓库有独特的标识，标识它和这个关键字有多强的关联度
4. 因此，比如一句 “Node.js 数据缓存库”，会被分隔成 ["Node.js", "数据", "缓存", "库"]，从每个词中取出了若干个仓库，仓库与各个关键词的关联度为 [Xa, Ya, Za, Da]，a 代表第几个仓库，即第一个仓库就是 [X1, Y1, Z1, D1]。
5. 将 X, Y, Z, D 看成是一个四维坐标系，则 [X1, Y1, Z1, D1] 可以作为从零点 (0, 0, 0, 0) 到 (X1, Y1, Z1, D1) 点的空间向量。至此，向量的长度可以作为搜索的匹配度；各个向量的角间距可以作为仓库的关联度（或相似度）

注：

1. 仓库与各个关键词的关联度，收到用户对仓库的描述影响。比方说，很多用户对某个仓库的描述都有 “缓存” 这个词，则该仓库与 “缓存” 的关联度较高。
2. 用户点击搜索结果后，会通知 server，server 对点击的该仓库的 hits 字段加 1，代表被点击次数，从侧面反馈该仓库与用户搜索的那句话的关联度。hits 字段会在一定程度上（比重比较小）影响关联度

所以，如何进一步提升搜索的精准度？

[lessfish]

感觉还是浏览器扩展管理 stars 方便，但是没有遇到一款好用的