DevOps 团队需要 IT 领导者关注三件事：沟通、技术债务和信任。

IT 领导者可以从大量的 DevOps 材料和 向 DevOps 转变 所要求的文化挑战中学习。但是，你在一个 DevOps 团队面对长期或短期的团结挑战的调整中 —— 一个 CIO 真正需要他们做的是什么呢？

在我与 DevOps 团队成员的谈话中，我听到的其中一些内容让你感到非常的意外。DevOps 专家（无论是内部团队的还是外部团队的）都希望将下列的事情放在你的 CIO 优先关注的级别。

1. 沟通

第一个也是最重要的一个，DevOps 专家需要面对面的沟通。一个经验丰富的 DevOps 团队是非常了解当前 DevOps 的趋势，以及成功和失败的经验，并且他们非常乐意去分享这些信息。表达 DevOps 的概念是很困难的，因此，要在这种新的工作关系中保持开放，定期（不用担心，不用每周）讨论有关你的 IT 的当前状态，如何评价你的沟通环境，以及你的整体的 IT 产业。

相反，你应该准备好与 DevOps 团队去共享当前的业务需求和目标。业务不再是独立于 IT 的东西：它们现在是驱动 IT 发展的重要因素，并且 IT 决定了你的业务需求和目标运行的效果如何。

注重参与而不是领导。在需要做决策的时候，你仍然是最终的决策者，但是，理解这些决策的最好方式是协作，这样，你的 DevOps 团队将有更多的自主权，并因此受到更多激励。

2. 降低技术债务

第二，力争更好地理解技术债务，并在 DevOps 中努力降低它。你的 DevOps 团队都工作于一线。这里，“技术债务”是指在一个庞大的、不可持续发展的环境之中，通过维护和增加新功能而占用的人力资源和基础设备资源（查看 Rube Goldberg）。

CIO 常见的问题包括：

• 为什么我们要用一种新方法去做这件事情？
• 为什么我们要在它上面花费时间和金钱？
• 如果这里没有新功能，只是现有组件实现了自动化，那么我们的收益是什么？

“如果没有坏，就不要去修理它”，这样的事情是可以理解的。但是，如果你正在路上好好的开车，而每个人都加速超过你，这时候，你的环境就被破坏了。持续投入宝贵的资源去支撑或扩张拼凑起来的环境。

选择妥协，并且一个接一个的打补丁，以这种方式去处理每个独立的问题，结果将从一开始就变得很糟糕 —— 在一个不能支撑建筑物的地基上，一层摞一层地往上堆。事实上，这种方法就像不断地在电脑中插入坏磁盘一样。迟早有一天，面对出现的问题你将会毫无办法。在外面持续增加的压力下，整个事情将变得一团糟，完全吞噬掉你的资源。

这种情况下，解决方案就是：自动化。使用自动化的结果是良好的可伸缩性 —— 每个维护人员在 IT 环境的维护和增长方面花费更少的努力。如果增加人力资源是实现业务增长的唯一办法，那么，可伸缩性就是白日做梦。

自动化降低了你的人力资源需求，并且对持续进行的 IT 提供了更灵活的需求。很简单，对吗？是的，但是你必须为迟到的满意做好心理准备。为了在提高生产力和效率的基础上获得后端经济效益，需要预先投入时间和精力对架构和结构进行变更。为了你的 DevOps 团队能够成功，接受这些挑战，对 IT 领导者来说是非常重要的。

3. 信任

最后，相信你的 DevOps 团队并且一定要理解他们。DevOps 专家也知道这个要求很难，但是他们必须得到你的强大支持和你积极参与的意愿。因为 DevOps 团队持续改进你的 IT 环境，他们自身也在不断地适应这些变化的技术，而这些变化通常正是 “你要去学习的经验”。

倾听，倾听，倾听他们，并且相信他们。DevOps 的改变是非常有价值的，而且也是值的去投入时间和金钱的。它可以提高效率、生产力、和业务响应能力。信任你的 DevOps 团队，并且给予他们更多的自由，实现更高效率的 IT 改进。

新 CIO 的底线是：将你的 DevOps 团队的潜力最大化，离开你的领导 “舒适区”，拥抱一个 “CIOps" 的转变。通过 DevOps 转变，持续地与你的 DevOps 团队共同成长，以帮助你的组织获得长期的 IT 成功。

via: https://enterprisersproject.com/article/2017/12/what-devops-teams-really-need-cio

作者：John Allessio 译者：qhwdw 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

我们又能通过开源社区做些什么？

在我们的世界里，算法无处不在，偏见也是一样。从社会媒体新闻的提供到流式媒体服务的推荐到线上购物，计算机算法，尤其是机器学习算法，已经渗透到我们日常生活的每一个角落。至于偏见，我们只需要参考 2016 年美国大选就可以知道，偏见是怎样在明处与暗处影响着我们的社会。

很难想像，我们经常忽略的一点是这二者的交集：计算机算法中存在的偏见。

与我们大多数人的认知相反，科技并不是客观的。 AI 算法和它们的决策程序是由它们的研发者塑造的，他们写入的代码，使用的“训练”数据还有他们对算法进行应力测试 的过程，都会影响这些算法今后的选择。这意味着研发者的价值观、偏见和人类缺陷都会反映在软件上。如果我只给实验室中的人脸识别算法提供白人的照片，当遇到不是白人照片时，它不会认为照片中的是人类 。这结论并不意味着 AI 是“愚蠢的”或是“天真的”，它显示的是训练数据的分布偏差：缺乏多种的脸部照片。这会引来非常严重的后果。

这样的例子并不少。全美范围内的州法院系统 都使用“黑盒”对罪犯进行宣判。由于训练数据的问题，这些算法对黑人有偏见 ，他们对黑人罪犯会选择更长的服刑期，因此监狱中的种族差异会一直存在。而这些都发生在科技的客观性伪装下，这是“科学的”选择。

美国联邦政府使用机器学习算法来计算福利性支出和各类政府补贴。但这些算法中的信息，例如它们的创造者和训练信息，都很难找到。这增加了政府工作人员进行不平等补助金分发操作的几率。

算法偏见情况还不止这些。从 Facebook 的新闻算法到医疗系统再到警用携带相机，我们作为社会的一部分极有可能对这些算法输入各式各样的偏见、性别歧视、仇外思想、社会经济地位歧视、确认偏误等等。这些被输入了偏见的机器会大量生产分配，将种种社会偏见潜藏于科技客观性的面纱之下。

这种状况绝对不能再继续下去了。

在我们对人工智能进行不断开发研究的同时，需要降低它的开发速度，小心仔细地开发。算法偏见的危害已经足够大了。

我们能怎样减少算法偏见？

最好的方式是从算法训练的数据开始审查，根据 微软的研究人员 所说，这方法很有效。

数据分布本身就带有一定的偏见性。编程者手中的美国公民数据分布并不均衡，本地居民的数据多于移民者，富人的数据多于穷人，这是极有可能出现的情况。这种数据的不平均会使 AI 对我们是社会组成得出错误的结论。例如机器学习算法仅仅通过统计分析，就得出“大多数美国人都是富有的白人”这个结论。

即使男性和女性的样本在训练数据中等量分布，也可能出现偏见的结果。如果训练数据中所有男性的职业都是 CEO，而所有女性的职业都是秘书（即使现实中男性 CEO 的数量要多于女性），AI 也可能得出女性天生不适合做 CEO 的结论。

同样的，大量研究表明，用于执法部门的 AI 在检测新闻中出现的罪犯照片时，结果会 惊人地偏向 黑人及拉丁美洲裔居民。

在训练数据中存在的偏见还有很多其他形式，不幸的是比这里提到的要多得多。但是训练数据只是审查方式的一种，通过“应力测验”找出人类存在的偏见也同样重要。

如果提供一张印度人的照片，我们自己的相机能够识别吗？在两名同样水平的应聘者中，我们的 AI 是否会倾向于推荐住在市区的应聘者呢？对于情报中本地白人恐怖分子和伊拉克籍恐怖分子，反恐算法会怎样选择呢？急诊室的相机可以调出儿童的病历吗？

这些对于 AI 来说是十分复杂的数据，但我们可以通过多项测试对它们进行定义和传达。

为什么开源很适合这项任务？

开源方法和开源技术都有着极大的潜力改变算法偏见。

现代人工智能已经被开源软件占领，TensorFlow、IBM Watson 还有 scikit-learn 这类的程序包都是开源软件。开源社区已经证明它能够开发出强健的，经得住严酷测试的机器学习工具。同样的，我相信，开源社区也能开发出消除偏见的测试程序，并将其应用于这些软件中。

调试工具如哥伦比亚大学和理海大学推出的 DeepXplore，增强了 AI 应力测试的强度，同时提高了其操控性。还有 麻省理工学院的计算机科学和人工智能实验室完成的项目，它开发出敏捷快速的样机研究软件，这些应该会被开源社区采纳。

开源技术也已经证明了其在审查和分类大组数据方面的能力。最明显的体现在开源工具在数据分析市场的占有率上（Weka、Rapid Miner 等等）。应当由开源社区来设计识别数据偏见的工具，已经在网上发布的大量训练数据组比如 Kaggle 也应当使用这种技术进行识别筛选。

开源方法本身十分适合消除偏见程序的设计。内部谈话、私人软件开发及非民主的决策制定引起了很多问题。开源社区能够进行软件公开的谈话，进行大众化，维持好与大众的关系，这对于处理以上问题是十分重要的。如果线上社团，组织和院校能够接受这些开源特质，那么由开源社区进行消除算法偏见的机器设计也会顺利很多。

我们怎样才能够参与其中？

教育是一个很重要的环节。我们身边有很多还没意识到算法偏见的人，但算法偏见在立法、社会公正、政策及更多领域产生的影响与他们息息相关。让这些人知道算法偏见是怎样形成的和它们带来的重要影响是很重要的，因为想要改变目前的局面，从我们自身做起是唯一的方法。

对于我们中间那些与人工智能一起工作的人来说，这种沟通尤其重要。不论是人工智能的研发者、警方或是科研人员，当他们为今后设计人工智能时，应当格外意识到现今这种偏见存在的危险性，很明显，想要消除人工智能中存在的偏见，就要从意识到偏见的存在开始。

最后，我们需要围绕 AI 伦理化建立并加强开源社区。不论是需要建立应力实验训练模型、软件工具，或是从千兆字节的训练数据中筛选，现在已经到了我们利用开源方法来应对数字化时代最大的威胁的时间了。

via: https://opensource.com/article/18/1/how-open-source-can-fight-algorithmic-bias

作者：Justin Sherman 译者：Valoniakim 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

我已经主要使用 Linux 大约 10 年了，而且主要是 Ubuntu。但在最新发布的版本中，我决定重新回到我通常不喜欢的操作系统： Windows 10。

我一直是 Linux 的粉丝，我最喜欢的两个发行版是 Debian 和 Ubuntu。现今作为一个服务器操作系统，Linux 是完美无暇的，但在桌面上一直存在不同程度的问题。

最近一系列的问题让我意识到，我不需要使用 Linux 作为我的桌面操作系统，我仍然是一个 Linux 粉丝，但基于我安装 Ubuntu 17.10 的经验，我已经决定回到 Windows。

什么使我选择了回归

问题是，当 Ubuntu 17.10 出来后，我像往常一样进行全新安装，但遇到了一些非常奇怪的新问题。

• Dell D3100 Dock 不再工作（包括临时规避方案也没用）
• Ubuntu 意外死机（随机）
• 双击桌面上的图标没反应
• 使用 HUD 搜索诸如“tweaks”之类的程序会尝试安装 META 桌面版本
• GUI 比标准的 GNOME 感觉更糟糕

现在我确实考虑回到使用 Ubuntu 16.04 或另一个发行版，但是我觉得 Unity 7 是最精致的桌面环境，而另外唯一一个优雅且稳定的是 Windows 10。

除此之外，使用 Linux 而不是使用 Windows 也有一些固有的问题，如：

• 大多数商用软件不可用，E.G Maya、 PhotoShop、 Microsoft Office（大多数情况下，替代品并不相同）等等。
• 大多数游戏都没有移植到 Linux 上，包括来自 EA、 Rockstar Ect. 等主要工作室的游戏。
• 对于大多数硬件来说，其 Linux 驱动程序是厂商的次要考虑。

在决定使用 Windows 之前，我确实考虑过其他发行版和操作系统。

与此同时，我看到了更多的“微软爱 Linux ”的行动，并且了解了 WSL。他们的新开发者的关注角度对我来说很有意思，于是我试了一下。

我在 Windows 找到了什么

我使用计算机主要是为了编程，我也使用虚拟机、git 和 ssh，并且大部分工作依赖于 bash。我偶尔也会玩游戏，观看 netflix 和一些轻松的办公室工作。

总之，我期待在 Ubuntu 中保留当前的工作流程并将其移植到 Windows 上。我也想利用 Windows 的优点。

• 所有的 PC 游戏支持 Windows
• 大多数程序是原生的
• 微软办公软件

虽然使用 Windows 有很多坑，但是我打算正确对待它，所以我不担心一般的 Windows 故障，例如病毒和恶意软件。

Windows 的子系统 Linux（Windows 上的 Ubuntu 中的 Bash）

微软与 Canonical 的密切合作将 Ubuntu 带到了 Windows 上。在经过快速设置和启动程序之后，你将拥有非常熟悉的 bash 界面。

我一直在研究其局限性，但是在写这篇文章时我碰到的唯一真正的限制是它从硬件中抽象了出来。例如，lsblk 不会显示你有什么分区，因为子系统里的 Ubuntu 没有提供这些信息。

但是除了访问底层工具之外，我发现其体验非常熟悉，也很棒。

我在下面的工作流程中使用了它。

• 生成 SSH 密钥对
• 使用 Git 和 Github 来管理我的仓库
• SSH 到几个服务器，包括不用密码
• 为本地数据库运行 MySQL
• 监视系统资源
• 使用 Vim 编辑配置文件
• 运行 Bash 脚本
• 运行本地 Web 服务器
• 运行 PHP、NodeJS

到目前为止，它已经被证明是非常强大的工具。除了是在 Windows 10 用户界面之中，我的工作流程感觉和我在 Ubuntu 上几乎一样。尽管我的多数工作可以在 WSL 中处理，但我仍然打算通过虚拟机进行更深入的工作，这可能超出了 WSL 的范围。

不需要用 Wine

我遇到的另一个主要问题是兼容性问题。我很少使用 Wine 来使用 Windows 软件。（LCTT 译注：Wine 是可以使 Linux 上运行 Windows 应用的软件）但是有时它是必需的，尽管通常体验不是很好。

HeidiSQL

我首先安装的程序之一是 HeidiSQL，它是我最喜欢的数据库客户端之一。它可以在 Wine 下工作，但是感觉很不好，所以我在 Linux 下丢掉它而使用了 MySQL Workbench。回到了 Windows 中，就像一个可靠的老朋友回来了。

游戏平台 / Steam

没有游戏的 Windows 电脑是无法想象的。我从 Steam 的网站上安装了它，我的 Linux 游戏，加上我的 Windows 游戏就变大了 5 倍，并且包括 GTA V （LCTT 译注： GTA V 是一款名叫侠盗飞车的游戏) 等 AAA 级游戏。而这些我在 Ubuntu 中只能梦想。

我对 SteamOS 有很大的期望，并且一直会持续如此。但是我认为在可预见的将来，它不会在任何地方的游戏市场中崭露头角。所以如果你想在 PC 上玩游戏，你确实需要 Windows。

还有一点需要注意的是， 你的 nvidia 显卡的驱动程序会得到很好的支持，这使得像 TF2 （LCTT 译注： 这是一款名叫军团要塞 2 的游戏）这样的一些 Linux 原生游戏运行的稍好一些。

Windows 在游戏方面总是优越的，所以这并不令人感到意外。

从 USB 硬盘运行，为什么

我在我的主固态硬盘上运行 Linux，但在过去，我是从 usb 棒和 usb 硬盘运行它的。我习惯了 Linux 的这种持久性，这让我可以在不丢失主要操作系统的情况下长期尝试多个版本。现在我尝试将 Windows 安装到 USB 连接的硬盘上时，它无法工作也不可能工作。所以当我将 Windows 硬盘分区的克隆作为备份时，我很惊讶我可以通过 USB 启动它。

这对我来说已经成为一个方便的选择，因为我打算将我的工作笔记本电脑迁移回 Windows，但如果不想冒险，那就把它扔在那里吧。

所以我在过去的几天里，我使用 USB 来运行它，除了一些错误的消息外，我没有通过 USB 运行发现它真正的缺点。

这样做主要的问题是：

• 较慢的启动速度
• 恼人的信息：不要拔掉你的 USB
• 无法激活它

我可能会写一篇关于 USB 驱动器上的 Windows 的文章，这样我们可以有更详细的了解。

那么结论是什么？

我使用 Windows 10 大约两周了，并没有注意到它对我的工作流程有任何的负面影响。尽管过程会有一些小问题，但我需要的所以工具都在手边，并且操作系统一般都在运行。

我会留在 Windows吗？

虽然现在还为时尚早，但我想在可见的未来我会坚持使用 Windows。

via: https://www.chris-shaw.com/blog/my-adventure-migrating-back-to-windows

作者：Christopher Shaw 译者：MjSeven 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这三个问题可以帮你避开不实宣传。

不错，“区块链”这个概念异常的火热。

众所周知，我一直关注区块链及相关技术的成熟度发展情况，思考我们是否对其评价过高了；但从目前的情况来看，还没有这个迹象。我在文中提到的区块链技术是广义上的，包含了狭义上不属于区块链的分布式账本技术（DLT）。我对私有链permissioned blockchain更感兴趣，其中私有链的定义可以参考我的文章《区块链是安全性方面的话题吗？》。简而言之，我对加密货币之外的区块链业务应用特别感兴趣 ^注1 。

我们对区块链的技术成熟度的判断应该有一部分可以得到证实 ^注2 。如果我们判断正确，未来将会出现海量的区块链应用。这很可能会变成现实，但并不是所有的应用都是优秀的区块链应用，其中一部分很可能是非常糟糕的。

但区块链所处的技术成熟度意味着，大量业务将快速拥抱新技术 ^注3 ，但对于可能的前景却一知半解。促成这种情况的原因可以大致分为三种：

1. 对于涉及多用户数据存储的业务应用，在投入精力的情况下，几乎都可以改造为基于区块链的版本；
2. 很多区块链相关的会议和“专家”呼吁尽快拥抱区块链，否则可能会在半年内被淘汰 ^注4 ；
3. 完全理解区块链技术是很难的，支持其在企业中落地的往往是工程师。

对于最后一条，我必须补充几句，不然很容易被引起众怒 ^注5 。作为一名工程师，我显然无意贬低工程师。但工程师的天性使然，我们对见到的新鲜事物（亮点）热情澎湃，却对业务本身 深入 fully grok ^注6 不足，故对于新技术给业务带来的影响理解可能并不深刻。在业务领导者看来，这些影响不一定是有利的。

上面提到的三种促因可能导致一种风险，即在没有充分评估利弊的情况下，将业务改造为区块链应用。在另一文（区块链：每个人都应该参与进来吗？）中提到几个场景，用于判断一个业务什么情况下适合采用区块链技术。这些场景是有益的，但更进一步，我坚信人们更加需要的是，业务完全不适用区块链的几种简单的场景判定。我总结了三种场景判定，如果对于其中任何一个问题你给出了肯定的回答，那么很大概率上区块链不适合你。

场景判定 1：业务是否需要集中式的管控或授权？

如果你给出了肯定的回答，那么区块链不适合你。

例如，假设你是一个普通销售商，具有唯一的订单系统，那么对于何时发货你有唯一的授权，显然区块链不适合你。假设你是一个内容提供商，所有提供的内容都会经过唯一的编辑和发布过程，显然区块链不适合你。

经验总结：只有当任务对应的执行流程及相应的认证流程是分布于众多主体时，区块链是有价值的。

场景判定 2：业务使用经典数据库是否工作良好？

如果你给出了肯定的回答，那么区块链不适合你。

该场景似乎与上一个场景是强相关的，但并不总是如此。在一些应用中，处理流程是分布的，但信息存储是中心化的；在另外一些应用中，处理流程需要中心化的授权，但信息存储是分布的，即总有一个并不是分布式的。但如果业务使用经典数据库可以工作量良好的话，使用经典数据库是一个好主意。

经典数据库不仅性能良好，在设计与运营成本方面低比区块链或分布式账本，而且我们在这方面技术积累丰厚。区块链让所有人 ^注8 可以查看和持有数据，但间接成本和潜在成本都比较高昂。

场景判定 3：业务采用新技术是否成本高昂或对合作伙伴有负面效果？

如果你给出了肯定的回答，那么区块链不适合你。

我曾听过这种观点，即区块链会让所有人获益。但这显然是不可能的。假设你正在为某个流程设计一个应用，改变合作伙伴与你及应用的交互方式，那么你需要判断这个改变是否符合合作伙伴的想法。不论是否涉及区块链，可以很容易的设计并引入一个应用，虽然降低了你自己的业务阻力，但与此同时增加了合作伙伴的业务阻力。

假设我为汽车行业生产发动机配件，那么使用区块链追溯和管理配件会让我受益匪浅。例如，我可以查看购买的滚珠轴承的生产商、生产时间和钢铁材料供应商等。换一个角度，假设我是滚珠轴承生产商，已经为40多个客户公司建立了处理流程。为一家客户引入新的流程会涉及工作方式、系统体系、储藏和安全性标准等方面的变更，这无法让我感兴趣，相反，这会导致复杂性和高开销。

总结

这几个场景判定用于提纲挈领，并不是一成不变的。其中数据库相关的那个场景判定更像是技术方面的，但也是紧密结合业务定位和功能的。希望这几个判定可以为区块链技术引进促因带来的过热进行降温。

• 注 1. 请不要误解我的意思，加密货币显然是一种有趣的区块链业务应用，只是不在本文的讨论范畴而已。
• 注 2. 知道具体是哪些部分是很有意义的，如果你知道，请告诉我好吗？
• 注 3. 坦率的说，它其实更像是一大堆技术的集合体。
• 注 4. 这显然是不太可能的，如果被淘汰的主体是这些会议和“专家”本身倒十分有可能。
• 注 5. 由于比方打得有些不恰当，估计还是会引起众怒。
• 注 6. 我太喜欢 grok 这个单词了，我把它放在这里作为我的工程师标志 ^注7 。
• 注 7. 你可能已经想到了，我读过Stranger in a Strange Land一书，包括删减版和原版。
• 注 8. 在合理的情况下。

原文最初发表于爱丽丝, 夏娃和鲍勃 – 一个安全性主题博客，已获得转载许可。

via: https://opensource.com/article/18/3/3-tests-not-moving-blockchain

作者：Mike Bursell 译者：pinewall 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

让我们了解一下如何使国外读者更容易理解你的技术文章。

英语是开源社区的通用语言。为了减少翻译成本，很多团队都改成用英语来写他们的文档。 但奇怪的是，为国际读者写英语并不一定就意味着以英语为母语的人就占据更多的优势。 相反， 他们往往忘记了该文档用的语言可能并不是读者的母语。

我们以下面这个简单的句子为例： “Encrypt the password using the foo bar command。”语法上来说，这个句子是正确的。 鉴于动名词的 “-ing” 形式在英语中很常见，大多数的母语人士都认为这是一种优雅的表达方式， 他们通常会很自然的写出这样的句子。 但是仔细观察， 这个句子存在歧义因为 “using” 可能指的宾语（“the password”）也可能指的动词(“encrypt”）。 因此这个句子有两种解读方式:

• “加密使用了 foo bar 命令的密码。”
• “使用命令 foo bar 来加密密码。”

如果你有相关的先验知识（密码加密或者 foo bar 命令），你可以消除这种不确定性并且明白第二种方式才是真正的意思。 但是若你没有足够深入的知识怎么办呢？ 如果你并不是这方面的专家，而只是一个拥有泛泛相关知识的翻译者而已怎么办呢？ 再或者，如果你只是个非母语人士且对像动名词这种高级语法不熟悉怎么办呢？

即使是英语为母语的人也需要经过训练才能写出清晰直接的技术文档。训练的第一步就是提高对文本可用性以及潜在问题的警觉性， 下面让我们来看一下可以帮助避免常见陷阱的 7 条规则。

1、了解你的目标读者并代入其中。

如果你是一名开发者，而写作的对象是最终用户， 那么你需要站在他们的角度来看这个产品。 文档的结构是否反映了用户的目标？ 人格面具 persona 技术) 能帮你专注于目标受众并为你的读者提供合适层次的细节。

2、遵循 KISS 原则——保持文档简短而简单

这个原则适用于多个层次，从语法，句子到单词。 比如:

• 使用合适的最简单时态。比如， 当提到一个动作的结果时使用现在时:

  • " Click 'OK.' The 'Printer Options' dialog will appear. " -> "Click 'OK.' The 'Printer Options' dialog appears."
• 按经验来说，一个句子表达一个主题；然而， 短句子并不一定就容易理解（尤其当这些句子都是由名词组成时）。 有时， 将句子裁剪过度可能会引起歧义，而反过来太多单词则又难以理解。

• 不常用的以及很长的单词会降低阅读速度，而且可能成为非母语人士的障碍。 使用更简单的替代词语:

  • " utilize " -> "use"
  • " indicate " -> "show"，"tell" 或 "say"
  • " prerequisite " -> "requirement"

3、不要干扰阅读流

将虚词和较长的插入语移到句子的首部或者尾部:

• " They are not, however, marked as installed. " -> "However, they are not marked as installed."

将长命令放在句子的末尾可以让自动/半自动的翻译拥有更好的断句。

4、区别对待两种基本的信息类型

描述型信息以及任务导向型信息有必要区分开来。描述型信息的一个典型例子就是命令行参考， 而 HOWTO 则是属于基于任务的信息；（LCTT 译注：HOWTO 文档是 Linux 文档中的一种）然而， 技术写作中都会涉及这两种类型的信息。 仔细观察， 就会发现许多文本都同时包含了两种类型的信息。 然而如果能够清晰地划分这两种类型的信息那必是极好的。 为了更好地区分它们，可以对它们进行分别标记。 标题应该能够反映章节的内容以及信息的类型。 对描述性章节使用基于名词的标题（比如“Types of Frobnicators”），而对基于任务的章节使用口头表达式的标题（例如“Installing Frobnicators”）。 这可以让读者快速定位感兴趣的章节而跳过对他无用的章节。

5、考虑不同的阅读场景和阅读模式

有些读者在阅读产品文档时会由于自己搞不定而感到十分的沮丧。他们在一个嘈杂的环境中工作，也很难专注于阅读。 同时，不要期望你的读者会一页一页的进行阅读，很多人都是快速浏览文本，搜索关键字或者通过表格、索引以及全文搜索的方式来查找主题。 请牢记这一点， 从不同的角度来看待你的文字。 通常需要折中才能找到一种适合多种情况的文本结构。

6、将复杂的信息分成小块

这会让读者更容易记住和吸收信息。例如， 过程不应该超过 7 到 10 个步骤（根据认知心理学中的 米勒法则）。 如果需要更多的步骤， 那么就将任务分拆成不同的过程。

7、形式遵循功能

根据以下问题检查你的文字：某句话/段落/章节的 目的（功能）是什么？比如，它是一个指令呢？还是一个结果呢？还是一个警告呢？如果是指令， 使用主动语气： “Configure the system.” 被动语气可能适合于进行描述： “The system is configured automatically.” 将警告放在危险操作的 前面 。 专注于目的还有助于发现冗余的内容，可以清除类似 “basically” 或者 “easily” 这一类的填充词，类似 “already existing ” 或“ completely new” 这一类的不必要的修饰， 以及任何与你的目标大众无关的内容。

你现在可能已经猜到了，写作就是一个不断重写的过程。 好的写作需要付出努力和练习。 即使你只是偶尔写点东西， 你也可以通过关注目标大众并遵循上述规则来显著地改善你的文字。 文字的可读性越好， 理解就越容易， 这一点对不同语言能力的读者来说都是适合的。 尤其是当进行本地化时， 高质量的原始文本至关重要：“垃圾进， 垃圾出”。 如果原始文本就有缺陷， 翻译所需要的时间就会变长， 从而导致更高的成本。 最坏的情况下， 翻译会导致缺陷成倍增加，需要在不同的语言版本中修正这个缺陷。

via: https://opensource.com/article/17/12/7-rules

作者：Tanja Roth 译者：lujun9972 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Facebook 开发人员 Christine Abernathy 讨论了开源如何帮助公司分享见解并推动创新。

开源逐年变得无处不在，从政府直辖市到大学都有。各种规模的公司也越来越多地转向开源软件。事实上，一些公司正在通过财务支持项目或与开发人员合作进一步推进开源。

例如，Facebook 的开源计划鼓励其他人开源发布他们的代码，同时与社区合作支持开源项目。 Christine Abernathy，是一名 Facebook 开发者、开源支持者，也是该公司开源团队成员，去年 11 月访问了罗切斯特理工学院，在 11 月 的 FOSS 系列演讲中发表了演讲。在她的演讲中，Abernathy 解释了 Facebook 如何开源以及为什么它是公司所做工作的重要组成部分。

Facebook 和开源

Abernathy 说，开源在 Facebook 创建社区并使世界更加紧密的使命中扮演着重要的角色。这种意识形态的匹配是 Facebook 参与开源的一个激励因素。此外，Facebook 面临着独特的基础设施和开发挑战，而开源则为公司提供了一个平台，以共享可帮助他人的解决方案。开源还提供了一种加速创新和创建更好软件的方法，帮助工程团队生产更好的软件并更透明地工作。今天，Facebook 在 GitHub 的 443 个项目有 122,000 个分支、292,000 个提交和 732,000 个关注。

一些以开源方式发布的 Facebook 项目包括 React、GraphQL、Caffe2 等等。（图片提供：Christine Abernathy 图片，经许可使用）

得到的教训

Abernathy 强调说 Facebook 已经从开源社区吸取了很多教训，并期待学到更多。她明确了三个最重要的：

• 分享有用的东西
• 突出你的英雄
• 修复常见的痛点

Christine Abernathy 作为 FOSS 演讲系列的嘉宾一员参观了 RIT。每个月，来自开源世界的演讲嘉宾都会与对自由和开源软件感兴趣的学生分享关于开源世界智慧、见解、建议。 FOSS @MAGIC社区感谢 Abernathy 作为演讲嘉宾出席。

关于作者

Justin 是罗切斯特理工学院主修网络与系统管理的学生。他目前是 Fedora Project 的贡献者。在 Fedora 中，Justin 是 Fedora Magazine 的主编，社区的领导...

via: https://opensource.com/article/18/1/inside-facebooks-open-source-program

作者：Justin W. Flory 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出