本文档的存在是因为我们想确保所有作者以及想成为作者的人都能得到我们对常见问题的最佳解答——而不是因为我们想让您阅读常见问题解答来代替提问。如果您对为 Linux Journal 写作有任何疑问，请联系我们。

简介

Linux Journal 发表关于 Linux 和相关主题的文章。《Linux Journal》的读者学习如何在 Linux 上做以前做不到的事情。而且，由于 Linux 支持从手表到数据中心和太空火箭的一切，可能的范围接近无限。

我们也是严格的编辑。我们只想要最有趣、准确和文笔优美的文章。对于新闻，我们希望报道不仅要及时，而且要比读者在其他地方可能找到的更权威和深入。对于专题文章，我们希望同样如此，但读者兴趣不会在短期内消退——换句话说，文章在六个月或一年后仍然新鲜。

文章主题

我们尝试刊登关于所有在 Linux 上运行的软件类别的文章，以及面向所有技能水平读者的文章。我们努力刊登能吸引尽可能多读者的文章。

文章流程

文章通常会经历以下流程。

1. 作者的初步查询信。我们更喜欢以电子邮件形式发送查询信，在纯文本消息的正文中，而不是作为附件。查询信应包括一份简短的说明或大纲，描述您的文章将涵盖的内容。还请说明您认为何时能够完成文章（换句话说，您需要几天、几周、一个月或更长时间？）。请将您的查询信发送至此处。
2. 如果我们喜欢您的文章想法，我们将向您发送截止日期和稿约，其中将包括所有提交信息。
3. 请在此处向我们提交文章：此处。我们会尽快告知您文章是否已被接受。

合同和版权

所有写作均属推测性。提交您的文章，即表示您同意这些条款。如果我们决定使用该作品，我们将购买文章的首次出版权、汇编权和翻译权。但是，我们没有义务发表它。我们不支付退稿费。

一旦您的文章被提交，它就进入了出版队列，因此不能在其他地方提交，除非 1) Linux Journal 拒绝该文章，或 2) 作者通知 Linux Journal 他/她打算撤回该文章，并且 Linux Journal 同意发布该文章。我们不会发布文章的唯一情况是，如果文章已经安排出版并且为时已晚无法撤回。

我们可能会在任何媒体中无限次地使用您的文章进行汇编和翻译。在您的文章出现在 Linux Journal 中之后，您可以自由地将其用于任何目的，因为您保留版权。如果您的文章记录了如何使用免费软件程序，我们鼓励您根据免费软件许可证将其贡献给该项目，以便它可以与您讨论的软件一起分发。

您不能将您的文章用于其他出版物或您的网站。

文章类型和长度

专题/深度

这是一篇操作指南、成功案例、评论文章或深度/比较评测，包括以下部分或全部内容：示例代码、屏幕截图和照片。专题和深度文章通常为 2000-3500 字。

较短的文章

简短评测（对 Linux 相关产品或书籍的真实评价）、新 Linux 和 FOSS 项目的介绍、新闻评论、技术技巧和迷你操作指南。通常为 500-1000 字。

文章格式

文章必须以纯 ASCII 文本形式发送，可以是电子邮件正文或附件。图像和其他项目可以包含在带有主要文章的 tar 存档中，也可以作为单独的附件。

在您的文章文本中，注释或格式信息可以包含在 [方括号] 内，根据需要。句子后只放一个空格，段落之间空一行，不要缩进段落。文章或代码中不要使用任何 TAB 字符，而应使用空格代替。不要使用任何文字处理器特殊字符，例如“智能引号”。破折号使用 --。（—）

欢迎随意包含给编辑的任何其他说明，例如上标或下标文本的指示，在 [方括号] 内。如果您的写作材料包含方程式或需要特殊格式，请联系您的编辑以确定适合您需求的格式。

文章中的任何示例代码应为 70 个字符宽或更少。如果您对行进行编号，则行号和后面的空格计入行宽。一般来说，我们更希望您使用足够短的代码片段，以至于不需要行号。使用空格代替 TAB 字符以保留格式。

以纯 ASCII 文本形式发送表格。我们将进行排版。

图像格式

将图像发送为 PNG 或 JPEG。务必为每张图像添加标题。

文章中包含的项目

每篇文章都应包含一份简短的个人简介，例如，“Joe Author 担任 UNIX 系统管理员已有十年。他以养鸭子和淡水虾为爱好，欢迎您发送评论至 joe@ducksnshrimp.org。”个人简介可以是严肃的，也可以是幽默的。另请提供 Twitter 和/或 Facebook 账号，以便我们为您宣传。

我们还需要您的邮寄地址（不会公开），以便向您付款。

务必为每篇文章包含两个“预告”——简短的描述，总结文章的内容并吸引读者。

您可以选择在文章中包含的一些可选项目包括

写作风格

• 选择您关心的主题。
• 使用对话式风格。直接称呼读者。使用祈使句。
• 写作时，就好像您在与一位可能不熟悉您所涵盖内容的具体细节的聪明朋友聊天。永远不要对读者居高临下。
• 使用短句。这很有帮助。
• 使用短词，除非您需要的确切词恰好很长。
• 小心使用幽默。讽刺和反讽很容易被误读，并且可能具有攻击性。许多读者的母语不是英语，可能不熟悉您文化的流行笑话和热门话题。
• 如果您意识到无法按时完成任务，请尽快告知您的编辑。
• 请在提交之前，让一位技术 компетентный 的同事检查您的作品，尤其是任何代码。

您永远不应使用被动语态

再读一遍本节标题。读起来是不是非常笨拙？问问自己，您真的会对别人说这样的话吗？这个标题的问题在于它是用被动语态写的。这是一个为了说明问题的笑话。除非绝对必要（而且几乎永远不是绝对必要），否则永远不要使用被动语态。

稍后我将详细阐述使用主动语态的重要性。但威廉·津瑟在他的著作 《写作要好》 中用更少的文字表达了最好的观点（重点是我的）

 

除非没有舒适的方式来避免使用被动动词，否则请使用主动动词。主动动词风格和被动动词风格之间的区别——在清晰度和力度方面——对于作家来说，就是生与死的区别。

“乔看见了他”很有力。“他被乔看见了”很弱。第一个简洁而精确；它毫无疑问地说明了谁做了什么。第二个必然更长，并且具有一种平淡的品质：某人对另一个人做了某事。它也是模棱两可的。乔多久见到他一次？一次？每天？每周一次？由被动结构组成的风格会消耗读者的精力。”

您不太可能在为 Linux Journal 撰写的文章中使用“乔看见了他”。以下是一些可能与您更相关的示例

主动语态

单击“颜色”按钮以更改文本的颜色。

被动语态

文本颜色是通过按下“颜色”按钮来更改的。

为什么这种差异如此重要？

Linux Journal 是一本杂志。它不是参考手册。您可以在技术手册中使用被动语态。您会因为被动语态而失去杂志读者的注意力。正如津瑟指出的那样，为了理解您想说什么，解开被动语态的句子需要付出太多的努力。

关于与 Linux Journal 沟通的常见问题解答

您会阅读文字处理器格式的附件吗？

请以纯文本形式发送您的邮件。谢谢。

嘿，你能看我的 31337 文章想法吗？！?

Linux Journal 正在寻找使用标准英语语法、标点符号、大小写和拼写的文章。请在您的电子邮件中使用它们。

我可以为您写文章吗？

我们一直对文章提案感兴趣。第一篇文章最好涵盖以下内容

• 以前从未有人做过
• 任何地方都没有相关文档
• 在所有架构上运行
• 基于通用软件或文章中包含的简短程序
• 帮助所有 Linux 用户
• 产生可衡量的性能改进
• 制作酷炫的照片

您可能无法在一篇文章中完成所有这些，但您做得越多越好。如果您对多个主题感兴趣，请选择您认为自己最了解的主题作为您的第一篇文章。

请参阅上面的文章流程。

我可以为您写专栏文章吗？

如果您有兴趣成为定期撰稿人，请联系我们。我们正在接受个人文章、热门话题以及两篇或三篇文章系列文章的提案。未来的任何专栏作家都将从撰写过优秀文章的人中选出。

关于文章流程的常见问题解答

在您的文章发表后但在用于翻译或汇编之前，我可以对我的文章进行更正吗？

如果您在文章发表后发现错误，请联系我们。我们将提供勘误表，并努力将更正纳入以后的使用中。

如果您为我分配的截止日期对应于未来的某期，这是否意味着文章会出现在该期中？

不幸的是，我们不能肯定地说。直到最后一刻我们自己也不确定。

我可以将同一篇文章提交到其他地方吗？

不可以。请参阅合同和版权。

我可以将关于同一主题的不同文章提交到其他地方吗？

如果您为其他出版物撰写过关于同一主题的类似文章，您应该在提出文章时告知我们。在您的文章发表后，我们鼓励您在文章发表的当期封面日期之后重新利用它。最好告知另一出版物的编辑。

版权呢？

版权归您所有。请参阅合同和版权。

为什么您不能说我的文章何时发表？

我们有一个审查团队，在排版之前投票决定哪些文章将用于数字杂志。在排版之前，我们不确定会选择哪些文章。有时我们确实对提前发行哪些文章有一个很好的想法，有时我们会分配关于及时主题的文章，我们将尽一切努力尽快发表这些文章。

关于文章内容的常见问题解答

你们是否刊登在其他地方发表过的文章？

不。唯一的例外是我们偶尔会刊登书籍摘录，但这很少见。我们不刊登已经出现在您的个人网站或 LJ 网站以外的网站上的文章。 但是，如果您有一个关于某个主题的信息丰富的网站，您可以撰写一篇关于该主题的文章。

您拒绝文章想法的主要原因是什么？

这是一个非常笼统的想法，不太适合 Linux Journal。它更适合面向非 Linux 受众的出版物，让他们大致了解 Linux 的可能性。

这个想法与大量现有在线资源和流行的 Linux 书籍中涵盖的内容非常相似。我们更倾向于涵盖其他地方尚未广泛涵盖的想法。

一般来说，Linux Journal 对关于仅二进制内核代码或硬件的文章提案不感兴趣，这些硬件的唯一驱动程序是仅二进制内核模块的形式。

文章包含特定于发行版的指令，用于不应或不应该是特定于发行版的内容。

没有性能测量来比较列出的解决方案并证明您的性能改进声明是合理的。

我们最近发表了一篇关于这个主题的文章。

我们不能接受以前在网络或印刷品上发表过的文章。

这似乎太接近产品文档或应该在产品文档中的内容。

这篇文章的想法与 Linux 的关联性不足。

这篇文章太“商业化”了。

这篇文章没有充分涵盖使这个主题/产品/等等引人注目的地方。

这篇文章不适合 LJ 的受众。

有哪些令人困惑的表达方式需要避免？

首字母缩略词

在引入新的首字母缩略词时，请在第一次拼写出来，并在括号中注明首字母缩略词。您无需在首次使用时展开常见的首字母缩略词。一些常见的首字母缩略词包括：ATA、CD、CDROM、DVD、HTTP、IP（当用于表示 Internet 协议时）、SCSI、SMTP、RAM、TCP、WWW。

抨击旧版操作系统

如果您想成为一名有效的 Linux 倡导者，那么忽略其他操作系统——毕竟它们已经过时了——比大肆宣扬您不喜欢它们的地方要有效得多。当您必须做一些特别的事情才能与旧版非 Linux 操作系统互操作时，请实事求是地对待它，并让读者得出自己的结论。

商业

不要用来表示专有。通常，一个程序既可以是商业的，也可以是免费的——作为一项业务提供商业支持，但可以自由修改和重新分发。

编译，如何

不要包含编译和安装程序的冗长解释。通常，人们要么可以从软件包安装，要么遵循 README 文件。在一篇文章中简短提及如何编译和安装是可以的，但是如果您正在撰写关于难以编译和安装的程序，请自愿修复它或编写更好的 README，而不是让文章成为不必要地变得困难的事情的变通方法。

自由软件

不要使用此术语来指代免费提供的专有软件。

脚注

我们不使用脚注。请将信息放在正文中，并将引文放在文章末尾的“参考资料”部分。

黑客

/usr/src/linux/CREDITS 和其他地方的开发人员将自己定义为“黑客”——不要使用该术语来表示“计算机罪犯”。

拉丁语

我们不使用拉丁语缩写，例如 e.g. 和 i.e.。请使用常用词语。不要使用 etc. 来结束示例列表。使用“例如”和一个逗号。

备选标题

如果您无法确定标题，请包含多个标题。

屏幕截图

屏幕截图确实有助于读者理解 GUI 程序。使用屏幕截图来说明主要步骤或概念。当读者可以根据之前的屏幕截图轻松地将其可视化时，请不要使用额外的屏幕截图。

图片建议

请包括关于哪种图片适合您的文章的建议（请参阅我们网站的主页，了解每篇文章是如何配图的）。