程序员必知必会之maillist篇
       本文最初由恋花蝶发表于http://blog.csdn.net/lanphaday,可以随意转载,但未经同意不得增删修改,转载应保留本声明,否则追究责任。
题注:因为我参与了若干个maillist,眼看一个一个maillist变成毫无学术氛围的“小水塘”,心如刀割,所以写下了这篇文字,忠诚劝戒大家善待maillist、尊重maillist上的每一位订阅者,共同营造和谐的网络交流环境。
maillist,即邮件列表,金山词霸2005上面的意思是邮件发送清单。maillist可能是互联网上最古老的人际交流手段之一,但到现在仍然是最有效的互联网交流手段之一。
maillist不比直接的人与人之间的email交流,发往maillist的邮件会分发到订阅了maillist的所有人的邮箱,这一特性使得交流的效率相当高。试想想,如果一个论坛有一万人注册用户,可能只要一千人会经常上线,你发一个贴子,去查看的可能不到一百人,回答问题的,恐怕就只有三五个了。而一个有几百个订阅者的maillist,一个“有趣”的主题可能引起几十封回复。正因为maillist的交流的高效性,使得maillist广泛应用在学校、企业、非营利组织和一些成员分布区域广阔的行业进行交流的必然选择。在大学的时候,我们可以订阅学校的maillist;在公司的时候,我们通常被要求加入maillist;作为程序员,我们肯定订阅了不同的maillist以丰富我们的学习环境;我们也可能参与了某开源项目,所以我们可能订阅了不少开源项目的maillist。这一系列maillist,是我们获得帮助和帮助别人的纽带,所以我们有必要来学习一下应该如何对待maillist和maillist上面的朋友。
尽管中国人号称中国是礼仪之邦,但我们中的确有相当多人连最基本的礼貌也不懂。怎么样写一封让人看起来不讨厌的Email,我已经在《程序员必知必会之Email篇》(http://blog.csdn.net/lanphaday/archive/2006/06/29/850059.aspx)里跟大家探讨过,里面的内容基本上也适用于maillist,所以不再赘述。现在我们来谈一些针对maillit的话题。
不发言是最好的
因为发往maillist的邮件会被所有订阅者收到,所以如果不是在其它地方找不到答案,不要在maillist发言。Email是程序员相当重要的联系方式,对若干人而言,收到Email就是意味着要阅读(甚至回复邮件)。想像一下你回家听到电话留言里十个有八个是推销家庭用品的广告是什么样的心情,而maillist充斥着大量的低品质话题给人的感觉就差不多,这会导致maillist的订阅者激情减退,甚至流失高手,久而久之,越来越多的问题得不到解决,这个maillist也就被大家温柔地轮奸至死了。
maillst是解决问题的有效手段,但绝不是唯一手段。而且由于地域差异(如订阅了世界性的maillist)等因素得到回复需要付出巨大的时间待价,所以maillist应该是备用的解决手段。我们应该优先使用咨询身边的同学、同事和老师;优先使用搜索引擎;优先在IM群组(如QQ群、MSN群和泡泡兴趣组等)上咨询在线网友;优先使用本地论坛(如直接在C++maillist问一个简单问题得到回复的时间可能远大于在CSDN论坛询问)。如果这些方案都已经试过了,而没有人能解决你的问题,现在可以尝试向maillist发言询问。
除了发言询问和回答问题外,不要在maillist里回复其它东西。如果你是询问者,在解决问题后想感谢解答人,可以私下发邮件给他,不要直接回复到maillist。更加不要在maillist里开玩笑,或者转贴你自以为有趣的小笑话、黄段子和美女图片,这样做会让大家都认为你素质相当低下。
最后一点,不要使用设置有“自动回复”功能的Email订阅maillist,也许有些“现代”maillist服务器已经可以忽略自动回复,但最好还是不要这样做。
详细描述问题
终于可以理直气壮地向maillist发邮件了,现在我们要注意的是要详细地描述问题。在继续之前,我们再来谈谈礼貌,礼貌这东西,怎么强调都不过份。在《程序员必知必会之Email篇》(http://blog.csdn.net/lanphaday/archive/2006/06/29/850059.aspx)可以找到关于Email礼仪的内容,如果你没有自信自己写的Email是有礼的,请去阅读一遍。
       本文最初由恋花蝶发表于http://blog.csdn.net/lanphaday,可以随意转载,但未经同意不得增删修改,转载应保留本声明,否则追究责任。
详细描述问题可能需要包括这三点:1)你所遇到的问题;2)你通过其它途径找到参考答案;3)如果有代码和测试用例,请提供。基本上有这些,maillist的其他订阅者已经可以帮到你。
邮件的主题也应该是问题的描述,类似“来自初学者的问题”远不如“XX功能应该如何实现”。
如果是回复者或者引发了相关的新讨论,在适当的位置引用原文,帮助阅读者理解自己的意思。
保持线索干净
maillist是一种交流环境,肯定会有人回复。我们在回复他人的问题的时候,请一定不要更改邮件线索,简单来说,就是不要更改邮件标题(通常而言,回复时自动增加的Re(也可能是R、Reply等)并不会更改线索,所以不必在意这个)。现在相当多人使用的邮件客户端可以根据线索来组织邮件,给使用者更佳的阅读体验(现在gmail这种web mail也有这样的趋势),所以我们要保持线索干净,方便他人。
不要在线索内讨论其它问题,如之前你发起了关于C++的问题,不要在解决之后又回复讨论“关于MySql数据库的XXX问题”,请重起一条线索。一则有利于你的问题得到解决,二则方便以后有人阅读maillist的历史问题时可以容易地找到“关于MySql数据库的XXX问题”的讨论。
关于引用,我个人建议是只引用最近的三封邮件,适时地删除引用,节省带宽。很多人喜欢全部引用,这个随个人喜好吧。
自我保护
maillist上肯定时刻都会有出现“垃圾”邮件的可能,这些“垃圾”不一定是广告邮件哦,更多的是不符合你兴趣领域的“专业”邮件或者一些你认为不值一看的低水准问题。这时候有必要进行自我保护。招术之一是使用关键词过滤,现在的web mail和邮件客户端都支持过滤;招术之二就是干脆退出maillist,有必要的时候再重新加入,这种方式虽然为人不齿,但极其有效。
至此,你应该不会再成为一发Email就被整个maillist的订阅者齐骂SB的人了,因为你与maillist的友好相处,你也将能够从maillst里获得更多的帮助,或者通过帮助他人获得更多快乐。

程序员必知必会之maillist篇相关推荐

  1. 程序员应知必会的思维模型之 18 林纳斯定律 (Linus‘s Law)

    林纳斯定律 (Linus's Law) 足够多的眼睛,就可让所有问题浮现.–Eric S. Raymond 简单地说,能够看到问题的人越多,有人解决过相关的问题或事情的可能性就越高. 最初该定律是用来 ...

  2. 程序员应知必会的思维模型之 7 邓巴数字 (Dunbar‘s Number)

    邓巴数字 (Dunbar's Number) 邓巴数字是对一个人能够保持稳定社会关系的人数的认知极限--在这种关系中,一个人知道每个人是谁,也知道每个人与其他人的关系如何.而对这一数字的确切值则有着一 ...

  3. 程序员应知必会的思维模型之 25 普特定律 (Putt‘s Law)

    普特定律 (Putt's Law) 技术由两类人主导,一类是纯粹的管理人员, 一类是纯粹的技术人员. 普特定律常常遵循普特推论: 每一个技术层次,假以时日,能力将逆转. 这些结论表明,由于各种选择标准 ...

  4. 程序员应知必会的思维模型之 19 梅特卡夫定律 (Metcalfe‘s Law)

    梅特卡夫定律 (Metcalfe's Law) 在网络理论中,系统的价值约等于系统用户数的平方. 这个定律基于一个系统中可能的连接对数量,并且与里德定律 (Reed's Law) 十分相近.奥德利兹科 ...

  5. 程序员应知必会的思维模型之 15 技术成熟度曲线 (The Hype Cycle or Amara‘s Law)

    技术成熟度曲线 (The Hype Cycle or Amara's Law) 我们倾向于过高估计技术在短期内的影响,并低估长期效应.–罗伊·阿马拉 (Roy Amara) 技术成熟度曲线是高德纳咨询 ...

  6. 程序员应知必会的思维模型之 23 帕金森定理 (Parkinson‘s Law)

    帕金森定理 (Parkinson's Law) 在工作能够完成的时限内,工作量会一直增加,直到所有可用时间都被填满为止. 基于官僚机构的研究背景,该定律被应用于软件开发中.该理论认为,团队在截止日期之 ...

  7. 程序员应知必会的思维模型之 21 墨菲定律 (Murphy‘s Law / Sod‘s Law)

    墨菲定律 (Murphy's Law / Sod's Law) 凡是可能出错的事就一定会出错 出自 爱德华·A·墨菲 , 墨菲定律 说明了如果一件事有可能出错,那么就一定会出错. 这是一句开发人员间的 ...

  8. 程序员应知必会的思维模型之 3 破窗效应 (The Broken Windows Theory)

    破窗效应 (The Broken Windows Theory) 在破窗理论中认为,一些明显的犯罪迹象(或缺乏环保意识)会导致进一步的.更严重的犯罪(或环境的进一步恶化). 软件领域应用 破窗理论已应 ...

  9. 程序员应知必会的思维模型之 12 席克定律 (Hick‘s Law or Hick-Hyman Law)

    席克定律 (Hick's Law or Hick-Hyman Law) 决策时间和可供选择的选项数量呈对数增长关系. – William Edmund Hick and Ray Hyman 解释 在下 ...

  10. 程序员应知必会的思维模型之 5 康威定律 (Conway‘s Law)

    康威定律 (Conway's Law) 这个定律说明了系统的技术边界可以反应一个组织的结构,它通常会在改进组织时被提及.康威定律表明,如果一个组织被分散成许多小而无联系的单元,那么它开发的软件也是小而 ...

最新文章

  1. cuDNN 功能模块解析
  2. HTTP协议,之入门初尝
  3. Android信使Messenger解析
  4. 插入节点insertBefore()
  5. vSAN ReadyNode™中可以(也不能)更改的内容
  6. java学习中,instanceof 关键字 和 final 关键字、值的传递(java 学习中的小记录)...
  7. 应该怎样设计和开发软件
  8. 【翻译】Brewer's CAP Theorem CAP定理
  9. 我对 SRE 的理解
  10. Flash Bootloader
  11. ADC相关参数之---INL和DNL
  12. java迅雷下载excel,Asp.net生成Excel文件并下载(更新:解决使用迅雷下载页面而不是文件的问题)...
  13. 学术届职称与凡人修仙传等级对应关系
  14. 改变虚拟导航栏(navigation bar)背景色及图标颜色
  15. js替换关键词为链接,只替换一次,要避开超链接或图片
  16. 【股票】java+js获取股票实时数据
  17. 词汇总结·《雅思词汇看这本书就够了》
  18. Ae:表达式语法基础
  19. 适用于WordPress的10个最佳白标签品牌插件
  20. 疫情环境下外卖跑腿市场,校园平台与社会主流大平台有什么区别?

热门文章

  1. php如何从左往右轮播,js实现从左向右滑动式轮播图效果
  2. mongodb集群 java_MongoDB集群JavaAPI插入数据
  3. Linux-xargs命令
  4. 学习笔记Spark(三)—— Spark架构及原理(spark架构、spark RDD)
  5. 凸透镜成像动画可拖动_经典四图八问!这道中考物理题,彻底解决凸透镜成像规律!...
  6. 三方库报错真的就没有办法了吗?
  7. Python知识:关于map
  8. 机器视觉:ransac算法详解
  9. java语言 文件上传,java中实现文件上传的方法
  10. plsql存储过程修改后怎么保存_证件照上传不成功,教你修改分辨率、调整照片大小...