文章分类整理工作

[yihui]

书接 #6。因为 #6 的任务太大了，所以新开一个事项，先完成它的一个子集：只整理分类信息，先不管标签。

目的

先说分类的最高目的：分类就是我们的子品牌。我们的文章包含哪些子品牌，或者说统计之都涵盖哪些栏目（像报纸一样）。这是整个统计之都的文章品牌建设问题。其次，因为所有的分类名都是可点击的链接，所以读者可以很方便只阅读她关心的栏目。这是为读者提供一个方便的导航。

分类建议

目前的所有分类在：https://cosx.org/categories/ 可以看到它们是一团浆糊：

R (2) Web API (1) cos 访谈 (9) ggimage (1) ggplot2 (1) leaflet (1) 中国 R 会议 (2) 中国 R 语言会议 (7) 优化与模拟 (16) 出国留学 (3) 分析与代数 (1) 可视化 (9) 回归分析 (12) 图书出版 (5) 图片 (1) 地图 (1) 地理信息可视化 (1) 多元统计 (3) 抽样调查 (3) 推荐文章 (97) 数学方法 (7) 数据分析 (32) 数据挖掘与机器学习 (47) 新闻通知 (77) 时间序列 (3) 概率论 (9) 模型专题 (7) 每周精选 (23) 沙龙纪要 (4) 生物与医学统计 (17) 经典理论 (27) 统计之都 (196) 统计刊物 (10) 统计图形 (40) 统计推断 (27) 统计计算 (16) 统计软件 (89) 网站导读 (40) 职业事业 (55) 计量经济学 (4) 试验设计 (7) 贝叶斯方法 (6) 软件应用 (60) 金融统计 (4) 随机过程 (5) 非参数统计 (3) 风险精算 (7) 高校课堂 (9)

结合 #6 中 @Huimincheng2015 的建议，我给出我的建议分类供讨论：

• 统计之都：这个分类是当前被滥用最多的（原因大概是过去作者们不理解这个分类的意思），它应该只被用在跟统计之都这个集体、组织密切相关的文章上，比如统计之都网站的改版、统计之都主办的活动等。我的结论是绝大多数文章的这个标签都应该被去掉。这个分类应该重命名为“新闻动态”，避免将来误导更多作者。可以归并原来的分类：新闻通知、网站导读、每周精选、沙龙纪要。

• COS访谈：因为有特色

• R语言：它可以作为所有跟 R 语言相关的文章的分类，在一篇文章分类中的排位取决于这篇文章跟“语言”的相关程度，比如 R 会议跟 R 有关，但 R 会议的文章应该优先使用 R 会议的分类；统计计算的文章如果用了 R，但主要强调计算方法，也不应该用 R 语言作为第一分类；类似 R 包开发、R 的程序特征类的文章用 R 语言的分类才比较合适。

• R会议：跟新闻动态分类有重叠，但 R 会议是我们重要的牌子，我觉得值得单独列一类。

• 统计计算：可能可以归并原“统计软件”、“软件应用”分类。

• 统计图形（诸如可视化、地图等分类都可以归并到这个分类）

• 统计模型：可归并统计理论

• 统计应用：可归并数据分析

• 机器学习：因为它热

• 职业事业：可以归并出国留学

• 推荐文章：我们根本没有一个推荐机制，所以这个分类过去其实一直是在胡来，但我觉得这个栏目也有存在的必要。因为现在再回去一篇篇读了投票是否推荐太不现实，所以只能靠整理分类的小编凭良心推荐了。

如前面所说，一篇文章可以有多个分类，但我建议每篇文章不要超过三个。分类需要高度概括，但也不能太抽象，比如“统计学”对统计之都网站来说就不是一个合理的分类，因为读者看到这个分类之后对文章的内容毫无概念（统计之都就是关于统计学的啊）。分类的作用是给读者一个大概概念，比如关心 R 会议的读者一般不会误入职业事业栏目（不能说二者绝对没有交集，但交集肯定是非常小）。

原来存在但这里没有提到的分类就请小编自己机动处理了。我的大体意见是，如果一个分类下面只有寥寥几篇文章，那这个分类可能没有存在的必要。但又有两个可能性让它有存在的必要：一是有些文章忘了使用这些分类名；二是这个分类是我们想建设的品牌，但现在的文章还太少，将来会更着重去约稿。

上面的分类并不是死的，随着时间推移可以再更新，等我们先把一团浆糊理清澈一点了再讨论新分类吧。

技术细节

blogdown 包中有个 find_categories() 函数也许可以帮帮忙，比如查找包含特定分类的文章：

devtools::install_github('rstudio/blogdown')
blogdown::find_categories('R')  # 查找含有 R 分类的文章
blogdown::find_categories(NULL)  # 查找分类完全缺失的文章

# 找到 R 分类下的所有文章并在 RStudio 里自动打开那些 .md 源文件
blogdown::find_categories('R', open = TRUE)

但并没有直接的替换分类的函数，需要小编自己动手丰衣足食。以下是一个示例，原谅我已经没有脑子更详细解释了：

files = list.files('content/post', '[.]md$', full.names = TRUE)
for (f in files) {
  blogdown:::modify_yaml(f, categories = function(old, ...) {
    # old 是当前文章的分类向量，有可能是 NULL
    # 下面对 old 做一些操作，并返回新的分类值
    old[old %in% c('R', 'ggimage', 'leaflet')] = 'R语言'
    unique(old)
  })
}

修改分类时要在 git 里面看看差异，每修改一次看一次，觉得没问题就提交一次，然后再修改再看，这样反复迭代。不然等全改完了再来看差异可能会昏掉。先用自动化方式处理，完了之后再用人眼来一篇篇过。

[tomatoiscoding]

初步尝试了一下～

[yihui]

我看了一下 e34098d 有这么几个问题：

1. 不知道 categories 怎么都跑到 YAML 的第一项去了，这个有点不合理，第一项应该是标题，然后作者、日期等。将来别人来读 Markdown 源文件，第一眼看见的是分类，可能会感觉怪怪的。

2. 这次提交我看绝大部分都是冗余修改（移动了 categories 的顺序以及双引号变单引号），巨大的差异让事后评审工作变得有点沉重，不知道你修改的真正目的是什么，所以我倾向于建议你下次先发 PR。

3. 提交消息就两个词：“update categories”。这是骗银滴。你真正做的工作明明不是 update categories，而是我上面说的。再引一下我目前最后一篇日志中的话：https://yihui.name/cn/2017/06/git-add/

   某种情况下，GIT 历史就是精神分裂的自己跟自己的对话，为了六个月甚至更久之后的自己还能明白当时在干啥。说到这儿，我又忍不住吐槽那些用一个词作为 GIT 提交消息的行为了，放眼望去，历史记录中就一个单词在不断重复：update（废话，我当然知道你在更新，可更新了啥以及为什么更新呢）。当然，这个有时候也可以理解，尤其是无关紧要的私人项目，随便写写 GIT 消息也无妨。如果做一个想要后继有人的项目，每一次更改最好是写上一条完整的消息。

   望下次提交时稍微解释一下具体做了什么。

4. 上面最后一句话我提到：

   修改分类时要在 git 里面看看差异，每修改一次看一次，觉得没问题就提交一次

   本意就是让你先看看变动到底是什么，以及想一想这些变动是否合理。比如这次提交中，你需要想想为什么 categories 的位置变了，这个变化有没有意义。在版本控制中，尽量不要做没有意义的改动。你的每次修改，都要想象台下有几万人在看着你改，你要对他们讲清楚你为什么改。这么说有点浮夸，但在这件事上稍微逼迫一下自己，对所有人都有好处，包括你自己。

谢谢！

[yihui]

又及，我觉得优先级最高的是首页的12篇文章。那些触目惊心的“未分类”让人实在是夜不能寐，先把它们的分类理顺了吧，后面的可以藏在地下慢慢清理。

[tomatoiscoding]

嗯，我试了几个脚本，都是更新完会把categories搞到yaml的第一个位置，保持不变的文章也会自动去刷一遍，我还没想清楚为啥。至于提交的原因，我是觉得它跑到第一个位置关系不大。。。我只好git revert一下了...

[yihui]

对外确实是毫无关系，改变任何 YAML 选项位置文章都不会有任何变化；只是对内有关系，看源文件的人第一眼看到的是分类而不是标题，另外造成了无谓的 GIT 历史记录。不好意思，我的洁癖非常严重，对外对内都要保持整洁，但我也不强求。

[tomatoiscoding]

嗯，我之后以PR的方式操作，抱歉 😭

[yihui]

跪谢！

[tomatoiscoding]

如果不准备拍死我的话，我现在解决冲突并操作git revert可以吗？:sob:

[yihui]

可以不必 git revert，就在现在的基础上继续走就好了。如果你的 PR 里能把纯位置移动的变动和有实质意义的变动分开做 git commit 就最好了，这样评审的人只需要看后者。

[tomatoiscoding]

我看这“统计软件”是不是还得保留一下啊？除了R语言，还有好多SAS，SPSS，编辑器啥的啊 @yihui

[yihui]

@tomatoiscoding 我没有意见。全权交给你了。

[tomatoiscoding]

分类用了一上午彻底结束掉。