经常在utopian发文，但是最近经常不通过，每次都是给我说不符合规则，那么今天我就来翻译下 utopian 的发帖规则，相当于是自己罚自己抄写一遍了(现在可能 utopian 给我最大的感触就是得跪舔审核）。希望我的翻译可以帮助到像我这样英语不是很溜的同学，深入学习下规则还是有必要的，可以节约大量的时间。

（全文基本上是先通过Google翻译，然后不易理解的地方，我再人工对照英文修改语序或者重新翻译。翻译不对的地方可在评论里纠正，原谅我目前的英语渣水平）

在翻译的最后，附上我所有未通过的帖子以及未通过的原因。

---

General Rules

总则

Immediate Rejection

Not respecting one or more of the rules below will lead to direct rejection of your contribution.

立即拒绝

不尊重下面的一条或多条规则将导致直接拒绝您的贡献。

Hard VS Soft Rules

Rules are implicitly marked as Hard rules. Soft rules are marked with the label [SOFT].

• All the rules not marked as [SOFT] lead to immediate rejection.
• All the rules marked as [SOFT] may lead to rejection if you have been notified about the same mistake multiple times. In any other case the Moderator will ask for a change but accept your contribution anyways.

硬规则VS软规则

规则未含标记的为硬性规则。 软规则标有 [SOFT] 标签。

• 所有未标记为 [SOFT] 的规则，违反都会导致立即拒绝。
• 如果多次收到同一错误的通知，所有标记为 [SOFT] 的规则也可能会导致被拒绝。 任何其他情况下，审查员们都会要求按照要求更改，但无论如何都会接受您的投稿。

Editor Templates

When submitting a contribution you will find a standard template that you should follow when writing the details of your contribution.

• Templates are editable, as long as your contribution has a clear format.
• Templates can be extended.

编辑模板

提交投稿时，您会发现一个标准模板，您在撰写投稿的详细信息时应遵循该模板。

• 模板是可编辑的，只要您的贡献有明确的格式。
• 模板可以扩展。

Temporary / Lifetime Bans - Utopian Downvote

Utopian may ban your account temporarily or for the lifetime and may also proceed for a downvote in any of the following cases.

• Any user found harassing a member of the Utopian Moderators or in general any member of the Utopian teams.
• Using multiple accounts to clearly abuse the system.
• Keep contributing with low quality contributions even after being notified.
• Plagiarism.
• Using Licensed or commercial materials or Creative Commons without citing the source even after being notified.
• Tag spamming. [SOFT]

临时/终身禁止 - Utopian踩

乌托邦可能会暂时或终身禁止您的帐户，并且可能会在下列任何情况下进行踩。

• 任何用户发现骚扰Utopian审核员或Utopian团队的其他的任何成员。
• 滥用多个帐户。
• 即使在收到通知后仍保持低质量的贡献。
• 抄袭。
• 使用许可或商业资料或知识共享，即使在收到通知后仍未引用来源。
• 标记为垃圾信息。 [SOFT]

Commercial/Copyrighted Materials

No commercial or copyrighted material should ever be used in a contribution.

• Only Creative Commons for Images and Videos can be accepted and the source should be always cited.
• You retain full responsibility when using copyrighted or commercial materials without proper permission.

商业/版权资料

任何商业或受版权保护的资料都不得用于捐赠。

• 只有图像和视频的创作共用才能被接受，并且应始终引用来源。
• 未经适当许可，使用版权或商业资料时，您将承担全部责任。

Contributions must be Formal and Professional

A moderator may reject a contribution if it is not written in a formal and professional style.

• The contributor should follow the templates provided in the editor for each category. [SOFT]
• The writing style should be formal never informal.
• The writing style should be professional.
• Sentences like: Hello Utopians, Hello Steemians, Dear friends and similar informal sentences may lead to rejection. [SOFT]
• Sentences like resteem, follow, upvote may lead to immediate rejection. [SOFT]
• Quality of the images and videos used in the contribution should be high. Low res images and videos will be rejected. [SOFT]
• A contribution with bad grammar will be rejected if the contents may be really hard to understand. [SOFT]

贡献必须是正式的和专业的

如果文章没有以正式和专业的风格写作，审查员可能会拒绝该贡献。

• 撰稿人应遵循编辑器中为每个类别提供的模板。[SOFT]
• 写作风格应该是正式的，而不是非正式的。
• 写作风格应该是专业的。
• 句子如：你好乌托邦人，你好史蒂米安人，亲爱的朋友和类似的非正式句子可能会导致拒绝。 [SOFT]
• 像resteem，follow，upvote这样的句子可能会导致立即被拒绝。 [SOFT]
• 贡献中使用的图像和视频的质量应该很高。 低分辨率的图像和视频将被拒绝。 [SOFT]
• 如果贡献内容有糟糕的语法，导致内容很难理解也会被拒绝。 [SOFT]

Contributions must be Informative

The contribution must contain as much detail as possible and have some graphical content in it (images, charts, videos, etc) where applicable. The length of the body of the contribution should be enough to give every possible detail about the submitted contribution.

贡献必须是有有用内容的

贡献必须包含尽可能多的细节，并在适用的地方包含一些图形内容（图像，图表，视频等）。 贡献主体的长度应该足以给出提交的贡献的每个可能的细节。

Contributions must be in English

Contents of the contributions (post content) must be in plain English and fully understandable.

共享内容必须使用英文

贡献内容（帖子内容）必须用简单的英文表达，并且完全可以理解。

Never Submitted Before

Contributions must be unique. Users must first check if the same or very similar contribution has been submitted before.

• Same contributions will never be accepted in Utopian twice by the same or different user.
• Contents already shared on the Steem blockchain in general may still be rejected if submitted in Utopian.
• Contents already shared anywhere else may still be rejected if submitted in Utopian.
• Same contents already shared before in Utopian or anywhere else by different users may still be rejected if a moderator recognises plagiarism.

之前从未提交过

贡献必须是独一无二的。 用户必须先检查之前是否提交过相同或非常相似的贡献。

• 相同或不同的用户永远不会在Utopian中接受两次相同的贡献。
• 如果在Utopian中提交，Steem区块链上已经分享的内容一般可能会被拒绝。
• 如果在Utopian提交，其他地方已经分享的内容仍可能被拒绝。
• 如果审查员承认剽窃，那么以前在Utopian或其他任何地方已经分享过的内容可能仍会被拒绝。

Author of the Contribution

The contribution must provide as much detail as possible to verify the actual work done and that you are the author.

• If your Steem/Utopian username does not match with the username used in an external platform, you must either edit the username in the external platform or provide an immediate way to verify you are the author.

贡献的作者

贡献必须提供尽可能多的细节来验证所做的实际工作，并且您是作者。

• 如果您的Steem / Utopian用户名与外部平台中使用的用户名不匹配，则必须在外部平台中编辑用户名或提供验证您是作者的方式。

Contributions Must Not Contain Spam

The contribution should not contain any clear attempt to profit solely from a commercial perspective, and should not be written in a way that suggests the contributor is looking to maximise the returns.

• The author may provide links to his social profiles in a way that does not disturb the reader.
• Links to commercial products are forbidden.
• Misusing the mentions by mentioning other Steem/Utopian users without an obvious reason will lead to rejection. [SOFT]

贡献不得包含垃圾信息

贡献不应该包含任何明确的商业获利行为，也不应该以贡献者希望获得最大回报的方式撰写。

• 作者可以以不妨碍读者的方式提供他的社交简介的链接。
• 禁止链接到商业产品。
• 提到其他Steem / Utopian用户而没有明显的理由，这将会导致被拒绝。 [SOFT]

Contributions Must Not Contain Defamation

Contributions must not use namecalling directed at other users of the Steem blockchain. Contributions may not contain false information about another user that may be perceived as defamatory.

贡献不得含有诽谤

贡献不得使用针对Steem区块链的其他用户的名称调用。 贡献可能不包含可能被视为诽谤的其他用户的虚假信息。

Contributions Should Not Solicit for Unrelated Activities

• Contributors should not ask for Steem/Steemit related activities in their posts, such as upvotes, resteems and follows. [SOFT]
• Contributors should not ask for Utopian related activities in their posts, such as upvotes and follows. [SOFT]
• Contributors should not solicit for any activity in general that it is not strictly accepted by the Utopian Rules.
• Contributors should not ask for witness votes in their Utopian posts. [SOFT]

不应为无关活动征求捐款

• 撰稿人不应在其帖子中要求Steem / Steemit相关活动，例如upvotes，resteems和follow。 [SOFT]
• 撰稿人不应在其帖子中要求进行与Utopian相关的活动，例如upvotes和follow。[SOFT]
• 撰稿人不应该招揽任何的活动，因为它不被Utopian规则严格接受。
• 作者不应该在Utopian的帖子中要求见证人投票。[SOFT]

Unvoting - Rejection After Approval

Utopian can unvote or reject an accepted contribution if it is found out that the contribution did not meet the rules and had been upvoted by mistake. This decision considers cases such as attempts of plagiarism, copying work and ideas of others or other violation of the rules which would be obvious to see that the contribution does not deserve the reward.

Unvoting - 批准后拒绝

如果发现捐献不符合规则并且被错误地通过，Utopian就可以否决或拒绝之前的贡献。 这个决定考虑了诸如剽窃企图，抄袭作品和其他人的想法或其他违反规则的情况，而这些规则显然会看到这种贡献不值得奖励。

Github Repository

• The linked Github repository must always contain code, a README and a license. [SOFT]
• Contributions will only be accepted for repositories not present in the Utopian repository blacklist.
• Contributions for un-official repositories will only be accepted if present in the Utopian un-official repository whitelist.
• Contributions on official repositories that are mirrors of another subversioning system are always accepted.
• Contributions on repositories that had no updates for longer than 1 year, will be rejected.
• Contributions on forks that do not have any difference/improvement from the original project won't be accepted.

Github Repository

• 链接的Github Repository必须包含代码，自述文件和许可证。 [SOFT]
• 只有Utopian Repository黑名单中不存在的Repository才能被接受。
• 只有在Utopian的非官方Repository白名单中的，才会接受对非官方Repository的贡献。
• 对于那些给官方库的镜像库的贡献也是会被接受的。
• 超过1年没有更新的 Repository 的贡献将被拒绝。
• 与原始项目没有任何区别/改进的分支上的贡献将不被接受。

Categories Rules

具体分类的规则

Suggestion Rules

• Suggestions are minor features/enhancements that you would like to have in an Open Source project.
• Suggestions may be only related to the technical aspects of the project not process or organisational issues.
• Suggestions must provide all the details for the requested features to be actually built.
• Images, screenshots, links and examples are always welcome in this category.
  Not respecting the rules will either give you lower votes or your contribution won't be accepted.

Suggestion 规则

• Suggestion 是您希望在开放源代码项目中使用的次要功能/增强功能。
• Suggestion 可能只涉及项目的技术方面而非流程或组织问题。
• Suggestion 必须提供所有要实现的功能的所有详细信息。
• 在这个类别里，图片，截图，链接和例子总是欢迎的。
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

Development Rules

• In the development category you can submit Bug Fixes, New Features and your Own Projects.
• Contributions must have a comprehensible commit history. Larger projects or updates submitted in a single commit will not be accepted.
• Outdated or low quality code can lead to rejection.
• Generated code or other results of automated processes will not be accepted.
• Submitted projects must have a unique value. Redundant projects will not be accepted.
• Trivial code snippets, example code or simple templates will not be accepted.
• Bug Fixes and New Features must be submitted via Pull Requests. The Pull Request must have been merged within the past 14 days.
• Updates on Own Projects can be committed directly, without a Pull Request. Commits must not be older than 14 days.
• Bug Fixes for your Own Projects will not be accepted, unless the Bugs were caused by third party dependencies.
• Your Utopian account must be connected to your GitHub account.
  Not respecting the rules will either give you lower votes or your contribution won't be accepted.

Development 规则

• 在 Development 类别中，您可以提交 BUG修复，新功能 和 自己的项目。
• 贡献必须有一个易于理解的提交历史记录。不接受在单次提交中提交的较大项目或更新。
• 过时或低质量的代码可能会导致拒绝。
• 生成的代码或其他自动化过程的结果将不被接受。
• 提交的项目必须具有独特的价值。冗余项目将不被接受。
• 不会接受简单的代码片段，示例代码或简单的模板。
• BUG修复和新功能必须通过Pull Request提交。Pull Request必须在 过去14天内 Merge。
• 自己的项目上的更新可以直接提交，无需提交请求。 Commits不得超过14天。
• BUG修复为您的自己的项目将不被接受，除非错误是由第三方依赖造成的。
• 你的Utopian帐户必须连接到你的GitHub帐户。
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

Bug Hunting Rules

• In this category you can submit Bug Reports for actively maintained Open Source projects on GitHub.
• The repository on GitHub must accept issues.
• Bug Reports for projects in pre-alpha stage will not be accepted.
• Cosmetic issues, that do not affect the functionality of the software, will not be accepted.
• You must provide sufficiant detail to reproduce the bug.
• Add screenshots, video recordings or animated GIFs, if they can help to understand the bug. [SOFT]
• Include information about your technical environment such as Device, Operating System, Browser and Application versions.
• Bugs must be found on the latest released version of the application.
• If you or someone else submitted the issue on GitHub first, the Bug Report will not be accepted. Approved Bug Reports will automatically be published on GitHub.
• Your Utopian account must be connected to your GitHub account.
  Not respecting the rules will either give you lower votes or your contribution will not be accepted.

Bug捕获 规则

• 在这个类别中，您可以在GitHub上为维护状态中的开源项目提交** Bug Reports **。
• GitHub上的Repository必须允许用户提交 Issues。
• Bug报告不适用于alpha版阶段的项目。
• 对于软件无关痛痒的功能BUG（比如拼写错误）将不会被接受。
• 您必须提供充足的细节来重现错误。
• 添加截图，视频录像或动画GIF，如果他们可以帮助理解错误。 [SOFT]
• 包括有关技术环境的信息，例如设备，操作系统，浏览器和应用程序版本。
• BUG必须在最新发布的应用程序版本中找到。
• 如果已经在GitHub上提交了该问题，则不会接受BUG报告。由Utopian通过的BUG报告将自动发布在GitHub上。
• 你的Utopian帐户必须连接到你的GitHub帐户。
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

Translations Rules

• This category is meant only for translations you have created or updated for an Open Source project.
• You must translate a minimum of 1000 words per translation contribution.
• CrowdIn contributions can be submitted only by translator with Proofreading permissions in the project, for the given language.
• Text that is supposed to remain untranslated (links, code, paths, ...) or duplicated strings/text can't be included in the minimum amount of words.
• You could translate less than the minimum amount of words if the project itself has less to be translated in total. May lead to a lower vote.
• Entire translations are always preferred. If you are writing about a partial translation we reserve the right to evaluate the actual work.
• If it is obvious that you can't properly write in the source language of the translation, your contribution will be rejected.
• If the translations is provided via GitHub is has to be a merged pull request
• The Pull Request must have been merged within the past 14 days.
• Updates on Own Projects can be committed directly, without a Pull Request. Commits must not be older than 14 days.
• Your GitHub username must match that on Utopian. If it does not, you must add your Utopian username in your GitHub profile.
• You must include every possible detail to check your translation and the tools you have used to translate.
• Same translations from different authors will be accepted if the moderator can recognise the newest translation has better quality.
• If the provided translation is obviously machine-translated for more than 20% or has low quality, it will be rejected.
• Proof-reading is not acceptable in Utopian as a valid contribution.
  Not respecting the rules will either give you lower votes or your contribution won't be accepted.

Translations规则

• 此类别仅适用于您为开放源代码项目创建或更新的翻译。
• 每个翻译贡献至少1000词。
• 针对给定的语言，CrowdIn翻译贡献只能由具有项目校对权限的翻译人员提交。
• 应该保持未翻译的文本（链接，代码，路径，...），重复的字符串/文本不能包含在最小量的单词中。
• 如果项目本身的翻译总数较少，则可以翻译少于最少量的文字。这可能会导致较低的投票。
• 整个翻译总是首选。如果您正在写部分翻译，我们保留评估实际工作的权利。
• 如果您明显无法正确使用翻译的源语言写作，您的贡献将被拒绝。
• 如果翻译是通过GitHub提供的，则必须是合并的拉取请求
• 合并请求必须在过去14天内合并。
• 自己的项目更新可以直接提交，无需提交请求。提交不得超过14天。
• 您的GitHub用户名必须与utopian的用户名相匹配。如果没有，您必须在您的GitHub配置文件中添加您的utopian用户名。
• 您必须包括所有可能的细节以检查您的翻译和您翻译过的工具。
• 如果审查员能够识别出最新的翻译质量更好，那么将接受来自不同作者的相同翻译。
• 如果提供的翻译显然有超过20%是机器翻译的或者质量低下，将被拒绝。
• 作为有效的贡献，校对在utopian中是不可接受的。
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

Graphics Rules

• This category is meant only for graphics/videos/motion graphics that you have realised for an open source project.
• The contribution must be a direct result of your own work. It is strictly prohibited to modify other people’s work/assets or use a template and claim it as yours.
• T-shirts and merchandising are generally not valid contributions in Utopian.
• You must include every possible detail in your contributions to verify the work is done by you.
• A contribution must contain the final file of your work, sample of the work, applications of your work, comparison to the existing product, and benefits of your work to the project owner.
• Graphics contributions can be delivered in .psd, .ai, .cdr or any other universally accepted file format except logo designs. Those must be delivered in a vector file (e.g. .eps/.svg/.pdf) for flexibility and scalability, and .png file format.
• Logo design contributions must contain the actual logo (logomark/logotype), the logo in a form of an icon, logo variations in terms of size and colour (monochrome and full-colour versions). You can see some examples of good contributions here, here, and here.
• Any text or fonts must be converted into shapes or “outlined”.
• You must provide credit to all third-party images/assets you have used in your contribution and make sure that you have permission to use them for commercial use. (images, videos, fonts, 3D models etc.)
• Intro videos are acceptable only if the project has already had an intro video before and your contributed video is of a better quality.
• It is highly recommended that you promote your work to the project owner.
• Banners, header images and other assets for use on social media platforms are not valid contributions at the moment.
• Designs are preferred to be in a vector format unless the project owner specifies a different format.
  Not respecting the rules will either give you lower votes or your contribution won't be accepted.

Graphics规则

• 此类别仅用于您为开源项目贡献的图片/视频/动态图片素材。
• 贡献必须是你自己工作的直接结果。严禁修改其他人的工作/资产或使用模板并将其声明为您的模板。
• T恤和商品推销通常不是Utopian的有效贡献。
• 您必须在您的贡献中包含所有可能的细节以确认工作是由您完成的。
• 贡献必须包含工作的最终文件，工作范例，工作申请，与现有产品的比较以及工作对项目的拥有者的利益。
• 图片素材贡献可以以.psd，.ai，.cdr或任何其他普遍接受的文件格式（徽标设计除外）提供。这些必须以矢量文件（例如.eps / .svg / .pdf）形式提供，以提高灵活性和可伸缩性，以及.png文件格式。
• 标志设计贡献必须包含实际的标志（标志标志/标识），标志以图标的形式，标志在尺寸和颜色（单色和全彩版）方面的变化。你可以在这里和这里看到一些很好的贡献。
• 任何文字或字体必须转换成形状或“outlined”。
• 您必须向您在贡献中使用的所有第三方图片/资产提供授信，并确保您有权将其用于商业用途。 （图像，视频，字体，3D模型等）
• 只有当项目之前已经有一个介绍视频，并且您提供的视频质量更好时，才能接受介绍视频。
• 强烈建议您将工作推给项目拥有者。
• 在社交媒体平台上使用的横幅，标题图片和其他资源目前无效。
• 除非项目所有者指定不同的格式，否则设计优先采用矢量格式。
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

Analysis Rules

• This category is meant only for providing a data analysis you have generated for an Open Source project.
• You must include the results of your analyses and the reasons why you have generated them.
• You should include example scripts which generated the results for your analysis, if applicable, or any information on how the data was generated.
• Recurring analyses that are obviously script generated will lead to a lower vote.
• If you are not pasting the entire analysis here you must provide public links to it.
• Results of the analyses, in the form of charts or tables are mandatory in this category.
  Not respecting the rules will either give you lower votes or your contribution won't be accepted.

Analysis规则

• 此类别仅用于提供您为开源项目生成的数据分析。
• 您必须包含分析结果以及生成它们的原因。
• 如果适用，您应该包括生成分析结果的示例脚本，或者有关如何生成数据的任何信息。
• 明显由工具脚本可以反复生成的分析会导致较低的投票率。
• 如果你没有在这里粘贴整个分析，你必须提供公共的链接。
• 分析结果以图表或表格的形式在此类别中是强制性的。
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

Visibility Rules

• This category is meant only for providing results of online social engagement, ads and similar for an Open Source project.
• Promotions done on chats (e.g. Whatsapp, Telegram and similar) won't be accepted as valid contributions.
  Valid contributions to the visibility category are paid search engine and display ads placement; paid social media ads; Thunderclap campaigns and posts to social media accounts with over 10,000 unique followers.
• You must have reached at least an audience of 5000 people.
• You must include links and proofs of the visibility effort you made and write down the results.
• You must provide a clear way to recognise you are the author of the social effort, by matching your Steem/Utopian account with the one on the social platforms or by using any other field to immediately verify that.
  Not respecting the rules will either give you lower votes or your contribution won't be accepted.

Visibility规则

• 此类别仅用于提供开源项目的在线社交活动，广告和类似活动的结果。
• 在聊天中完成的促销活动（例如Whatsapp，Telegram和类似活动）不会被视为有效贡献。
  对可见性类别的有效贡献是付费搜索引擎和展示广告展示位置; 付费社交媒体广告; Thunderclap campaigns和发布到有至少10,000名粉丝的社交媒体帐户。
• 您必须达到至少5000人的关注。
• 您必须包含您所做的可见性工作的链接和证明，并写下结果。
• 您必须提供一种清晰的方式，通过将您的Steem / Utopian帐户与社交平台上的帐户进行匹配，或通过使用任何其他字段来立即验证您是否是社交努力的作者。
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

Documentation Rules

• Only merged Pull Requests on the official repository will be accepted or on a fork as long as the fork is not just a mirror of the original one.
• This category is meant only when working on the Official documentation of an Open Source project.
• If your username on Github does not correspond to the Utopian username you must use the "Name" field in the Github settings and enter there your Utopian/Steem username to verify you are the author.
• Documentation category is meant only for the official project documentation. Use the Tutorials category if this is not the case.
• If you are not pasting the entire documentation here you must provide public links to it.
• You must link Pull Requests you have submitted on Github for the official documentation using the functionality provided in the editor.
  Not respecting the rules will either give you lower votes or your contribution won't be accepted.

Documentation规则

• 只有在官方库上已经合并的Pull Request才会被通过，或者在分支上且不是原始库的镜像。
• 此类别仅用于开源项目的官方文档。
• 如果您在Github上的用户名不符合Utopian用户名，您必须使用Github设置中的“Name”字段并输入您的Utopian / Steem用户名以验证您是作者。
• 文件类别仅用于官方项目文件。 如果不是这种情况，请使用教程类别。
• 如果您不粘贴整个文档，您必须提供公共链接。
• 您必须使用编辑器中提供的功能，将您在Github上提交的Pull Request链接为官方文档。
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

Tutorial Rules

• Tutorials must be technical instructions that teach non-trivial aspects of an Open Source project.
• Design or video editing related tutorials, gameplay, simple on-screen instructions, ubiquitous functions (Save, Open, Print, etc.) or basic programming concepts (variables, operators, loops, etc.) will not be accepted.
• Your contribution can be rejected if the moderator provides a link to another tutorial that covers the same topic better.
• Machine translated tutorials will be rejected.
• You must include the entire tutorial in the Utopian post.
• If you include a video covering the full tutorial, use the Video Tutorial category. You can not share the same tutorial in both categories.
• If you create a GitHub repository with additional material (like code samples), make sure to choose the repository of the project your tutorial is about and not your own repository. You can provide links to your repository in your post.
  Not respecting the rules will either give you lower votes or your contribution won't be accepted.

Tutorial 规则

• 教程必须是教授开源项目并不容易学会或者理解的技术指导。
• 不接受设计或视频编辑相关教程，玩法，简单的屏幕指令，无处不在的功能（保存，打开，打印等）或基本编程概念（变量，操作符，循环等）。
• 如果审查员提供了另一个涵盖同一主题的教程的链接，您的贡献可能会被拒绝。
• 机器翻译的教程将被拒绝。
• 您必须将整个教程全部纳入utopian文章。
• 如果您包括一个涵盖完整教程的视频，请使用视频教程类别。你不能在这两个类别中共享相同的教程。
• 如果您使用其他材料（如代码示例）创建GitHub库，请确保选择您的教程所涉及的项目的库，而不是您自己的代码库。您可以在您的帖子中提供指向您代码库的链接。
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

Video Tutorial Rules

• Video Tutorials must be technical instructions that teach non-trivial aspects of an Open Source project.
• Design or video editing related tutorials, gameplay, simple on-screen instructions, ubiquitous functions (Save, Open, Print, etc.) or basic programming concepts (variables, operators, loops, etc.) will not be accepted.
• Your contribution can be rejected if the moderator provides a link to another tutorial that covers the same topic better.
• A personal introduction should be included in the video [SOFT]
• Video Tutorials using a machine voice will be rejected.
• The video and audio recording must be in HD (min. 720p).
• You must host the video on YouTube or DTube and embed it in your post.
• The video can not be older than 14 days.
• If you provide a text version of your tutorial, you need to include it or a link to it in your post. You can not submit a separate contribution in the Tutorial category.
• If you create a GitHub repository with additional material (like code samples), make sure to choose the repository of the project your tutorial is about and not your own repository. You can provide links to your repository in your post.
  Not respecting the rules will either give you lower votes or your contribution won't be accepted.

Video Tutorial规则

• 视频教程必须是教授开源项目并不容易学会或者理解的技术指导。
• 不接受设计或视频编辑相关教程，玩法，简单的屏幕指令，无处不在的功能（保存，打开，打印等）或基本编程概念（变量，操作符，循环等）。
• 如果审查员提供了另一个涵盖同一主题的教程的链接，您的贡献可能会被拒绝。
• 个人介绍应包含在视频中[SOFT]
• 使用机器语音的视频教程将被拒绝。
• 视频和音频录制必须为HD（最低720p）。
• 您必须在YouTube或DTube上放置视频并将其嵌入到您的帖子中。
• 视频不能超过14天。
• 如果您提供了教程的文本版本，则需要在文章中包含该文本或链接。您无法在教程类别中提交单独的贡献。
• 如果您使用其他材料（如代码示例）创建GitHub库，请确保选择您的教程所涉及的项目的库，而不是您自己的代码库。您可以在您的帖子中提供指向您代码库的链接。
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

Copywriting Rules

• This category is meant only for showing copywriting work you have completed for an Open Source project.
• Linking pull requests from Github is encouraged, but not required if not applicable.
• You must be the author of the copywriting work and provide a clear way to verify that.
• Read the official Wikipedia explanation for what acceptable Copywriting work is.
  https://en.wikipedia.org/wiki/Copywriting
  Not respecting the rules will either give you lower votes or your contribution won't be accepted.

Copywriting规则

• 此类别仅用于显示您为开放源代码项目完成的文案撰写工作。
• 鼓励链接来自Github的Pull Request，但如果不适用则不需要。
• 您必须是撰稿工作的作者，并提供一个明确的方式来验证。
• 阅读正式的维基百科解释什么是可以接受的文案工作。
  https://en.wikipedia.org/wiki/Copywriting
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

Blog Post Rules

• You must provide an original and unique editorial content of very high quality, not only news found on the web or general thoughts.
• Blogs must be strongly related to the promotion and development of an open-source project.
• Blogs must have a unique and consistent format. Posts must be part of a series and contain links to previous parts.
• The first blog post of a series, must contain clear explanations and expectations about the series.
• Blog posts must provide detailed content and overviews related to the open-source projects.
• Images, screenshots, links and examples are not necessary but preferred.
  Not respecting the rules will either give you lower votes or your contribution won't be accepted.

Blog Post 规则

• 您必须提供非常高质量的原创和独特编辑内容，而不仅仅是网络上发现的新闻或一般想法。
• 博客必须与推广和开发一个开源项目密切相关。
• 博客必须具有独特和一致的格式。 帖子必须是一系列的一部分，并包含前几部分的链接。
• 一系列的第一篇博客文章必须包含关于该系列的明确解释和期望。
• 博客文章必须提供与开源项目相关的详细内容和概述。
• 图片，屏幕截图，链接和示例不是必需的，但是提供会更好。
  不尊重规则将会给你更低的票数或者你的贡献不被接受。

---

我发过未通过的文章

文章地址	审查员给出的不通过原因	对应规则
Data too long for column 'raw' when insert into sbds_core_blocks table	Your contribution cannot be approved because it is a duplicate.	Bug Hunting Rules第9条
Out of range value for column min_to_receive in sbds_tx_limit_order_creates table	1. The repo selected Doesnt have a license File; 2. It seems like you are pushing digits out of the bound to create this bug. Although realistic speaking someone entering 18125000000.0 to transfer is not possible.I'm not saying its never possible, It May occur. But it seems like you are trying to Overflow the Decimal buffer.	1. Github Repository 章节第一条 2.第二条原因我并不认可，然而英文不好，惧怕去争论
SteemMysql -- Yet another SBDS service	大致上是认为我的这个不算是贡献或者是选错了分类	没有找到对应的章节（花钱搭建公共服务如果不算贡献我也不知道该怎么说了，我猜测可能写一篇类似 这样的blog 才有可能会被通过吧）
TypeError: 'NoneType' object is not subscriptable	BUG未重现，以及不是官方库，没提供具体版本	对应 Bug Hunting Rules 第7、8条
Need to adjust the password verification order	Your contribution cannot be approved because it is not as informative as other contributions.	未知，可能是英文太差，老外没看懂写的是什么吧。。。
Fix ReviewBookmarks Chrome Extension conflicts with some sites UI	Bug Fixes for your Own Projects will not be accepted, unless the Bugs were caused by third party dependencies.	Development Rules 第9条
The tutorial of Review Bookmarks Chrome Extension.	It is a simple do as i do tutorial and not admissible under utopian rules. Check rules for tutorial category.	Tutorial Rules 第一条。不过我之前的用户对我开发的扩展界面的部分操作有疑问，我认为并不是对于所有人都是一个simple do

以上就是我没有通过审核的帖子，希望与大家共勉！主要就是好好的看规则，可以节省下时间。毕竟我一篇utopian帖子至少花费3--4小时。

---

感谢你的阅读，我是中文区见证人之一，欢迎通过 SteemConnect 来给我投票，或者打开 https://steemit.com/~witnesses 页面，输入 ety001 进行投票。

中文区的见证人目前有：
支持一下他们（按字母顺序），一人可以有30票：

• Hive account@abit ｜ 投票
• Hive account@bobdos｜ 投票
• Hive account@ety001｜ 投票
• Hive account@justyy ｜投票
• Hive account@skenan ｜投票

---

Thank you for reading. I'm a witness. I would really appreciate your witness vote! You can vote by SteemConnect. Or open https://steemit.com/~witnesses page, input ety001 to vote.