要为我们撰稿，请查看并遵守本指南。我们欢迎关于开源软件和硬件以及开放数据、开放科学和开放知识的文章想法或草稿。了解更多关于如何成为我们社区的一份子的信息。
所有内容均根据 知识共享署名-相同方式共享许可协议 4.0 获得许可，除非另有说明。
开始
受众
OpenSource.net 接受关于软件、硬件以及与开放文化、科学、数据和知识相关主题的文章。
OpenSource.net 的读者既有技术背景，也有非技术背景。他们来自不同的地理区域、背景和研究领域。
如果您的投稿的主要目的是推广产品或您的公司，那么我们不是您文章的合适发表平台。我们专注于关于开放项目、技术和社区的故事——我们不认可产品。当我们提及公司或产品时，我们通常链接到维基百科条目，而不是公司或产品页面。虽然产品推销不适合我们，但您可能有一个关于您的组织如何使用开源或回馈开源的精彩故事，我们很乐意帮助您讲述。
最后的话：保持简洁、专注和及时。
文章类型
一些通用指南
- 500-600 字：大约 500 字可能足以用于项目更新、宣布新的会议或分享其他及时的开放新闻。
- 600-800 字：这是一个常规专题文章、专栏投稿、采访或综述的良好范围。考虑添加一两个副标题来分解文本，并引导读者阅读文章的各个部分。
- 800-1,300 字：操作指南、入门指南、教程和更深入的综述往往比专题文章更长。
- 1,300+ 字：如果您的文章远超 1,300 字，请考虑将故事分成多个部分。
OSNet 编辑指南
我们很高兴与您合作撰写 OSNet 的故事。
我们涵盖开源软件和硬件以及开放数据、开放科学和开放知识。我们的目标是讲述关于这些主题以及项目背后人物的引人入胜的专题故事。
成功的投稿提案会回答以下问题：
- 为什么是这个故事？
- “开放”的角度是什么？
- 这件事的重要性是什么——以及为什么是现在？
- 我们为通用知识库增加了什么？我们避免重复多次报道过的故事。
- 您为故事带来了什么：是对项目的普遍了解、专业知识，还是周末的修补？告诉我们为什么我们应该将这个故事分配给您。
关于产品的特别说明：如果主要目的是为您的公司或产品提供反向链接或提高销量，那么我们不是您文章的合适发表平台。
不起作用的投稿提案示例
示例：三大 Markdown 语言。本文旨在概述 Markdown-it、CommonMark 和 Pandoc，并简要介绍每种语言的优势。
快速网络搜索显示，热门结果是标题党：
然后结果是 Markdown 编辑器列表、Markdown 指南等。
通过发布另一篇这样的文章，我们为社区增加了什么？可能不多，因为 OSNet 的目标是供人类阅读，而不是为了点击量而优化。也没有关于为什么投稿人适合撰写这篇文章的信息。
如果您有兴趣撰写关于您使用的软件的文章，我们对文章内容应该是手册中包含的内容不太感兴趣。我们想知道您为什么应该使用它，它的优势是什么？您发现了哪些独特的技巧来解决酷炫的现实生活问题？
例如，我们想知道您如何使用 LibreCalc 跟踪花园中的温度和湿度以最大化蔬菜生长，但我们对关于如何在 GNUplot 中构建简单图表的教学帖子不太感兴趣。
如果您想撰写关于电子表格的系列文章，请描述读者在阅读完该系列文章后将学习/能够做什么：该系列是否贡献了已被广泛涵盖的知识？当与某些工作场所合作时，如果仅使用 OSS 通常不如其他选择有吸引力/功能强大或容易/常见，大多数人并不关心。虽然我们的大多数读者都支持开源，但最好始终考虑它对更广泛的受众以及总体而言的实用性/趣味性。
一篇好的投稿提案会简要地回答这些问题。
起作用的投稿提案示例
以下是一些示例：
- GDPR 将如何影响开源社区？许多组织正在努力理解法律的变化将如何影响他们的工作。我将介绍影响开源社区的主要法规部分，例如同意、被遗忘权、访问权和违规通知。随着法律在几周后生效，这将成为您读者的及时入门指南。我是一名律师，在开源领域拥有三年经验。
- 开源对很多人来说意味着很多事情。这也许就是为什么它也是技术领域中最被误解和误用的术语之一。我们正在推出一个名为“我的开源经验”的播客，我们想写一篇关于我们正在做什么以及为什么这样做的文章。理想情况下，该文章的发布时间应与两周后的发布时间一致。主持人拥有在开源社区共 25 年的经验。
- 2017 年，我启动了一个名为 OpenAvalanche 的开源项目，旨在通过使用机器学习提高预测准确性来减少全球范围内的死亡人数。我目前正在寻找在机器学习和人工智能方面具有经验的社区贡献者。您是否有兴趣专题报道该项目？我们可以将其安排在今年十月的国际减灾日。
风格指南
我们的编辑团队力求正确性和一致性。我们遵循美联社风格，与开源促进会保持一致。
遵循一些基本原则，让您的文章更容易被“接受”！
- 写出小于 10 的数字（例如：九、八和七）
- 日期格式为 12 月 1 日，2014 年（而不是2014 年 12 月 1 日）
- 将句点和逗号放在引号内（代码示例除外）
- 本出版物是 OpenSource.net 或 OSNet
- 大写且不要用连字符连接 Open Source（而不是 open source、opensource 或 open-source tools）
语法和拼写
我们的编辑团队会审查每篇文章的语法、拼写、格式、风格等。为了简化发布流程，请校对您的草稿并遵守正确的语法和美式拼写规范。
术语警惕
您可能知道您的LBaaS 和您的VPNaaS，但永远不要假设读者也知道。新兴技术的势头来自刚接触它的人们——不要用转瞬即逝的首字母缩略词将他们拒之门外。
首次提及时请拼写出首字母缩略词，特别是那些特定于技术或社区的首字母缩略词。新读者不应该想知道 PTL 是项目技术负责人还是acronymfinder.com上的其他 58 个含义之一。
链接
所有故事都需要链接，因此请提交带有链接的故事。确保它们指向有用的信息。如果链接突出显示的部分是会议的工作早餐会议，请链接到该特定会议或会议纪要——而不是主会议页面。
更多示例
- 在首次提及文章中提到的开源项目时，包含指向这些项目的链接或指向描述该项目的维基百科页面的链接。
- 解释或链接到其他开源许可证、组织、标准等。
- 包含指向非技术受众可能不熟悉的技术想法和术语的链接。
格式
小标题：如果您的文章超过 500 字，请考虑添加小标题来分解文本并使其更易于阅读。使用 <h2> 和/或 <h3> 标题。如果您的文章超过 1,300 字，我们可能会考虑将文章分成更长的系列文章。
采访：问题使用粗体，答案使用常规格式。
代码格式：如果您的文章包含代码，请使用 <code> 标签对其进行描述，我们的编辑团队将在发布前确认正确的格式。如果是短代码片段、函数名称或其他一些小片段，请将其保留在段落内联中，但较长的代码块应另起一行。不要使用块引用或 <pre> 标签来表示代码示例。
避免使用“在下面的代码中”或“在上面的代码中”之类的短语，因为布局永远无法保证。相反，请遵循一致的模式：首先介绍代码块的作用，然后向读者展示代码。如有必要，为复杂或令人困惑的部分提供额外的解释。在编写多个代码示例时，请分别介绍每个示例。
表格：HTML 表格无法调整大小以适应屏幕，这使得它们在移动设备上难以阅读。请改用项目符号列表。
图片
Opensource.net 上发表的每篇文章都有一张引导图片。如果您想建议一张图片，请务必包含图片来源和许可详细信息。
内联图片：内联图片和屏幕截图增加了视觉趣味性，可能有助于说明您的文章并分解文本。如果您包含图片，请确保它们与您的文章的许可证（我们的默认许可证是 知识共享署名-相同方式共享 4.0）相匹配，或者告知我们许可证是什么以及您有权在我们的网站上分享。
- 署名：在您提交草稿和图片时，请包含图片来源和许可详细信息。
- 格式：以文件形式提交图片，附加到您的投稿提案或草稿中。不要将图片放在草稿中。
- 尺寸：不大于 1920×1080。
- 标记图片：标记图片，以便编辑可以轻松判断每张图片应在文章中的哪个位置使用（mylinux.webp）。
- 添加标题（如果适用）：请务必在您的文章文本中引用您的图片应放置的位置以及标题应写什么。（例如：[mylinux.webp] 标题：这是我的 Linux 桌面的屏幕截图。）
- 避免使用文本屏幕截图作为图片。盲人使用的屏幕阅读器无法“看到”嵌入在图片中的文本，因此，如果您想在屏幕截图中演示的内容可以更好地表达为代码块，请改用文本。
- 如果您提供图片，请在命名图片文件时使用描述性术语，并在文章草稿中包含您希望放置图片的文件名。发送每个文件的图片署名信息。
投稿指南
原创内容
如果您的文章（或文章的某个版本）已在其他网站上发表，请告知我们。通常，我们发表原创文章，但我们会考虑转载文章或运行修订版本。在任何情况下，我们都需要预先知道您的投稿是否已在其他地方发表或将要发表。
文档格式
您可以以 .md、.odt、.txt、.docx 文件附件的形式提交文章。如果您发送指向 Etherpad 或 Google 文档的链接，请勿在提交后修改文档。我们会下载并编辑您发送给我们的内容，因此我们看不到您的更改。
审核流程
使用此表单发送您的草稿或投稿提案。包含您作品的许可证。我们的默认许可证是 知识共享署名-相同方式共享 4.0，但我们会根据具体情况考虑其他许可选项。要注册帐户，请填写此表单。请务必添加个人简介和照片，然后保存。
编辑团队将审核您的投稿并回复后续步骤。如果我们对您的想法感兴趣，我们将尽快回复您。很遗憾，我们无法回复所有人。
发布时间表
我们的编辑团队会在发布文章之前仔细审查、编辑和准备文章。如果您的投稿被批准发布，可能会要求进行修订。编辑团队将在需要时进行文字编辑和更深入的建议。
通常，我们在作者批准最终修订稿后两到三周内发布文章。如果您对文章的发布日期有具体期望，或者文章包含禁止发布的信息，请在您投稿提案或提交文章时告知我们。
编辑工作流程
收到的请求自动具有“新”状态。主编审核收到的工单，并相应地更改工单状态
- 需要评估：投稿提案需要另一位团队成员（代理人）进行审核（例如，需要技术专业知识的文章）
- 搁置：投稿提案需要进一步评估，代理人尚未决定如何回复，但已阅读，并且工单不应被分配的代理人以外的任何人触摸
- 已委托：投稿提案被接受，并附带关于如何进行的说明
- 已拒绝：投稿提案不可接受。流程在此结束。
- 需要信息：投稿提案需要投稿人提供更多详细信息或调整
- 编辑批准：提交的文章已准备好发布
- 制作中：此状态表示已批准的草稿（以及所有相关的图片）需要移动到帖子中进行编辑
- 已安排：文章已编辑完成，可以发布。流程在此结束。
