查看文件交換文件審查其他人的加載項/腳本需要很長時間（特別是如果有任何問題）。 一個大問題是文件交換/JMP 插件的工作方式，但這是一個不同的討論。 一些事情要考慮：
- 我們應該嗎嘗試定義某種大綱 在瀏覽文件交換文件時應該審查什麼？
- 我們是否應該有一些指導方針用戶在接受文件之前必須遵守哪些要求？
- 應該有關於用戶如何發布他們的文件的說明嗎？
- 公開審核流程步驟，以便用戶了解必須遵守的內容和正在檢查的內容。
- 我還會在文件交換部分添加一些免責聲明，即所有加載項的使用均由用戶因為審查過程不會抓住一切。
如果您安裝/使用插件，有很多事情會破壞您的 JMP 體驗。 像 Clear Symbols、弄亂命名空間、使用 Quit/Exit 以及在我看來最煩人的弄亂 Preferences 之類的事情。
以下是我想到的一些不應該被允許的事情的小清單：
- 無名稱空間污染（使用此處/窗口/框或匿名名稱空間...）
- 沒有清晰的符號/清晰的全局
- 除非是加載項的目的，否則不要觸及用戶的偏好
- 在用戶清楚知道的情況下，無法連接到 JMP 外部的服務（請求）
- 不退出/退出
- 不要將腳本直接添加到加載項/工具欄，因為它是審查的噩夢。 所有腳本都應位於加載項安裝期間安裝的 .jsl 文件中
- 如果加載項被添加到除加載項之外的現有菜單，則必須明確它是自定義加載項。
- 如果安裝工具欄不要弄亂現有的工具欄並始終添加自定義。
- 避免啟動和退出腳本
- （沒有不能審查的加密代碼，意味著必須向審查者提供密鑰以檢查代碼
回复：審查文件交換文件雖然其中很多聽起來像是最佳實踐，但我擔心這裡的用戶社區不夠大，無法支持這些限制，這意味著永遠不會提交許多加載項或腳本。我認為我們可以問用戶他們正在做這些事情中的哪些，並且至少要清楚如果有人使用腳本可能會發生什麼。 也許是新帖子模板中的內容？
回复：審查文件交換文件首先，感謝您開始討論有關加載項的問題。
@jthi我同意你所有的陳述。 是的，我確實認為我們應該提供一組必須滿足的準則才能提交加載項。 是的，我們應該提供審核過程的解釋。 如果用戶不願意遵守準則或不願意花時間來滿足準則，我可以犧牲該加載項的發布。 我寧願開發一個用戶對加載項具有更高信任度的庫。
你已經提供了一個很好的清單，可以用來啟動指南。 我可以與我們的作者一起為指南和審查過程開發一篇知識文章，以及關於使用所提供的任何插件的免責聲明。
正如您所說，審查加載項是一項非常重要的任務。 你對複習有什麼建議？ 這是您（超級用戶）會做的任務嗎（可能除了我可以招募的任何 JMP 員工之外）？ 審查是否僅包括驗證準則，還是應該採取其他步驟？ 有興趣聽聽其他想法。
加載項只是文件交換的一部分。 我們為這個庫所做的決定也可能適用於腳本和示例數據。
對於 2023 年，我們希望開始對社區的每個部分進行更深入的審查，以確定所有權、設計、功能等。因此，請告訴我們您認為哪些改進將使文件交換（或僅添加-ins) 以便我們可以進一步討論並構建我們的路線圖。
謝謝。
回复：審查文件交換文件我一直在與@Wendy_Murphrey和@_jr使用兩個最近提交的加載項開發流程：快速選擇工具欄和圖形生成器工具欄。
根據我們的評論，以下是一些注意事項：
- 啟動了一個模板以在提交之間提供更多的一致性，並希望能夠更輕鬆地找到有關加載項的相關信息。 我們沒有修改原始帖子的內容以與模板保持一致。
- 雖然我們安裝並檢查了相關文章中所述的一些基本功能，但我們沒有進行測試。 我們認為測試超出了審閱者的範圍。
- 掃描代碼以驗證它是否符合準則，即它是否修改了用戶首選項，是否調用操作系統或外部服務等。代碼審查時間約為 15 分鐘。
- 除非絕對必要，否則不要超過 2 條評論。 第一次審查可能會更加嚴格，並導致插件被退回給作者。 第二次審查是為了確保在第一次審查中發現的任何重大違規行為都已得到糾正（並且沒有引入新的違規行為）。 我們不想讓提交加載項的過程負擔過重並阻礙參與。
我們將記錄我們在審查代碼時採取的步驟，作為其他審查者的資源。
我們的下一步是把我們從這次迭代中學到的東西應用到另一個請求中。
如果您有任何問題，請告訴我。 謝謝。
