Newbandysol
commented
5 months ago "但对于程序员来说，这是用代码说话的世界。于是就有网友指出了一些代码问题，当然措辞的攻击性比较强"
OSChina说得很好啊
Open ghost opened 6 months ago
Newbandysol
commented
5 months ago "但对于程序员来说，这是用代码说话的世界。于是就有网友指出了一些代码问题，当然措辞的攻击性比较强"
OSChina说得很好啊
Newbandysol
commented
5 months ago 虽然回复这种三分钟前注册的小号没啥意义，但想了想还是说一下，顺便回复一下 @TabNahida 说的。
第一，“玉玉症是这样的，还请不要见怪吧？”，我看到了这句话。 第二，他的原话你都不能贴出来么。他用的可不是“糟糕”这个词。现在大家戾气都重，中国的孩子可能在学校里也习惯了或是言语攻击或者是卖弱或是互膜等等。但这不意味着有些话你能在一个国际社区上直接说出来，还希望别人认同它是温和的。 第三，我可以的，当然更可能是直接走开，我没有那么多评论别人的兴趣。不要以为每个人都和你一样。
“玉玉症”这样的说法让我感到不适。这个词最初出现是为了嘲讽那些动不动就说自己抑郁的人。作为一个曾经轻度抑郁患者，我不会把这个词当玩笑说出来，因为这好像在把我经历过的痛苦化为笑谈。或许你可以解释一下这里有什么反讽的成分，讽刺了什么。
如果TabNahida是她的同学，现在当务之急是帮她解封GitHub账号，以及帮她面对她的病症。祝好。对于你的评论我不想回复太多，如果你认为她的issue标题 is just moderately describe the issue of the code，我认为你们离你们向往的“开源精神”还有不少路要走。
评论的各位其实说得很委婉，但你们不要以为大部分人赞同异月的这种方式。大家只是觉得这样的争吵很幼稚，无意讨论罢了。
事实上，我的大号被盗用做了一些事，所以他的评论不可见。
"但对于程序员来说，这是用代码说话的世界。于是就有网友指出了一些代码问题，当然措辞的攻击性比较强"，讲真的，我很不理解为什么有人会讨厌批评——即使语言并不很礼貌，他也的确指出了问题。（253个警告未免太离谱了吧）
如果你要跟我谈中国的社会现实，那对不起，如果某人毕业去工作，任何一个正常的公司都不可能接受一个不会改正自己的错误的人。我说”如果PR是正确的，我们要做的是合并它。而不礼貌与PR的内容没有任何关联。我们当然可以对不礼貌提出批评，但是这和PR有什么关系？“。而批评的正确与否和批评的用语有什么关系？
”中国的孩子可能在学校里也习惯了或是言语攻击或者是卖弱或是互膜等等“。请你注意一点，这些”言语攻击“通常来说都是没有根据的。而他的批评是正确的。
我把这句话还给你：”不要以为每个人都和你一样“。你可以忍受有人对这种东西大肆夸赞，然而不是每个人都可以忍受的。
”is just moderately describe the issue of the code“？对不起，虽然我不懂rust,但是如果指针满天飞的话还不如用c++或者c，这样rust的优势完全没有体现出来。
”我认为你们离你们向往的“开源精神”还有不少路要走“。请先注意，我只是说我们要就事论事。如果批评是正确的，我们应该接受批评，而如果他的用语并不礼貌，我们当然可以要求他礼貌，然而这与批评的正确与否没有任何关系。“不贵于无过，而贵于能改过”
“不要以为大部分人赞同异月的这种方式”，我并没有说我完全赞同他的做法，也没有说我并不赞同他的做法。我在上面说过：这与批评的正确与否没有任何关系。批评是批评，措辞是措辞，两者之间没有任何联系。
”在你发表任何你的意见之前，请先尽可能多地了解事件的经过“。请你注意，他并不是一上来就进行所谓的”言语攻击“，他是在写PR的过程中被恶心到了而添加了这些语句，这在他的说明中已经清楚的表述过了。显然他被代码恶心到了。
TabNahida
commented
5 months ago 事实上，我的大号被盗用做了一些事，所以他的评论不可见。
"但对于程序员来说，这是用代码说话的世界。于是就有网友指出了一些代码问题，当然措辞的攻击性比较强"，讲真的，我很不理解为什么有人会讨厌批评——即使语言并不很礼貌，他也的确指出了问题。（253个警告未免太离谱了吧）
如果你要跟我谈中国的社会现实，那对不起，如果某人毕业去工作，任何一个正常的公司都不可能接受一个不会改正自己的错误的人。我说”如果PR是正确的，我们要做的是合并它。而不礼貌与PR的内容没有任何关联。我们当然可以对不礼貌提出批评，但是这和PR有什么关系？“。而批评的正确与否和批评的用语有什么关系？
”中国的孩子可能在学校里也习惯了或是言语攻击或者是卖弱或是互膜等等“。请你注意一点，这些”言语攻击“通常来说都是没有根据的。而他的批评是正确的。
我把这句话还给你：”不要以为每个人都和你一样“。你可以忍受有人对这种东西大肆夸赞，然而不是每个人都可以忍受的。
”is just moderately describe the issue of the code“？对不起，虽然我不懂rust,但是如果指针满天飞的话还不如用c++或者c，这样rust的优势完全没有体现出来。
”我认为你们离你们向往的“开源精神”还有不少路要走“。请先注意，我只是说我们要就事论事。如果批评是正确的，我们应该接受批评，而如果他的用语并不礼貌，我们当然可以要求他礼貌，然而这与批评的正确与否没有任何关系。“不贵于无过，而贵于能改过”
“不要以为大部分人赞同异月的这种方式”，我并没有说我完全赞同他的做法，也没有说我并不赞同他的做法。我在上面说过：这与批评的正确与否没有任何关系。批评是批评，措辞是措辞，两者之间没有任何联系。
For me, if someone point out my problem with sharp languages, I might talk back with . Yet I will still check whether I truly have problems. Bylx666, however, dose not notice that he has any serious problem. By the way, any static language programmers will think codes which widely use static variables are shit.
E0SelmY4V
commented
5 months ago 第一次赶上开源社区大讨论的直播，合个影！😁
顺便说一句就是 Rust 官方有很完善的教程，官网有专门一个页面介绍了 Rust 的学习资源。 我最近也正在看，特别是其中的《Rust 程序设计语言》。 这本书前几章就把项目开发中需要注意的一些比较重要的事情都讲解了，比如官方自带的格式化工具、package 和 crate 的组织方法、私有和公开代码、还有各种业务上的最佳实践之类的。 如果英语好的话，还可以读这本书的互动版，里头有各种小测试和直观易懂的图表，甚至从第 6 章开始还会有取自 StackOverflow 的经典 Rust 编程问题（一系列选择题）等你解决，配有 VSCode 一样的“浏览器 IDE”，看起来十分的高级。
这里推荐阅读一下。
Newbandysol
commented
5 months ago @LUO12826 Bylx666的道歉
为什么你如此在意他的措辞？语言只是交流工具，真正重要的是说的东西而不是怎么说。
你一直提”言语暴力“，然而”语言暴力是使用谩骂、诋毁、蔑视、嘲笑等侮辱歧视性的语言，致使他人在精神上和心理上遭到侵犯和损害“。这段话是从华南师范大学心理咨询中心找到的。请你告诉我，他的话是”谩骂、诋毁、蔑视、嘲笑等侮辱歧视性的语言“吗？
@Bylx666 已经意识到他的错误并且道歉，而你又对他的措辞提出意见（并且很可能导致了他的病情加重），我是否能说你在”言语暴力“？毕竟”学会说话，学会尊重“就是在侮辱他不会说话呢。
lexoooooo
commented
5 months ago 这件事情实际上并没有太多争议。您有权利去喜欢或不喜欢一样事情，这是您的自由。但您无权用言语伤害/攻击别人。这违反了Code of conduct。也在伤害我们的社区。
纵使代码质量不高，把这个项目开源出来就是在贡献社区。写一篇issue来骂maintainer写的代码真烂。这对社区无益。请不要随便把跟项目无关的东西放到issue来。你可以说「世界上没有理性的人」。但这并不能合理化你的行为。因为你在做错误的事情。人不是动物，忤逆情绪的本能是我们人的高等智慧的体现之一。
以及，你的沟通方式明显存在问题。你说你在14岁就实现了一个更好的编译器。那么你很棒很厉害，我佩服你。也许maintainer的代码水平并不如你。但实际上，纵使你在代码水平强过别人。你也依然必须对他人保持尊重。请不要把社会达尔文的「谁强谁有理」的观念带入开源社区。这是有毒的文化。因为你终归也会遇到更强者。但这不意味着你必须对更强者下跪。在中国教育体系长大的学生可能已经习惯了给人分好三六九等，弱者服从强者的秩序。这可能也是为什么大家容易不开心：因为赞美和尊重太昂贵了。
程序员圈是用代码说话的世界吗？是，也不是。Larry Wall说程序员的三大美德是懒惰、急躁和傲慢。「傲慢」似乎被很多程序员欣赏。可程序员是人的子集。人所须遵守的社会约束，程序员依然要遵守。换句话说，在用代码说话的同时，不要忘记了我们还是社会中的人。
换个角度思考，若你在社交平台上发布了一个自己学钢琴的视频，下面有人评价「你弹得跟shit一样」。这就是一种「冒犯」。各位朋友或许已经习惯了这种有毒的氛围——但这不意味着他合理。你总有一次会成为某方面的弱者。在计算机领域的强者，亦可以是排球的弱者、K-pop的弱者。但弱者无罪，自信有理。不要吝啬您的赞美，不要吝啬您的赞美，你不会损失什么。赞美他人世界上只会多一个快乐的人，何乐而不为呢？不要做一个太mean的人。
纵使Linus也只是对它不喜欢的PR开骂，而不是直接提个issue贴脸输出。但他也因此受到批评。你所做的事情实际上并不比Linus好多少。受到批评完全是合理的——不过也请各位不要过于情绪化。切勿上升到人身攻击的地步。违反 GitHub Community Guidelines 将会被GitHub封禁。珍惜你的账号。
开源者们所能在物质上获得的回报甚少，几乎是在免费地为全世界工作。我印象很深的是之前在翻sled的issue的时候，有个人提了个issue https://github.com/spacejam/sled/issues/950。我当时深受感动。我可以想象到spacejam当时有多开心。这恐怕便是开源者最幸福的时刻吧...... maintainer或许现在还不是一位出色的开源者——因此我们有权针对代码做批评——但请以温和的方式。不要伤了任何人的心。似乎很多「理科生」都不太会说话。若您在发言之前先交给ChatGPT去润色，矛盾恐怕会减少不少（just kidding😒）。这场争吵实际上还是沟通方式的问题。不管怎样，我期待各位未来能成为优秀的开源者，遂贡献社区，贡献世界。
整个事情的辩驳到此为止了。你可以对maintainer的过度营销不满。但请不要上升到任何人身攻击。issue不是这么用的。拜托。
lexoooooo
commented
5 months ago 以及诸位高三生高考加油！祝各位都能考入自己理想的大学！
LUO12826
commented
5 months ago @LUO12826 Bylx666的道歉
为什么你如此在意他的措辞？语言只是交流工具，真正重要的是说的东西而不是怎么说。
你一直提”言语暴力“，然而”语言暴力是使用谩骂、诋毁、蔑视、嘲笑等侮辱歧视性的语言，致使他人在精神上和心理上遭到侵犯和损害“。这段话是从华南师范大学心理咨询中心找到的。请你告诉我，他的话是”谩骂、诋毁、蔑视、嘲笑等侮辱歧视性的语言“吗？
@Bylx666 已经意识到他的错误并且道歉，而你又对他的措辞提出意见（并且很可能导致了他的病情加重），我是否能说你在”言语暴力“？毕竟”学会说话，学会尊重“就是在侮辱他不会说话呢。
朋友你是不是搞错了什么？Bylx666是key-lang的开发者，不是本issue的楼主。开这个issue的是异月（的新号），也就是现在ghost了的这位。Bylx666是道歉了，但我没看见楼主的道歉。
哦对，我不认为Bylx666这位的处理方式是没问题的，只是我的评论里主要在讨论异月的行为。我想讨论的和代码质量差、不接受（极其不友善的）建议没什么关系。或者简单来说，公司里屎山代码多了去，但你要是第一个对别人喷脸说“你的代码是垃圾”，那只会被开除。我关注的是后面这点。
当然要在意措辞，我一开始就说了，即使背后的意图是好的，也不能为言语上的伤害开脱。我们没法约束人心，只能通过约束言语来尽量维护和谐。你，我，社区皆受这样的共识的保护，要不然你也不想活在污言秽语中吧？楼上 @lexoooooo 的解释很好，你可以读一读。
当然，你也可以认为我的话是暴力，是不妥的。但凡事有因果，总不能在对他人恶言恶语后，还期待他人（维护者，评论者或是其它）非常正面的回应，对吧。这点我完全可以道歉，我更愿把重点放到“好的意图也不能为言语上的伤害开脱”上。
回头看了下，太远的不想回了，但有两处有点乐的地方：
我把这句话还给你：”不要以为每个人都和你一样“。你可以忍受有人对这种东西大肆夸赞，然而不是每个人都可以忍受的。
我当然是认同这句话的啊喂！ 这里的上下文是你问我“难道你可以冷静地提出建议么？”，潜在的意思是觉得大家都会选择这样的方式。我是在说会有人能选择更温和的方式。
”is just moderately describe the issue of the code“？对不起，虽然我不懂rust,但是如果指针满天飞的话还不如用c++或者c，这样rust的优势完全没有体现出来。
你有读懂这句话及其上下文么？这里不是在说代码的问题是轻微的，我是引用了另一个人的话，TA认为原始issue的标题“这是我见过的最垃圾的代码” 这句话 is just moderately describe the issue of the code （只是在平和地描述代码中的问题）。
这个issue已经有些长得没必要了，我可能之后不会再看了。朋友们祝好，高三同学加油
FrankHB
commented
5 months ago 这件事情实际上并没有太多争议。您有权利去喜欢或不喜欢一样事情，这是您的自由。但您无权用言语伤害/攻击别人。这违反了Code of conduct。也在伤害我们的社区。
纵使代码质量不高，把这个项目开源出来就是在贡献社区。写一篇issue来骂maintainer写的代码真烂。这对社区无益。请不要随便把跟项目无关的东西放到issue来。你可以说「世界上没有理性的人」。但这并不能合理化你的行为。因为你在做错误的事情。人不是动物，忤逆情绪的本能是我们人的高等智慧的体现之一。
以及，你的沟通方式明显存在问题。你说你在14岁就实现了一个更好的编译器。那么你很棒很厉害，我佩服你。也许maintainer的代码水平并不如你。但实际上，纵使你在代码水平强过别人。你也依然必须对他人保持尊重。请不要把社会达尔文的「谁强谁有理」的观念带入开源社区。这是有毒的文化。因为你终归也会遇到更强者。但这不意味着你必须对更强者下跪。在中国教育体系长大的学生可能已经习惯了给人分好三六九等，弱者服从强者的秩序。这可能也是为什么大家容易不开心：因为赞美和尊重太昂贵了。
程序员圈是用代码说话的世界吗？是，也不是。Larry Wall说程序员的三大美德是懒惰、急躁和傲慢。「傲慢」似乎被很多程序员欣赏。可程序员是人的子集。人所须遵守的社会约束，程序员依然要遵守。换句话说，在用代码说话的同时，不要忘记了我们还是社会中的人。
换个角度思考，若你在社交平台上发布了一个自己学钢琴的视频，下面有人评价「你弹得跟shit一样」。这就是一种「冒犯」。各位朋友或许已经习惯了这种有毒的氛围——但这不意味着他合理。你总有一次会成为某方面的弱者。在计算机领域的强者，亦可以是排球的弱者、K-pop的弱者。但弱者无罪，自信有理。不要吝啬您的赞美，不要吝啬您的赞美，你不会损失什么。赞美他人世界上只会多一个快乐的人，何乐而不为呢？不要做一个太mean的人。
纵使Linus也只是对它不喜欢的PR开骂，而不是直接提个issue贴脸输出。但他也因此受到批评。你所做的事情实际上并不比Linus好多少。受到批评完全是合理的——不过也请各位不要过于情绪化。切勿上升到人身攻击的地步。违反 GitHub Community Guidelines 将会被GitHub封禁。珍惜你的账号。
开源者们所能在物质上获得的回报甚少，几乎是在免费地为全世界工作。我印象很深的是之前在翻sled的issue的时候，有个人提了个issue spacejam/sled#950。我当时深受感动。我可以想象到spacejam当时有多开心。这恐怕便是开源者最幸福的时刻吧...... maintainer或许现在还不是一位出色的开源者——因此我们有权针对代码做批评——但请以温和的方式。不要伤了任何人的心。似乎很多「理科生」都不太会说话。若您在发言之前先交给ChatGPT去润色，矛盾恐怕会减少不少（just kidding😒）。这场争吵实际上还是沟通方式的问题。不管怎样，我期待各位未来能成为优秀的开源者，遂贡献社区，贡献世界。
整个事情的辩驳到此为止了。你可以对maintainer的过度营销不满。但请不要上升到任何人身攻击。issue不是这么用的。拜托。
虽然和这里讨论的问题没有直接关系，我不得不提醒你，你无权用私相授受的条款约束不特定和你之间没有法律上的义务遵循这些条款作为共识的其他人；而滥用这些实质上只有免责而无法落实公众监督的不对等格式条款，即便在法律上不是全然无效，至少在伦理上是存疑的（特别是对比一些强化职业道德的、需要签署批准或同意的那些行为准则文件中往往会更注意详细约定的对等权利义务）。同样地，不限于你，这些条款的作者等人也没有权利在任意地点随意约束没有签署条款的其他人。
退一步讲，即便不考虑内容效力，仅从范围的规范，你能引用的默认共识，也就是 GitHub Community Guidelines 之类的文件（因为这里是 GitHub ，知晓(acknowledgement) 这部分约定是有效使用 GitHub 服务的事实前提）；而要考虑内容效力，具有规范性的就需要是基本等同 gitHub ToS 的条款了（这是有权使用 GitHub 服务的前提）。但同样地，对此你能做的最终只是建议其他方面的行动；这部分是 GitHub 官方才有权强制的，GitHub 没有授权你超越其他用户的、任意解释他们的文档含义和适用性的权利。
在技术上，负责强制这些条款落实的治理者的水平也值得存疑。作为对比，Linux CoC 被提出和签署，首先是约束签署者本人的行为，向社区的不特定参与者作出限制行使权利的承诺而保护他们的利益。我没有在你给出的条款中看出能与之相比的公益性让你把它作为前提；他们反而在弱化内部既有的特权者的义务。
我要说这些是因为 Rust moderation team 对此条款的滥用已经损害了我的现实工作；他们无法取信于我表明遵照条款自身恰当地完成了职责，更不用说所有基于 Contributor Covenant 模板的草台条款引起的这些固有缺陷了。作为有伤害自身在内的社区的多次前科的组织，我需要完成的仅仅是一些程序。正式的行动会在晚些时候展开；但这不妨碍我对破坏更普遍的社区的行径的公开谴责。
这些恰好就是我提过的德不配位的例子；所以，姑且不算完全跑题。
liushengqi000
commented
3 months ago 发布者对自己的开源项目有绝对的话语权，意见不合的话一般不是fork么。为什么要在别人拉黑你之后还要开小号来恶心彼此呢。你可以改良出一个更好的keylang，用更多的星来说话，而不是在issue里争执。
lexoooooo
commented
3 months ago 这件事情实际上并没有太多争议。您有权利去喜欢或不喜欢一样事情，这是您的自由。但您无权用言语伤害/攻击别人。这违反了Code of conduct。也在伤害我们的社区。 纵使代码质量不高，把这个项目开源出来就是在贡献社区。写一篇issue来骂maintainer写的代码真烂。这对社区无益。请不要随便把跟项目无关的东西放到issue来。你可以说「世界上没有理性的人」。但这并不能合理化你的行为。因为你在做错误的事情。人不是动物，忤逆情绪的本能是我们人的高等智慧的体现之一。 以及，你的沟通方式明显存在问题。你说你在14岁就实现了一个更好的编译器。那么你很棒很厉害，我佩服你。也许maintainer的代码水平并不如你。但实际上，纵使你在代码水平强过别人。你也依然必须对他人保持尊重。请不要把社会达尔文的「谁强谁有理」的观念带入开源社区。这是有毒的文化。因为你终归也会遇到更强者。但这不意味着你必须对更强者下跪。在中国教育体系长大的学生可能已经习惯了给人分好三六九等，弱者服从强者的秩序。这可能也是为什么大家容易不开心：因为赞美和尊重太昂贵了。 程序员圈是用代码说话的世界吗？是，也不是。Larry Wall说程序员的三大美德是懒惰、急躁和傲慢。「傲慢」似乎被很多程序员欣赏。可程序员是人的子集。人所须遵守的社会约束，程序员依然要遵守。换句话说，在用代码说话的同时，不要忘记了我们还是社会中的人。 换个角度思考，若你在社交平台上发布了一个自己学钢琴的视频，下面有人评价「你弹得跟shit一样」。这就是一种「冒犯」。各位朋友或许已经习惯了这种有毒的氛围——但这不意味着他合理。你总有一次会成为某方面的弱者。在计算机领域的强者，亦可以是排球的弱者、K-pop的弱者。但弱者无罪，自信有理。不要吝啬您的赞美，不要吝啬您的赞美，你不会损失什么。赞美他人世界上只会多一个快乐的人，何乐而不为呢？不要做一个太mean的人。 纵使Linus也只是对它不喜欢的PR开骂，而不是直接提个issue贴脸输出。但他也因此受到批评。你所做的事情实际上并不比Linus好多少。受到批评完全是合理的——不过也请各位不要过于情绪化。切勿上升到人身攻击的地步。违反 GitHub Community Guidelines 将会被GitHub封禁。珍惜你的账号。 开源者们所能在物质上获得的回报甚少，几乎是在免费地为全世界工作。我印象很深的是之前在翻sled的issue的时候，有个人提了个issue spacejam/sled#950。我当时深受感动。我可以想象到spacejam当时有多开心。这恐怕便是开源者最幸福的时刻吧...... maintainer或许现在还不是一位出色的开源者——因此我们有权针对代码做批评——但请以温和的方式。不要伤了任何人的心。似乎很多「理科生」都不太会说话。若您在发言之前先交给ChatGPT去润色，矛盾恐怕会减少不少（just kidding😒）。这场争吵实际上还是沟通方式的问题。不管怎样，我期待各位未来能成为优秀的开源者，遂贡献社区，贡献世界。 整个事情的辩驳到此为止了。你可以对maintainer的过度营销不满。但请不要上升到任何人身攻击。issue不是这么用的。拜托。
虽然和这里讨论的问题没有直接关系，我不得不提醒你，你无权用私相授受的条款约束不特定和你之间没有法律上的义务遵循这些条款作为共识的其他人；而滥用这些实质上只有免责而无法落实公众监督的不对等格式条款，即便在法律上不是全然无效，至少在伦理上是存疑的（特别是对比一些强化职业道德的、需要_签署批准或同意_的那些行为准则文件中往往会更注意详细约定的对等权利义务）。同样地，不限于你，这些条款的作者等人也没有权利在任意地点随意约束没有签署条款的其他人。
退一步讲，即便不考虑内容效力，仅从范围的规范，你能引用的默认共识，也就是 GitHub Community Guidelines 之类的文件（因为这里是 GitHub ，知晓(acknowledgement) 这部分约定是有效使用 GitHub 服务的事实前提）；而要考虑内容效力，具有规范性的就需要是基本等同 gitHub ToS 的条款了（这是有权使用 GitHub 服务的前提）。但同样地，对此你能做的最终只是建议其他方面的行动；这部分是 GitHub 官方才有权强制的，GitHub 没有授权你超越其他用户的、任意解释他们的文档含义和适用性的权利。
在技术上，负责强制这些条款落实的治理者的水平也值得存疑。作为对比，Linux CoC 被提出和签署，首先是约束签署者本人的行为，向社区的不特定参与者作出_限制行使权利_的承诺而保护他们的利益。我没有在你给出的条款中看出能与之相比的公益性让你把它作为前提；他们反而在弱化内部既有的特权者的义务。
我要说这些是因为 Rust moderation team 对此条款的滥用已经损害了我的现实工作；他们无法取信于我表明遵照条款自身恰当地完成了职责，更不用说所有基于 Contributor Covenant 模板的草台条款引起的这些固有缺陷了。作为有伤害自身在内的社区的多次前科的组织，我需要完成的仅仅是一些程序。正式的行动会在晚些时候展开；但这不妨碍我对破坏更普遍的社区的行径的公开谴责。
这些恰好就是我提过的德不配位的例子；所以，姑且不算完全跑题。
这件事情实际上并没有太多争议。您有权利去喜欢或不喜欢一样事情，这是您的自由。但您无权用言语伤害/攻击别人。
「您有权利去喜欢或不喜欢一样事情，这是您的自由。但您无权用言语伤害/攻击别人。」 这句话我不觉得在道德上有什么错误。所以一旦看到这种行为，我就会反对。实际上 「无权用言语伤害/攻击别人」 也是包含在GitHub的ToS的。而这个人身攻击的人也的确被GitHub封号了。至于我有没有权利在他被封前去批评这个被封的人，当然有，这是我的言论自由。不需要谁授权我。我没有对着他骂，也没有持续骚扰他，更没有用一个脏字。这就是我的批评自由。
至于「德不配位」嘛...你当然可以按照你心里的尺子去衡量去批评。但是 「无权用言语伤害/攻击别人」 在我看来已经是人类的默认道德共识了...我心里也觉得他在「过度营销」「德不配位」，但是我觉得无论如何跑到项目下面来骂太过分了。
至于「约束」，能真真切切约束人的其实不应该只有法律。道德同样也是。人们通过「德不配位」约束他。同样，「不能用言语伤害别人」也在约束每一个人。如果真的只是在邮件里，在其他地方友好的批评，那我觉得就只是在行使自己的自由。但是如果跑到项目作者的项目下面骂「这是我读过的最垃圾的代码，没有之一」「不建议使用Rust」，被删了被封了还要接着argue。我觉得这完全就是「用言语伤害」。做人要做得这么刻薄吗？没必要吧。
FrankHB
commented
2 months ago 这件事情实际上并没有太多争议。您有权利去喜欢或不喜欢一样事情，这是您的自由。但您无权用言语伤害/攻击别人。这违反了Code of conduct。也在伤害我们的社区。 纵使代码质量不高，把这个项目开源出来就是在贡献社区。写一篇issue来骂maintainer写的代码真烂。这对社区无益。请不要随便把跟项目无关的东西放到issue来。你可以说「世界上没有理性的人」。但这并不能合理化你的行为。因为你在做错误的事情。人不是动物，忤逆情绪的本能是我们人的高等智慧的体现之一。 以及，你的沟通方式明显存在问题。你说你在14岁就实现了一个更好的编译器。那么你很棒很厉害，我佩服你。也许maintainer的代码水平并不如你。但实际上，纵使你在代码水平强过别人。你也依然必须对他人保持尊重。请不要把社会达尔文的「谁强谁有理」的观念带入开源社区。这是有毒的文化。因为你终归也会遇到更强者。但这不意味着你必须对更强者下跪。在中国教育体系长大的学生可能已经习惯了给人分好三六九等，弱者服从强者的秩序。这可能也是为什么大家容易不开心：因为赞美和尊重太昂贵了。 程序员圈是用代码说话的世界吗？是，也不是。Larry Wall说程序员的三大美德是懒惰、急躁和傲慢。「傲慢」似乎被很多程序员欣赏。可程序员是人的子集。人所须遵守的社会约束，程序员依然要遵守。换句话说，在用代码说话的同时，不要忘记了我们还是社会中的人。 换个角度思考，若你在社交平台上发布了一个自己学钢琴的视频，下面有人评价「你弹得跟shit一样」。这就是一种「冒犯」。各位朋友或许已经习惯了这种有毒的氛围——但这不意味着他合理。你总有一次会成为某方面的弱者。在计算机领域的强者，亦可以是排球的弱者、K-pop的弱者。但弱者无罪，自信有理。不要吝啬您的赞美，不要吝啬您的赞美，你不会损失什么。赞美他人世界上只会多一个快乐的人，何乐而不为呢？不要做一个太mean的人。 纵使Linus也只是对它不喜欢的PR开骂，而不是直接提个issue贴脸输出。但他也因此受到批评。你所做的事情实际上并不比Linus好多少。受到批评完全是合理的——不过也请各位不要过于情绪化。切勿上升到人身攻击的地步。违反 GitHub Community Guidelines 将会被GitHub封禁。珍惜你的账号。 开源者们所能在物质上获得的回报甚少，几乎是在免费地为全世界工作。我印象很深的是之前在翻sled的issue的时候，有个人提了个issue spacejam/sled#950。我当时深受感动。我可以想象到spacejam当时有多开心。这恐怕便是开源者最幸福的时刻吧...... maintainer或许现在还不是一位出色的开源者——因此我们有权针对代码做批评——但请以温和的方式。不要伤了任何人的心。似乎很多「理科生」都不太会说话。若您在发言之前先交给ChatGPT去润色，矛盾恐怕会减少不少（just kidding😒）。这场争吵实际上还是沟通方式的问题。不管怎样，我期待各位未来能成为优秀的开源者，遂贡献社区，贡献世界。 整个事情的辩驳到此为止了。你可以对maintainer的过度营销不满。但请不要上升到任何人身攻击。issue不是这么用的。拜托。
虽然和这里讨论的问题没有直接关系，我不得不提醒你，你无权用私相授受的条款约束不特定和你之间没有法律上的义务遵循这些条款作为共识的其他人；而滥用这些实质上只有免责而无法落实公众监督的不对等格式条款，即便在法律上不是全然无效，至少在伦理上是存疑的（特别是对比一些强化职业道德的、需要_签署批准或同意_的那些行为准则文件中往往会更注意详细约定的对等权利义务）。同样地，不限于你，这些条款的作者等人也没有权利在任意地点随意约束没有签署条款的其他人。 退一步讲，即便不考虑内容效力，仅从范围的规范，你能引用的默认共识，也就是 GitHub Community Guidelines 之类的文件（因为这里是 GitHub ，知晓(acknowledgement) 这部分约定是有效使用 GitHub 服务的事实前提）；而要考虑内容效力，具有规范性的就需要是基本等同 gitHub ToS 的条款了（这是有权使用 GitHub 服务的前提）。但同样地，对此你能做的最终只是建议其他方面的行动；这部分是 GitHub 官方才有权强制的，GitHub 没有授权你超越其他用户的、任意解释他们的文档含义和适用性的权利。 在技术上，负责强制这些条款落实的治理者的水平也值得存疑。作为对比，Linux CoC 被提出和签署，首先是约束签署者本人的行为，向社区的不特定参与者作出_限制行使权利_的承诺而保护他们的利益。我没有在你给出的条款中看出能与之相比的公益性让你把它作为前提；他们反而在弱化内部既有的特权者的义务。 我要说这些是因为 Rust moderation team 对此条款的滥用已经损害了我的现实工作；他们无法取信于我表明遵照条款自身恰当地完成了职责，更不用说所有基于 Contributor Covenant 模板的草台条款引起的这些固有缺陷了。作为有伤害自身在内的社区的多次前科的组织，我需要完成的仅仅是一些程序。正式的行动会在晚些时候展开；但这不妨碍我对破坏更普遍的社区的行径的公开谴责。 这些恰好就是我提过的德不配位的例子；所以，姑且不算完全跑题。
这件事情实际上并没有太多争议。您有权利去喜欢或不喜欢一样事情，这是您的自由。但您无权用言语伤害/攻击别人。
「您有权利去喜欢或不喜欢一样事情，这是您的自由。但您无权用言语伤害/攻击别人。」 这句话我不觉得在道德上有什么错误。所以一旦看到这种行为，我就会反对。实际上 「无权用言语伤害/攻击别人」 也是包含在GitHub的ToS的。而这个人身攻击的人也的确被GitHub封号了。至于我有没有权利在他被封前去批评这个被封的人，当然有，这是我的言论自由。不需要谁授权我。我没有对着他骂，也没有持续骚扰他，更没有用一个脏字。这就是我的批评自由。
至于「德不配位」嘛...你当然可以按照你心里的尺子去衡量去批评。但是 「无权用言语伤害/攻击别人」 在我看来已经是人类的默认道德共识了...我心里也觉得他在「过度营销」「德不配位」，但是我觉得无论如何跑到项目下面来骂太过分了。
至于「约束」，能真真切切约束人的其实不应该只有法律。道德同样也是。人们通过「德不配位」约束他。同样，「不能用言语伤害别人」也在约束每一个人。如果真的只是在邮件里，在其他地方友好的批评，那我觉得就只是在行使自己的自由。但是如果跑到项目作者的项目下面骂「这是我读过的最垃圾的代码，没有之一」「不建议使用Rust」，被删了被封了还要接着argue。我觉得这完全就是「用言语伤害」。做人要做得这么刻薄吗？没必要吧。
权利自始自终是个法律概念，如果不是政治概念的话。道德权利或者习惯权利的法理依据是自然法，但接受何种自然法在伦理上是更基础的信仰自由问题。如果非要架空这种伦理接受性而找到共识，那就是不以人为转移的客观规律——比如物理定律；但你若说你接受权利的合理性来自物理定律的允许，那不妨直接架空所有伦理了，也没有法律更没有道德存在的必要，因为很明显底线是顺次提升的。
所以说，有没有权利，这是一个更该有共识的问题。用法律这种比道德更接近底线的理由是争取更大程度的规范性共识，而跟是否是常识无关。若都提起道德，你说你这应当是共识，但我说不算，那最后谁说了算，按闹分配？这就事实上不可行。我姑且乐观估计，GitHub 的用户群体应当不至于理解不了这些实际障碍的存在，而非得用常识性的多寡来降低自律的难度。——注意，一旦追求“约束人”的效果能足够可靠地重现，道德也整个地原则上天然地只堪自律，不配他律。
而诉诸法律自然应当面对程序合法问题，自然也包括依据的形式审查，例如主体符合性和依据的效力。引用 GitHub ToS 的理由其一，GitHub 这个主体就是社区中公认的特权者（不同意的连使用 GitHub 的资格都没有），能强制打成最低限度的共识；其二，它是能合法地实现对 GitHub 用户的不当行为最严厉的特定制裁的最终依据——比如让用户账户人间蒸发和阻碍发言——不管这位用户如何坚持言论自由之类的正当性。所有社区自治性质的互动，若没有 GitHub 权限的背书，在 GitHub 内的制裁效果都是次要的，类似公权和私权的悬殊。因此 GitHub 意见如何在此首当其冲地值得一提。对事实依据的审查也有为其服务的意味。很遗憾，你所谓的"实际上 「无权用言语伤害/攻击别人」 也是包含在GitHub的ToS的"并非事实，因为真正的 ToS 明确是另一个文档，这个文档中正好符合预期地充满了 legal code 的冗长臭味，而你给的文档只是个试图教会用户做事说明性文件，甚至不如社区行为规范能体现 GitHub 的态度。
在这种底线思维下，判断有或者没有权利自然不会使用你的逻辑。反对私相授受却对非特定公众造成影响的约定，是一种最起码的形式正确，甚至是更广泛意义的政治正确（法治>人治；若你不同意当事人具有足够的实践经验，至少也还有法制>人治）。用道德理由反对或批判，因为缺乏可比的信服的前提，是软弱无力的。
这点和道德在强制力下弱于法律一致，并非偶然——还是因为实际操作的原因。对 GitHub 这样的社区，援引规则的目的是为了以自治为主的社区治理，GitHub ToS 已经是属于对不熟悉各个自治区域的常规约定的兜底条款了，才需要有与之配位的强制性。反观你所谓的“无权用言语伤害/攻击别人”并非社区处理的特化版本，不说强制力需要你这样看似有理实则漏洞百出的苦口婆心，即便用于日常生活内涵都不甚完善，甚至还可能引起争端——为什么“以牙还牙，以眼还眼”，就不能至少同等地在道德上正当，难道就因为你说的就是道德制高点？而刑法上也有正当防卫的概念。这些规则的重要共同点是为了维护遵守规则的涉众的利益，包括在共识不够时消除争端带来的破坏。你的主张不够占据基础必要的地位，又无法避免实际操作的问题，是注定被妥协的。
至于遵守规则预先需要付出的代价，那又是另一回事。法律可不会因为被管辖的用户不理解法律而失效，ToS 同理——一旦用上了，就没理由辩驳不懂而免责，违反规则就需要承担相应的后果。这也是可操作性的另一个主要来源。反观你的主张，排除 coverage 上的 bug ，最大的不同其实也就是这个豁免，“降低学习的门槛”以换取容易被接受。但这种行径反而正削弱了成文规则的作用，损害了行之有效的规则体系的价值。道理也简单——你不做制定规则、一碗水端平利益分配、消除分歧这些更烧脑的工作也罢了（毕竟你也没得到匹配的权力），但连理解规则的起码道德义务都尽不到，光享受社区治理的成果却拿自己的事实上不大顶用的观念来挖墙脚，这合理么？即便不存在那么强制力的场合也有类似的例子，比如 RTFM 文化。如果手册是用来被无视的，每次非要浪费维护人员的时间教育 n00b ，那是无差别消解所有维护手册的贡献者的价值；无非是没有强制力条款背书的场合，不那么容易让无视规则者付出代价而已，多数直接无视。
这里所谓的德不配位的德的主要部分，也就是对规则的理解和遵守。这不是单指普通用户，而是所有社区活动的参与者。因此，这理应也包括权限汪的滥权的反制以确保这些行为至少不能被视为常规。社区行为规范的内容往往不如正式签订的行业法律文件（一般用于规范职业道德的具体内容，避免违规者以不懂为由逃离制裁），但显然也可以通过补充规则来限制。钻空子滥权和规则打击的行为很大程度上是类似的，都具有削弱共识传导和拆散组织的严重破坏性。不完善的规则体系无法确保约束的情况下，这些行为诉诸为道德上的缺陷，这已经是对一些参与者无能维护社区价值的一种讽刺了。
如果你仅仅是停留在我表达的是喜欢/不喜欢，那我只能对你的理解能力感到遗憾。
这个 issue不是针对这个key lang，而是针对一场争端
在你发表任何你的意见之前，请先尽可能多地了解事件的经过。不过，如果你是鲁迅笔下的“那些人”…我就没什么好说的了。
总览
事件经过
为什么出视频
为何如此痛恨控评
为何还要继续下去
因为我已经被 @Bylx666 封禁，故不能使用这个账户提出issue
事件经过
在这里我先比较完整地叙述一下事件经过，以免使得各位对事件经过和内容产生不必要的误解。
最开始我在B站刷到了key lang的视频，听完他干巴巴讲半天，没看到一行key代码，我也没有多关注这个（不过还是记下来了）。
因为他提了一嘴，我就抱着学习的想法去看了一下Key的源代码。
他的网页，他的视频…以及视频下被他挑选过的评论区，全是对作者，对key lang的表扬，赞美。
可是他华丽的网页之下所呈现的主体，key lang，它的源代码却是混乱不堪粗糙无比。就事论事，他的源代码质量真的很差…差在哪里我不会再重复了，这是不争的事实。
然后我就提交了一个issue，也就是#10。
之后我发现他的代码不止没有通过clippy，还没有格式化，就在clippy后加上了rustfmt。
我并没有在#10中指出更多的问题，因为我在对#10进行第一次修改之后就在帮他修复代码中的warn，提交pr，也就是#11。
写pr，读代码的过程中着实被他的代码恶心到了，我就修改了#10，加上了“这是我读过的最垃圾的代码，没有之一”，同时修改标题为“不建议使用rust”，也就形成个各位第一次看到的版本。
之后我收到了作者的回复…只能说他完全就没有去了解我的issue指出了什么，提出了什么建议。他只抓到我说他的很代码质量很差，于是就
评价我的行为：不过脑子
对于我的行为：不多评价
这就是作者对于提出建议的人的态度？
因为某些原因，我的情绪很不稳定，很快就写出了非常具有攻击性，充满阴阳怪气的#12。确实，#12语气很恶劣，但是这并不体现我对作者的尊重程度，而是作者对我的尊重程度。
那么他是怎么回应的呢?
对于我的PR，他说：“说到底你所谓的"优化"或许只是你的一厢情愿罢了”
对于我的态度，他说：“一丝不挂地表达出自己的优越, 我认可你的勇气.”
在内容上，在#12我额外指出了代码中的各问题，比如
滥用static mut：他说：“滥用”static mut同样是我自己的选择.
使用指针代替引用：他说：“用Rust贴近汇编的思维方式并不可耻”，“懒得写生命周期”,
没有CI测试验证代码是否内存安全：他没有看，直接忽略了这一条
他还说：“我不会关闭该issue”。但是接下来他做了什么呢？ closed this as completed
接下来我提交了#15，和这个issue一样并不面向于作者，而是面向于其他看到这个项目的人，详细罗列了代码的问题
这次他是这样回复的: “我欢迎你无限攻击我, 也欢迎所有人来观看新世纪人类行为鉴赏. 毕竟这个仓库已经没人来看了, 也没人来开发, 我就把该issue保持open状态. 你一定还会回复或添加新issue继续攻击我, 我对你表示欢迎态度.”
这次他又说保持open状态。确实，这个issue直到被delete前一刻，都是open的。而他对我的“攻击”的欢迎态度是，让我无法再对这个项目添加issue或者回复信息。我也是第一次知道github可以拉黑某个人。
对于他删除我issue的原因，我认为作者认为只有哦对他提出意见。意思就是说所有提出意见的人全都是我的小号。于是，我在github多了一堆“小号”，在B站又多了一堆“小号”。
既然他在github上传了源代码，既然他为他的项目出视频宣传，那就不会只有我一个人看到他的源代码，对他的源代码提出意见
他对一群我以前不认，他们也不认识我的人，说了些什么？
我知道你是异月的小号，你一定会开各种小号来无限攻击我的，为了避免后续，我会把你的账号拉黑屏蔽，希望你好自为之
(reopen#12)把话说干净就好了，我只是看不惯他的语气
我看得出你的态度有所悔改(close#12)
我相信你, 真的相信你, 但我真的很想笑而已, 自顾自笑一下而已, 别在意我哈哈哈哈
我就不更多列举了
之后，我搜集了一些信息，就制作了视频
为什么要出视频
其实，到目前为止的所有，我就觉得没什么。他代码写的不行啊，不听建议啊，态度恶劣啊，都没什么。但是他做出了一件值得让我花大量时间去制作一期视频的事，花费大量时间写这个issue补充细节的事。
控评
他的bilibili视频下的评论区，非常干净，几乎全是赞美，很明显嘛，他有在精心维护评论区，对于他不喜欢的他可以删除，或者举报。
甚至我的视频下的评论区，他都要用举报帮我管理，他怎么这么好
而github，更是简单的很。怎么说，这位作者也是很高明的，掐头去尾只开放#12，#10没人知道，#15已经删掉。评论里认个错，诶，他就是对的了。
不合心意的评论，删。不和心意的issue，删。
我呢，因为#12里恶劣的语气啊，现在已经github都无法正常使用，被标记了呢。所以现在#10到#12都是无法打开的状态。
好像舆论的风向已经导向了他，毕竟这是他的地盘，他可以随意控制这里的言论的。
我承认我语气恶劣，我认为这来自于看见他过度包装的项目内里却无比腐败的反差。
为何如此痛恨控评
去查找，分析一场事件的全过程，是很麻烦的，往往也少有人愿意这样做。所以，在可以被看到的地方发布的信息，就可以作为评判事件的根据…吗？
可以被看到的信息，是可以被引导的。而控评，就是起这个作用。
以上的故事可以当做我编的，随便说说而已
为何还要继续下去
我的视频很好地起到了引流的作用…也让很多人参与进来了，最后结果到底怎么样，我也不是很在乎吧，大不了空中飞人。但是我觉得让不明经过的各位了解一下过程，还是有必要的。