各位朋友：
编程开发版始终希望为各位开发者打造一个开放友好的讨论空间。问答类内容在编程开发版占据较多的比重，是编程开发版版块内容里较为重要的一部分。我们现结合近期的实际情况，拟对编程开发版的问答类内容作相应的限制，限制将涵盖 提问帖的提问内容 与 回答者的回答内容。
考虑到编程开发版从未对此类内容做过硬性限制，贸然进行修改不符合编程开发版的惯例与版块调性，我们决定拟于现在起正式向各位征集此次修改的相关意见，且计划于8月31日将相关内容并入版块规定内并正式生效。
涉及到本次内容限制修订的内容包含如下部分：
对提问帖的提问内容做具体限制，提问帖中均应当包含新限制规定中要求的必要项目对回答内容的语言与导向等做具体限制
以下是对本次限制修订常见问题的具体解释，欢迎回复本帖提出意见或建议。
1. 此次限制修订后，发布提问帖需要注意什么？提问帖内必须包含什么？
在本次修订后，发布提问帖时，提问者须审查提问帖的内容：
确认自己是否查阅过论坛已有的内容，此问题是否为常见问题，此问题能否通过已有内容能否解决提问帖标题和内容内必须注明API类型（如Forge、Fabric、Spigot、Paper等）和游戏版本（如1.12.2、1.16.5-1.19等），除非能够根据提问内容可用合理的方式推理出与环境、游戏版本无关提问帖的标题和内容应当能够说明自己最终的开发目的，在内容里说明的方式应当尽量详细，能够让大多数人理解，如问题的内容在标题内确实难以用较短的语句表述，须在标题尽量说明问题的症状和期望的结果提问内容内必须详细说明问题的复现方式，所提及的复现方式须在提问者力所能及的范围内，确保大概率能够被他人复现提问内容须能够体现提问者对此问题所作出的尝试，以及这些尝试最终的结果提问内容必须态度友好和善，且语句通顺流畅
如违反上述规则，将予以下沉处理并通知限期修改，超时仍未能完成修改将予以删除处理，并视情况扣除对应数量的金粒（0金粒~50金粒）。
如提问内容显然没有修改正常的可能，将直接予以删除处理，并视情况扣除对应数量的金粒（0金粒~60金粒）。
如违反第六条中的“友好和善”一项，将视情况附加相应的处罚。
下面是对具体的判例与对其处理结果的解释：
标题 【插件开发问题】求教配置文件无法读取
内容 我在开发插件，希望读取自己的配置文件，但是我不知道怎么做，有没有代码可以参考？
预期处理结果：直接删除提问帖，并根据实际情况扣除一定的金粒
处理解释：
大部分的插件开发教程均有对配置文件的读取的章节，论坛现有的常见教程均能作为内容参考，提问者的问题内容无法看出其查阅过相关内容提问者帖子内没有注明API类型（如Paper、Spigot、Nukkit等），没有注明游戏版本（如1.12.2等），配置文件的读取问题在不同版本内可能会存在不同的问题（例如1.9之前的版本可能读取Unicode符号会存在问题，但提问者没有指明具体版本，如果有此类需求，回答者无从下手给予提醒与帮助），提问内容无法推理出此问题与API类型和游戏版本无关，故缺失此项必要内容读取配置文件是一个非常大的问题话题，如果提问者不说明具体的目的，那么回答者没有办法指引提问者使用对应的方式读取配置文件，无法得知读取的配置文件究竟是什么类型的数据，也无法得知读取的配置文件是config.yml还是其他配置文件，读取的配置文件是否为yaml文件，提问者均未说明与解释，故此处标题和内容均缺失最终开发目的此提问帖直接向他人索取对应的代码，从内容内无法看出其对此问题做出的尝试，结合处理解释第一条，基本断定此提问内容为纯粹的伸手索取内容此内容从内容上看，很难有被提问者进一步完善的可能性
下面是对上述限制项目的常见问题的解释：
Q1：如果提问的问题论坛内确有相关提问，提问内容与现有某一帖子重复怎么办？是否意味着本次修改禁止了重复提问？
A：第一条规定主要针对的是新人常见提问，部分提问内容在版块内存在显而易见的解决方案，此处限制主要针对的是此类内容。这条限制并不意味着处罚重复提问，重点在于引导提问者多加查阅现有资料。如各位朋友遇到了版块内已经有的重复提问帖，在回复中回复其相应内容即可。如果遇到的内容是各个教程都有的常规内容，可以举报。
Q2：对于第二条规定的不需要标注API类型和版本的情形，什么叫做“能够用合理的方式推导出不需要标注”？
A：通常提问内容都需要针对具体版本而定，但有些诸如问题本身涉及跨版本、各个版本都有且肯定没有被修改过的内容等，则不需要标注版本。对于某些源自NMS或者Mojang官方设计的某些机制的问题，此类问题如果无论什么环境均存在，则不需要标注API类型。
Q3：什么是API类型？什么是版本？对于使用了诸如TabooLib开发的插件的问题需不需要标注TabooLib和它的版本？Architectury算不算具体的API类型？如果依赖了Paper的jar文件但开发时未使用Paper的API应当标注为Bukkit、Spigot还是Paper？Mod与插件的依赖需不需要标注API类型和版本？启动器、工具类网站等与Mod和插件无关的软件开发和使用问题需不需要标注API类型和版本？
A：此处规定的API类型和版本以便于其他开发者了解问题产生的具体环境为主要导向。
如果问题造成的环境里依赖了其他API类的Mod或者插件，也应当一同标出，在内容里应当提及与造成问题有关的所有可能的API类型和其对应版本，除非确实没有必要。
如果存在诸如Paper、Spigot或BukkitAPI标注的争议问题，只要能说明问题，任意标注方式均可。TabooLib和Architectury可以视作单独的API类型，以能够清晰表述具体环境为准。
如果是诸如启动器等工具的开发过程中，API类型尽可能标注为开发语言、开发SDK等，以便于他人理解为主。此类工具类软件的开发过程中未涉及具体MC版本的问题，可以选择不标注版本。
其他此处未提及的情况参照上述方向，以具体情况为准。
Q4：最终的实际开发目的、复现方式不便透露怎么办？
A：此类情况需要提问者抽象出一个能够被大家理解的一般情况。例如某个插件属于某个服务器群组的具体情况，提问者需要将此问题从该场景中提取成一般情况下的问题。
Q5：如果我不了解某个API，我想问问对应的API是什么算不算伸手？比如BukkitAPI下我不知道玩家钓鱼是什么事件，发帖提问这个事件的名字算伸手吗？
A：看具体的情形。如果此API确实不是常见的API，从提问中能够看出提问者“试图寻找过此API，但是没有得到答案”，能够体现出提问者对这件事情有思考的成分，而不是遇到问题直接伸手提问，则不属于违规。
一句话询问事件类型的帖子视具体情况处理，如果寻找的内容确实比较难想或不常用，则不属于违规。
Q6：我不知道应当怎样描述最终的开发目的，我能直接说“我想做某某Mod/插件的那种效果”之类的对比性描述吗？
A：如果所提及的对象是众所周知的东西则不属于违规，例如开服的服主都知道的Essentials插件，或Mod玩家常用的JEI等。如果所提及的内容在圈内有较高认可度的解释也不属于违规，例如“自动砍树”指的是“玩家砍掉一个原木方块，就能让整棵树的所有原木方块全部被砍下掉落为对应物品”这件事具有较高认可度。
如果所提及的对象可能有些人不懂，或者对象为付费作品，那应当在贴内用截图等方式说明效果应该是什么样子，而不是引导回答者下载对应作品自行查看效果。
2. 此次限制修订后，回答时需要注意什么？必须包括什么？
回答必须包含的内容有：
对问题本身有帮助的内容（如造成此问题原因的解释，此问题可行的解决方式，有用的资料和思路等，合理即可）友好和善的态度，语句通顺流畅
违反将视情况给予扣分、发卡等处理。
下面是对具体的判例与对其处理结果的解释：
回答内容 你这种属于完全不会就在这里做，建议不要再做这个了，你做不出来
预期处理结果：根据实际情况扣分与发卡
处理解释：
任何人都有对自己不理解的编程问题提问的权力，任何人都有从完全不懂到逐渐理解的过程，此类劝退内容违反了编程开发版版块规定所述的“友善发言”、“友好讨论”和“真诚回答”的基本原则在实际处理时，如提问者发言存在严重不友好情况在先，则只做一定的扣分处罚，如提问者没有不友好的言论，则处罚倾向于从重处理
下面是对上述限制项目的常见问题的解释：
Q1：如果发现提问者提问的内容思路与方向完全错了，或者提问者提问的实现方式明显不是最佳方案，这样做浪费时间吃力不讨好，我能劝退吗？
A：如果理由足够充分则可以，但是要简要说明一下原因与可行的方向等有用的内容，以便对这一问题提供一些可行帮助。
Q2：如果我给出了问题的答案，但是提问者坚守了错误的答案，态度强势地不听取我的答案并否认我的合理解释，算不算对方不友好？
A：算。回答者要对提问者的问题抱有一定的尊重，对自己答案负责。同样，提问者也应当对回答抱有感谢，这是版块规定的基本原则之一，也是友善交流中不可或缺的基本礼貌，这会成为处罚时的判定依据。如有相关问题可私聊联系版主或举报帖子内容。
Q3：我发现提问者的编程语言水平明显不足以支撑其开发其提问问题涉及的内容，我能直接让他去多学学对应的编程语言再来吗？
A：如果确实提问者的提问内容暴露了其基础不足，可以用“我从xxx可以看出你对xxx的认知有欠缺，建议多看一下xxx的xxx”一类的有帮助性的话语做引导。如果提问者的问题除去基础不足这一问题外仍有可以回答的价值的话，回答应该仍然以回答提问者提问涉及到的问题为主。即判定以有没有解决问题主要矛盾为主。
Q4：提问帖下的其他人的回复是不是都算回答？如果只是偶然穿插的吐槽是否也要按照“回答”来限制？
A：不必这么拘谨。如果只是偶然的吐槽等内容，只要上下文能够解释得通即可。
如果是显著干扰问答秩序的内容，仍参照以往判例按水贴严格处罚，例如在提问帖下无礼地回复“感谢楼主分享”等。
3. 此次限制修订的目的是什么？是不是意味着今后在编程开发版发言都需要仔细斟酌了？
此次限制修订基于两个方面的考虑：
一方面，一个圈子的活跃需要源源涌入的新人，此次修订中对回答者回答内容的限制是出于对保护新人的目的。在MC开发者中，存在一些掌握较多开发经验和和较高开发技能的开发者，这些开发者的发言往往透露出“你应当理所当然掌握某样技能”的意思，给出的建议从言语中往往带有劝退的含义，对于新人而言有较强的挫败感。实际上，任何人都有由弱变强的资格，对于一个没有接触过这样事物的人来说，出现任何问题都是有可能的，真正的帮助应当是引导其探索解决问题的方法，而不是将其一味拒之门外。另一方面，此次修订同样是对提问者和回答者体验的保护。往往新人提出的问题涵盖面较广，让回答者不知如何下手，如果此类问题需要得到解决，往往需要不断的交流才行，这样对于双方而言都需要消耗大量的时间成本。实际上出现此类现象的提问帖往往最终也不能得到更好的解答，而在于有经验的开发者看来，此类含糊不清的提问帖内容质量都比较“水”，大部分开发者反映对此类内容存在抵触心理，不利于问题的解决。此次修订希望能够通过强制措施引导新人学会正确提问问题，能够有效的把关键内容表达出来，这同样是提升编程技能之路上重要的一环。
限制对提问内容和回答内容的目的绝非是让大家“发言都要仔细斟酌”、“这里不能随便说话”。
正如版规开篇所述，“我们试图建立一个开放友好的氛围, 不希望被奇怪的条框限制”，此次修订的目的重在引导，而非惩罚。在编程开发版内，合理的需求都有商量的余地，底线则是版块规定第一页所述的“基本原则”。编程开发版的版规遵循着基本原则而立，目的是打造友好的氛围，而不是给来到这里的人平添顾虑。只要是愿意友善讨论相关的编程开发技术的人，无论是谁，这里都始终欢迎。
编程开发版始终希望为各位开发者打造一个开放友好的讨论空间。问答类内容在编程开发版占据较多的比重，是编程开发版版块内容里较为重要的一部分。我们现结合近期的实际情况，拟对编程开发版的问答类内容作相应的限制，限制将涵盖 提问帖的提问内容 与 回答者的回答内容。
考虑到编程开发版从未对此类内容做过硬性限制，贸然进行修改不符合编程开发版的惯例与版块调性，我们决定拟于现在起正式向各位征集此次修改的相关意见，且计划于8月31日将相关内容并入版块规定内并正式生效。
涉及到本次内容限制修订的内容包含如下部分：
对提问帖的提问内容做具体限制，提问帖中均应当包含新限制规定中要求的必要项目对回答内容的语言与导向等做具体限制
以下是对本次限制修订常见问题的具体解释，欢迎回复本帖提出意见或建议。
1. 此次限制修订后，发布提问帖需要注意什么？提问帖内必须包含什么？
在本次修订后，发布提问帖时，提问者须审查提问帖的内容：
确认自己是否查阅过论坛已有的内容，此问题是否为常见问题，此问题能否通过已有内容能否解决提问帖标题和内容内必须注明API类型（如Forge、Fabric、Spigot、Paper等）和游戏版本（如1.12.2、1.16.5-1.19等），除非能够根据提问内容可用合理的方式推理出与环境、游戏版本无关提问帖的标题和内容应当能够说明自己最终的开发目的，在内容里说明的方式应当尽量详细，能够让大多数人理解，如问题的内容在标题内确实难以用较短的语句表述，须在标题尽量说明问题的症状和期望的结果提问内容内必须详细说明问题的复现方式，所提及的复现方式须在提问者力所能及的范围内，确保大概率能够被他人复现提问内容须能够体现提问者对此问题所作出的尝试，以及这些尝试最终的结果提问内容必须态度友好和善，且语句通顺流畅
如违反上述规则，将予以下沉处理并通知限期修改，超时仍未能完成修改将予以删除处理，并视情况扣除对应数量的金粒（0金粒~50金粒）。
如提问内容显然没有修改正常的可能，将直接予以删除处理，并视情况扣除对应数量的金粒（0金粒~60金粒）。
如违反第六条中的“友好和善”一项，将视情况附加相应的处罚。
下面是对具体的判例与对其处理结果的解释：
标题 【插件开发问题】求教配置文件无法读取
内容 我在开发插件，希望读取自己的配置文件，但是我不知道怎么做，有没有代码可以参考？
预期处理结果：直接删除提问帖，并根据实际情况扣除一定的金粒
处理解释：
大部分的插件开发教程均有对配置文件的读取的章节，论坛现有的常见教程均能作为内容参考，提问者的问题内容无法看出其查阅过相关内容提问者帖子内没有注明API类型（如Paper、Spigot、Nukkit等），没有注明游戏版本（如1.12.2等），配置文件的读取问题在不同版本内可能会存在不同的问题（例如1.9之前的版本可能读取Unicode符号会存在问题，但提问者没有指明具体版本，如果有此类需求，回答者无从下手给予提醒与帮助），提问内容无法推理出此问题与API类型和游戏版本无关，故缺失此项必要内容读取配置文件是一个非常大的问题话题，如果提问者不说明具体的目的，那么回答者没有办法指引提问者使用对应的方式读取配置文件，无法得知读取的配置文件究竟是什么类型的数据，也无法得知读取的配置文件是config.yml还是其他配置文件，读取的配置文件是否为yaml文件，提问者均未说明与解释，故此处标题和内容均缺失最终开发目的此提问帖直接向他人索取对应的代码，从内容内无法看出其对此问题做出的尝试，结合处理解释第一条，基本断定此提问内容为纯粹的伸手索取内容此内容从内容上看，很难有被提问者进一步完善的可能性
下面是对上述限制项目的常见问题的解释：
Q1：如果提问的问题论坛内确有相关提问，提问内容与现有某一帖子重复怎么办？是否意味着本次修改禁止了重复提问？
A：第一条规定主要针对的是新人常见提问，部分提问内容在版块内存在显而易见的解决方案，此处限制主要针对的是此类内容。这条限制并不意味着处罚重复提问，重点在于引导提问者多加查阅现有资料。如各位朋友遇到了版块内已经有的重复提问帖，在回复中回复其相应内容即可。如果遇到的内容是各个教程都有的常规内容，可以举报。
Q2：对于第二条规定的不需要标注API类型和版本的情形，什么叫做“能够用合理的方式推导出不需要标注”？
A：通常提问内容都需要针对具体版本而定，但有些诸如问题本身涉及跨版本、各个版本都有且肯定没有被修改过的内容等，则不需要标注版本。对于某些源自NMS或者Mojang官方设计的某些机制的问题，此类问题如果无论什么环境均存在，则不需要标注API类型。
Q3：什么是API类型？什么是版本？对于使用了诸如TabooLib开发的插件的问题需不需要标注TabooLib和它的版本？Architectury算不算具体的API类型？如果依赖了Paper的jar文件但开发时未使用Paper的API应当标注为Bukkit、Spigot还是Paper？Mod与插件的依赖需不需要标注API类型和版本？启动器、工具类网站等与Mod和插件无关的软件开发和使用问题需不需要标注API类型和版本？
A：此处规定的API类型和版本以便于其他开发者了解问题产生的具体环境为主要导向。
如果问题造成的环境里依赖了其他API类的Mod或者插件，也应当一同标出，在内容里应当提及与造成问题有关的所有可能的API类型和其对应版本，除非确实没有必要。
如果存在诸如Paper、Spigot或BukkitAPI标注的争议问题，只要能说明问题，任意标注方式均可。TabooLib和Architectury可以视作单独的API类型，以能够清晰表述具体环境为准。
如果是诸如启动器等工具的开发过程中，API类型尽可能标注为开发语言、开发SDK等，以便于他人理解为主。此类工具类软件的开发过程中未涉及具体MC版本的问题，可以选择不标注版本。
其他此处未提及的情况参照上述方向，以具体情况为准。
Q4：最终的实际开发目的、复现方式不便透露怎么办？
A：此类情况需要提问者抽象出一个能够被大家理解的一般情况。例如某个插件属于某个服务器群组的具体情况，提问者需要将此问题从该场景中提取成一般情况下的问题。
Q5：如果我不了解某个API，我想问问对应的API是什么算不算伸手？比如BukkitAPI下我不知道玩家钓鱼是什么事件，发帖提问这个事件的名字算伸手吗？
A：看具体的情形。如果此API确实不是常见的API，从提问中能够看出提问者“试图寻找过此API，但是没有得到答案”，能够体现出提问者对这件事情有思考的成分，而不是遇到问题直接伸手提问，则不属于违规。
一句话询问事件类型的帖子视具体情况处理，如果寻找的内容确实比较难想或不常用，则不属于违规。
Q6：我不知道应当怎样描述最终的开发目的，我能直接说“我想做某某Mod/插件的那种效果”之类的对比性描述吗？
A：如果所提及的对象是众所周知的东西则不属于违规，例如开服的服主都知道的Essentials插件，或Mod玩家常用的JEI等。如果所提及的内容在圈内有较高认可度的解释也不属于违规，例如“自动砍树”指的是“玩家砍掉一个原木方块，就能让整棵树的所有原木方块全部被砍下掉落为对应物品”这件事具有较高认可度。
如果所提及的对象可能有些人不懂，或者对象为付费作品，那应当在贴内用截图等方式说明效果应该是什么样子，而不是引导回答者下载对应作品自行查看效果。
2. 此次限制修订后，回答时需要注意什么？必须包括什么？
回答必须包含的内容有：
对问题本身有帮助的内容（如造成此问题原因的解释，此问题可行的解决方式，有用的资料和思路等，合理即可）友好和善的态度，语句通顺流畅
违反将视情况给予扣分、发卡等处理。
下面是对具体的判例与对其处理结果的解释：
回答内容 你这种属于完全不会就在这里做，建议不要再做这个了，你做不出来
预期处理结果：根据实际情况扣分与发卡
处理解释：
任何人都有对自己不理解的编程问题提问的权力，任何人都有从完全不懂到逐渐理解的过程，此类劝退内容违反了编程开发版版块规定所述的“友善发言”、“友好讨论”和“真诚回答”的基本原则在实际处理时，如提问者发言存在严重不友好情况在先，则只做一定的扣分处罚，如提问者没有不友好的言论，则处罚倾向于从重处理
下面是对上述限制项目的常见问题的解释：
Q1：如果发现提问者提问的内容思路与方向完全错了，或者提问者提问的实现方式明显不是最佳方案，这样做浪费时间吃力不讨好，我能劝退吗？
A：如果理由足够充分则可以，但是要简要说明一下原因与可行的方向等有用的内容，以便对这一问题提供一些可行帮助。
Q2：如果我给出了问题的答案，但是提问者坚守了错误的答案，态度强势地不听取我的答案并否认我的合理解释，算不算对方不友好？
A：算。回答者要对提问者的问题抱有一定的尊重，对自己答案负责。同样，提问者也应当对回答抱有感谢，这是版块规定的基本原则之一，也是友善交流中不可或缺的基本礼貌，这会成为处罚时的判定依据。如有相关问题可私聊联系版主或举报帖子内容。
Q3：我发现提问者的编程语言水平明显不足以支撑其开发其提问问题涉及的内容，我能直接让他去多学学对应的编程语言再来吗？
A：如果确实提问者的提问内容暴露了其基础不足，可以用“我从xxx可以看出你对xxx的认知有欠缺，建议多看一下xxx的xxx”一类的有帮助性的话语做引导。如果提问者的问题除去基础不足这一问题外仍有可以回答的价值的话，回答应该仍然以回答提问者提问涉及到的问题为主。即判定以有没有解决问题主要矛盾为主。
Q4：提问帖下的其他人的回复是不是都算回答？如果只是偶然穿插的吐槽是否也要按照“回答”来限制？
A：不必这么拘谨。如果只是偶然的吐槽等内容，只要上下文能够解释得通即可。
如果是显著干扰问答秩序的内容，仍参照以往判例按水贴严格处罚，例如在提问帖下无礼地回复“感谢楼主分享”等。
3. 此次限制修订的目的是什么？是不是意味着今后在编程开发版发言都需要仔细斟酌了？
此次限制修订基于两个方面的考虑：
一方面，一个圈子的活跃需要源源涌入的新人，此次修订中对回答者回答内容的限制是出于对保护新人的目的。在MC开发者中，存在一些掌握较多开发经验和和较高开发技能的开发者，这些开发者的发言往往透露出“你应当理所当然掌握某样技能”的意思，给出的建议从言语中往往带有劝退的含义，对于新人而言有较强的挫败感。实际上，任何人都有由弱变强的资格，对于一个没有接触过这样事物的人来说，出现任何问题都是有可能的，真正的帮助应当是引导其探索解决问题的方法，而不是将其一味拒之门外。另一方面，此次修订同样是对提问者和回答者体验的保护。往往新人提出的问题涵盖面较广，让回答者不知如何下手，如果此类问题需要得到解决，往往需要不断的交流才行，这样对于双方而言都需要消耗大量的时间成本。实际上出现此类现象的提问帖往往最终也不能得到更好的解答，而在于有经验的开发者看来，此类含糊不清的提问帖内容质量都比较“水”，大部分开发者反映对此类内容存在抵触心理，不利于问题的解决。此次修订希望能够通过强制措施引导新人学会正确提问问题，能够有效的把关键内容表达出来，这同样是提升编程技能之路上重要的一环。
限制对提问内容和回答内容的目的绝非是让大家“发言都要仔细斟酌”、“这里不能随便说话”。
正如版规开篇所述，“我们试图建立一个开放友好的氛围, 不希望被奇怪的条框限制”，此次修订的目的重在引导，而非惩罚。在编程开发版内，合理的需求都有商量的余地，底线则是版块规定第一页所述的“基本原则”。编程开发版的版规遵循着基本原则而立，目的是打造友好的氛围，而不是给来到这里的人平添顾虑。只要是愿意友善讨论相关的编程开发技术的人，无论是谁，这里都始终欢迎。