查看文件交换文件审查其他人的加载项/脚本需要很长时间（特别是如果有任何问题）。 一个大问题是文件交换/JMP 插件的工作方式，但这是一个不同的讨论。 一些事情要考虑：
- 我们应该吗尝试定义某种大纲 在浏览文件交换文件时应该审查什么？
- 我们是否应该有一些指导方针用户在接受文件之前必须遵守哪些要求？
- 应该有关于用户如何发布他们的文件的说明吗？
- 公开审核流程步骤，以便用户了解必须遵守的内容和正在检查的内容。
- 我还会在文件交换部分添加一些免责声明，所有加载项均由用户因为审查过程不会抓住一切。
如果您安装/使用插件，有很多事情会破坏您的 JMP 体验。 像 Clear Symbols、弄乱命名空间、使用 Quit/Exit 以及在我看来最烦人的弄乱 Preferences 之类的东西。
以下是我想到的一些不应该被允许的事情的小清单：
- 无名称空间污染（使用此处/窗口/框或匿名名称空间...）
- 没有清晰的符号/清晰的全局
- 除非是加载项的目的，否则不要触及用户的偏好
- 在用户清楚知道的情况下，无法连接到 JMP 外部的服务（请求）
- 不退出/退出
- 不要将脚本直接添加到加载项/工具栏，因为它是审查的噩梦。 所有脚本都应位于加载项安装期间安装的 .jsl 文件中
- 如果加载项被添加到除加载项之外的现有菜单，则必须明确它是自定义加载项。
- 如果安装工具栏不要弄乱现有的工具栏并始终添加自定义。
- 避免启动和退出脚本
- （没有不能审查的加密代码，意味着必须向审查者提供密钥以检查代码
回复：审查文件交换文件虽然其中很多听起来像是最佳实践，但我担心这里的用户社区不够大，无法支持这些限制，这意味着永远不会提交许多加载项或脚本。我认为我们可以问用户他们正在做这些事情中的哪些，并且至少要清楚如果有人使用脚本可能会发生什么。 也许是新帖子模板中的内容？
回复：审查文件交换文件首先，感谢您开始讨论有关加载项的问题。
@jthi我同意你所有的陈述。 是的，我确实认为我们应该提供一组必须满足的准则才能提交加载项。 是的，我们应该提供审核过程的解释。 如果用户不愿意遵守准则或不愿意花时间来满足准则，我可以牺牲该加载项的发布。 我宁愿开发一个用户对加载项具有更高信任度的库。
你已经提供了一个很好的清单，可以用来启动指南。 我可以与我们的作者一起为指南和审查过程开发一篇知识文章，以及关于使用所提供的任何插件的免责声明。
正如您所说，审查加载项是一项非常重要的任务。 你对复习有什么建议？ 这是您（超级用户）会做的任务吗（可能除了我可以招募的任何 JMP 员工之外）？ 审查是否仅包括验证准则，还是应该采取其他步骤？ 有兴趣听听其他想法。
加载项只是文件交换的一部分。 我们为这个库所做的决定也可能适用于脚本和示例数据。
对于 2023 年，我们希望开始对社区的每个部分进行更深入的审查，以确定所有权、设计、功能等。因此，请告诉我们您认为哪些改进将使文件交换（或仅添加-ins) 以便我们可以进一步讨论并构建我们的路线图。
谢谢。
回复：审查文件交换文件我一直在与@Wendy_Murphrey和@_jr使用两个最近提交的加载项开发流程：快速选择工具栏和图形生成器工具栏。
以下是根据我们的评论得出的一些注意事项：
- 启动了一个模板以在提交之间提供更多的一致性，并希望能够更轻松地找到有关加载项的相关信息。 我们没有修改原始帖子的内容以与模板保持一致。
- 虽然我们安装并检查了相关文章中所述的一些基本功能，但我们没有进行测试。 我们认为测试超出了审阅者的范围。
- 扫描代码以验证它是否符合准则，即它是否修改了用户首选项，是否调用操作系统或外部服务等。代码审查时间约为 15 分钟。
- 除非绝对必要，否则不要超过 2 条评论。 第一次审查可能会更加严格，并导致插件被退回给作者。 第二次审查是为了确保在第一次审查中发现的任何重大违规行为都已得到纠正（并且没有引入新的违规行为）。 我们不想让提交加载项的过程负担过重并阻碍参与。
我们将记录我们在审查代码时采取的步骤，作为其他审查者的资源。
我们的下一步是把我们从这次迭代中学到的东西应用到另一个请求中。
如果您有任何问题，请告诉我。 谢谢。
