[weekly] update draft

1 files changed, 15 insertions, 0 deletions

diff --git a/content/weekly/77.md b/content/weekly/77.md
index 29bccf95..1307d1a9 100644
--- a/content/weekly/77.md
+++ b/content/weekly/77.md
@@ -58,6 +58,19 @@ Olivia Rodrigo 第三张专辑《you look pretty sad for a girl so in love》的
 
 ## 连接
 
+### 有屁就放的艺术
+
+> [!note] 📜
+> [I beg you to follow Crocker's Rules, even if you will be rude to me](https://lr0.org/blog/p/crocker/)
+
+作者讲解了克洛克法则（Crocker's Rules），查阅后我发现这是 MediaWiki 的主要贡献者和 Wikipedia 编辑 Lee Daniel Crocker 提出的概念[^1]。大概的意思是：直接交代信息，去掉社交缓冲层。这是一种社交协议（protocol），前提是双方都同意应该以这种方式沟通，而且一般是在专业场景下和工作关系中。
+
+反例是回复邮件时先道歉「抱歉回复得太晚了」，或者在回复 PR 的时候表示「希望你周末过得愉快」，亦或是在提出问题时写「我知道我可能不该在这里问，如果你不同意的话我完全理解，但我想现在的错误处理方案可能有些问题？」——如果这么问的话，处理这个问题的人就必须再问一句「你能展开谈谈吗？」，才能知道问题具体出在哪里，明明可以在一开始就把问题说清楚，而不是先表明自己是个友善的人，然后征求提出问题的许可。作者认为直接提出问题，就事论事，才是工程师的做法。
+
+作者在开头表示这条规则仅限于文字交流，并且应该在彼此熟悉的团队伙伴之间进行，如果是面对面交流或者面对新人，缓冲层可能是必要的，而且克洛克法则并不鼓励恶意攻击。在我看来，这只是做了课题分离：你听了我的话之后会不会产生情绪、如何应对情绪，是你自己的课题，与我无关。况且，预设对方听不得直接的话所以加上一大堆噪音信息，在我看来更不礼貌。
+
+作者举的一个反例是 *I know this might not be the right place to say this...*，我意识到我前不久才在 Anna's Archive 的 Matrix 群组里说过相同的话，不过我想这是面对不熟悉的环境和人时必要的做法（况且我也真的不知道应该不应该在开发群里讨论这个问题）。在熟人之间能建立起这种就事论事、有话直说的社交氛围，我觉得还挺好的。
+
 ### 用 Git 提升写作质量
 
 > [!note] 📜
@@ -101,3 +114,5 @@ Olivia Rodrigo 第三张专辑《you look pretty sad for a girl so in love》的
 
     不出意外的话，之后就可以在 [@eltrac@tech.lgbt](https://tech.lgbt/@eltrac) 上找到我。
 
+
+[^1]: 来源：[Crocker's Rules - LessWrong](https://www.lesswrong.com/w/crockers-rules)