TL;DR
この意見募集は可決次第【意見募集】技術的要素に関するポリシーの制定での技術的要素に関するポリシーに内包されます.
外部includeにおけるいくつかの問題点(後述)から,外部includeをSCP-JPサンドボックスIIIの専用カテゴリ(以下,custom-componentカテゴリ)のみに制限します.
提案可決後は,6か月の猶予期間を設け,可決前に作成されたすべての外部includeをcustom-componentカテゴリに移動することを努力義務とし,可決後作成されたページは順守義務があるものとします.但し,猶予期間後違反があるページに関してスタッフは修正や機能のオミットを行う可能性があり,その変更が著者の意に沿わないものである場合はポリシー内の変更であれば編集することができるようにします.
外部includeの定義: include構文を用いてincludeを行うページのうち,記述外のサイトからincludeを行うことである.
つまり,
- [[include credit:start]]
- [[include :scp-jp:credit:start]]
は問題ないが
- [[include :scp-jp-sandbox3:credit:start]]
は外部includeとなる.
外部includeには以下のような問題点があります.
- セキュリティ上の問題
- SCP-JPでの管理が不可能(ライセンスを含む)
- Wikijumpでの移行が不可能
順番に説明していきます.
1. セキュリティ上の問題
テクニカルスタッフは,外部includeはセキュリティ上のリスクが高いと考えております.理由として,
外部include元の変更をスタッフ側が感知できないため,内容の変更による
- 悪意のあるコードを埋め込まれたことによる荒らしないしはそれを上回る破壊行為
- NSFWな内容が表示させられるハラスメント行為
などといった可能性が考えられます.これらはサイト外の非サイトメンバーによって行われる行為であるため,現サイトルールでは対応できず,外部includeを使用したユーザーの自己責任という形に帰結します.
2. SCP-JPでの管理が不可能(ライセンスを含む)
外部Wikiのコンテンツは権限管理が行われていないケースもあり,コンテンツ自体が勝手に第三者に書き換えられるというケースもあります.他にもサイト上の設定でライセンス自体が異なる場合もあります.こう言った行為による作品への影響を防ぐため、include元のページはスタッフが管理できるところに置かれている必要があります.
3. Wikijumpでの移行が不可能
スタッフは、当然のことながら外部Wikiのバックアップを取っていません.そのため,Wikijumpが始動した瞬間から外部includeを行っている記事は正常な表示ができないだけではなく,元の表示のソースすら残らず,元の記事の表示に戻すことはできなくなります.
背景/目的
現在,サイト上には他支部サイトを含むSCP-JP関連サイト以外の外部サイトのincludeがかなりの数存在します.これら外部サイトからのincludeの問題点は前述のとおりであり,サイトにおける危険性は計り知れないものかと思います.また,一部テーマ(例えばBHLなど)は,外部include元の更新に追い付かず外観が乱れるといったケースも以前はありました.
この提案は,同時に意見募集を行う【意見募集】技術的要素に関するポリシーの制定の技術的要素に関するポリシーに再挿入される予定です.
詳細
以下提案を行います.
1. サンドボックスIII利用ガイドの新規項: カスタムコンポーネント の追加
下記草案の内容で,custom-componentカテゴリの説明を追加します.
2.各種投稿ガイドの技術的要素に関するポリシーの順守の追記
各種投稿ガイドの投稿前チェックの部分で以下文面を追加します.
N: 内容がtechnical-content-policyを満たしているか確認する
サイト上におけるCSSや構文を含めたページコンテンツ全体におけるポリシーとしてtechnical-content-policyが存在し、すべてのページはこのポリシーに準拠する必要があります。投稿前にこのポリシーに違反する内容がないか確認する必要があります。
以下,ポリシーに規定されている順守すべき内容です。
- サンドボックスIIIのcustom-componentカテゴリ以外からの外部includeを行わない
棄却された場合,可決された側の提案の施行は無期限に延長されます.
結局どうなるのか?
前回の意見募集(【意見募集】技術的要素に関するポリシー制定に関する意見募集)より,制度上かなり緩和されました.
前提
完全に外部の,サイトスタッフが管理できないサイトからのincludeは安全性等の観点から許容できないため,制限が必要である.
↓
付随状況
A: 一方で外部includeは創作に大きく寄与しており,完全に禁止すれば多くのコンテンツに影響がある.
↓
Aの解決案
サイトスタッフが管理できるサイトに一般メンバーが外部includeのソースをコピー・保存できる領域を設け,危険なコードや不安定な動作を確認した際に介入できるようにすれば,この問題は解決する.
↓
今回の提案内容
外部サイトから内容を転載可能なcustom-componentカテゴリをサンドボックスIIIに設ける.メインサイトの同名カテゴリとは違い,このカテゴリは一定数以上メインサイト・サンドボックスIIIで使用されている場合のみ査読後のメインサイトでの投稿が必須となる.
↓
要約
外部サイトに使用したいコンポーネントがあり,しかしその内容をメインサイトにカスタムコンポーネントとして投稿できるほどCSS等の技術に精通していない場合,サイトメンバーはサンドボックスIIIのcustom-componentカテゴリに使用したいコンポーネントをコピーし,そこからincludeできるものである(ファイルストレージのコンポーネント版といえる).
議論について
議論・投票終了予定日: 2023年03月02日 23:59 (2週間)
議論上のお願い
- 質問の際は、一旦賛成か反対の意見を保留してコメントしてください.
- 意見と質問はそれぞれ別のポストに分けてください.
- 複数の質問はそれぞれ別のポストに分けてください.
- 意見の際は賛成か反対かを明確にしてください.
- 質問は一問一答形式で、簡潔に、主語を明確にしてください
- モックの内容に大幅な変更があった場合、意見募集期間の延長やリセットを行う場合があります.
流れ
この意見募集は可決次第【意見募集】技術的要素に関するポリシーの制定での技術的要素に関するポリシーに内包されます.
技術的要素に関するポリシーの新設提案可決後,6か月の猶予期間を設け,可決前に作成されたすべての外部includeをcustom-componentカテゴリに移動することを努力義務とし,可決後作成されたページは順守義務があるものとします.但し,猶予期間後違反があるページに関してスタッフは修正や機能のオミットを行う可能性があり,その変更が著者の意に沿わないものである場合はポリシー内の変更であれば編集することができるようにします.
変更履歴
2023年02月16日: 意見募集期間の延長
----
Tech Cap. of SCP-JP
想像よりも遥かに柔軟な内容ですね。半年間の期間をとるとのことなので現時点での賛否表明はしませんが、とりあえず賛成よりの思考しています。
質問です。
現時点は削除されていますが、提案者の当初のポストには「そのテーマがある程度他者に利用されるならば、メインサイトへの投稿が必須になる」という内容の文言がありました。
提案者には今後後出しする予定の政策が存在しますか?
ご指摘の文言に関して,回答します.
「そのテーマがある程度他者に利用されるならば、メインサイトへの投稿が必須になる」
に関して
上記意見募集ポスト: 一定数以上メインサイト・サンドボックスIIIで使用されている場合のみ査読後のメインサイトでの投稿が必須となる.
草案: SCP-JPメインサイト、SCP-JPサンドボックスIII内で5記事以上にincludeされている場合はカスタムテーマ/ユーザーコンポーネントポリシーに則って、査読提出を行う必要があります
とあるように,査読提出等行っていただくようになります.
提案者には今後後出しする予定の政策が存在しますか?
今のところは,考えておりません.但し,重大な問題が発生した場合には再度意見募集をリセットを行う可能性はあります.
1点質問になりますが,当初のポストというのはどのポストを指されていますでしょうか.
Tech Cap. of SCP-JP
1点質問になりますが,当初のポストというのはどのポストを指されていますでしょうか.
17:11投稿の提案者のポストにあったような 気のせいだったでしょうか
とりあえず回答については承知しました
ありがとうございます
恐らく上記ポストにはそのような文言は載せていなかった気がします......
Tech Cap. of SCP-JP
質問です。
「カスタムコンポーネントの使用と投稿基準」の項について、実効性を欠くのではないかという懸念があります。
- ページ内容の変更
- そのカスタムコンポーネントがあなた以外が使用している場合、大規模な改稿は他人の記事の内容を変更させる可能性があるため、推奨されません。
この文言を見るに、SB3上のカスタムコンポーネントはページ作成者のみならず他のサイトメンバーも記事等に使用できるものと考えられます。
そうしますと、例えば以下のような事例においてページ作成者はガイドに違反する可能性があります。
サイトメンバーAは自己の著作に使用する目的で、SB3上にカスタムコンポーネントを作成した。その後Aは当該カスタムコンポーネントをincludeする記事を下書きも合わせて4ページ作成した。
(1)サイトメンバーBはAに断わることなく当該カスタムコンポーネントを流用し、下書きページを作成した。その結果、当該カスタムコンポーネントは「SCP-JPメインサイト、SCP-JPサンドボックスIII内で5記事」にincludeされていることとなったが、Aはその事実を知らないため査読提出を行っていない。
(2)サイトメンバーCは当該カスタムコンポーネントを使用したいと思ってAに連絡を試みたが、Aは非アクティブになっていたため、CはAと連絡がつかないままに当該カスタムコンポーネントをincludeした記事を作成した。その結果、当該カスタムコンポーネントは「SCP-JPメインサイト、SCP-JPサンドボックスIII内で5記事」にincludeされていることとなったが、Aはアクティブでないため査読提出を行っていない。
「SCP-JPメインサイト、SCP-JPサンドボックスIII内で5記事以上にincludeされている場合はカスタムテーマ/ユーザーコンポーネントポリシーに則って、査読提出を行う必要があ」るという規定は、義務を負うページ作成者の予期しない時点で要件を満たす可能性があります。その場合、運用によってはページ作成者はガイド違反者として処罰の対象となる危険があります。或いは、誰もこの事態に気付かないか、ページ作成者が査読提出を申請しうる状態にないために、5記事以上にincludeされているけれども査読提出されないカスタムコンポーネントが放置されるということも考えられます。
これらの懸念点についてサイトスタッフのご意見を伺いたいです。
質問です。
「カスタムコンポーネントの使用と投稿基準」にて、5記事以上他の記事にインクルードされるとカスタムテーマポリシーに基づいた査読が義務付けられるとされていますが、このルールを設置している意図はなんでしょうか?
提案者は
外部サイトに使用したいコンポーネントがあり,しかしその内容をメインサイトにカスタムコンポーネントとして投稿できるほどCSS等の技術に精通していない場合,サイトメンバーはサンドボックスIIIのcustom-componentカテゴリに使用したいコンポーネントをコピーし,そこからincludeできるものである(ファイルストレージのコンポーネント版といえる).
と語っており、SB3カスタムコンポーネントカテゴリーなら最低限以上の知識を必要とせずにやれると説明しています。
にも拘わらず、記事へのインクルードが増えたからという理由で高い水準のハードルを科せられることになるのはどういう理屈か分かりません。場合によっては他者が沢山インクルードしたおかげで自分に義務が課せられるという道理不明な現象も起きうるでしょう。
結果的に誰もSB3コンポーネントを使わなくなり、記事1つ1つにクソデカ構文を設置するようになるだけな気がするんですが、どういう意図があるのでしょうか。
カスタムテーマポリシーやユザコンポリシーには以下のような規定があります。これらの規定はカスタムコンポーネントの査読申請を妨げる可能性がありますが、これらの規定も本提案と同時に改定されますか?
ユーザーコンポーネントが使用されている
使われていない、また使われる予定のないユーザーコンポーネントの投稿は認められません。ユーザーコンポーネントを投稿するためには、以下の条件を1つ以上満たす必要があります。
- Wikiに既に存在しているページに使われているWikidotシンタックスとほぼ同じ機能を果たし、ユーザーコンポーネント投稿後にその記事のWikidotシンタックスを投稿したユーザーコンポーネントに差し替える予定があること
- ユーザーコンポーネントを使用するページとほぼ同時に投稿する予定であること
- ユーザーコンポーネントを使用するページが、ユーザーコンポーネント投稿から1週間以内に投稿される予定があること
申請者
あなたを含む複数人によって作成されたユーザーコンポーネントである場合は、その全員の許可のもとでのみ申請することができます。
http://scp-jp.wikidot.com/forum/t-15608650#post-5964284
http://scp-jp.wikidot.com/forum/t-15608650#post-5964764
上記2つの質問ですが同懸念点のため一括で返信を行います.
G and B Channelさんの
「SCP-JPメインサイト、SCP-JPサンドボックスIII内で5記事以上にincludeされている場合はカスタムテーマ/ユーザーコンポーネントポリシーに則って、査読提出を行う必要があ」るという規定は、義務を負うページ作成者の予期しない時点で要件を満たす可能性があります。その場合、運用によってはページ作成者はガイド違反者として処罰の対象となる危険があります。或いは、誰もこの事態に気付かないか、ページ作成者が査読提出を申請しうる状態にないために、5記事以上にincludeされているけれども査読提出されないカスタムコンポーネントが放置されるということも考えられます。
に関して,確かにだれも気付くことができない,及び非アクティブ時の対応が漏れていたため下記第1, 2項にて修正いたしました.
indonootokoさんの
「カスタムコンポーネントの使用と投稿基準」にて、5記事以上他の記事にインクルードされるとカスタムテーマポリシーに基づいた査読が義務付けられるとされていますが、このルールを設置している意図はなんでしょうか?
ルールを設置している意図として,
多く使われるようなコンポーネントであれば
- セキュリティ上広範囲に実害が出やすい為
- テーマやユーザーコンポーネントとしてサイトに投稿してもらった方が利益となりうる為
その多く使われるコンポーネントの記事数を5記事と定めただけです.
他者が使用した場合に関しては下記第1項にて,査読自体が高い水準だということに関しては下記第3項にて説明をいたします.
1. カスタムコンポーネントの使用可能条件/使用時の変更
カスタムコンポーネントを他者が使用可能な状態になるための条件を変更します.
カスタムコンポーネントページを作成し,何らかの記事で使用する前にそのページをGoogle Formで報告していただきます.イメージとしては翻訳予約のようなものとなります.
参考: https://forms.gle/YhEccqSpbWAEKqUB8
報告されたカスタムコンポーネントは順次スタッフがセキュリティ上問題ないものかどうかセキュリティチェックを行い,問題ないものであれば脆弱性なしのカスタムコンポーネントとして扱われます.この状態になったものは,ハブもしくはスプレッドシートに記載され,他者が自由に使用できる状態になります.
カスタムコンポーネントを使用する際は,1記事につき1ポストそのページのディスカッションにて使用を報告する義務が生じます.これは,カスタムコンポーネント作者にも当てはまります.
コメントを行っていただく理由として,ListPages等のWikidotに負荷を掛けない手段を用いた被include数の計測を行うためです.
セキュリティチェックでは,スタッフは表示の乱れなどには干渉せず悪意のあるコードが含まれていないかどうか等のチェックにとどまります.もし含まれていた場合はその時点でそのコードは取り除かれそのページのディスカッションにて指摘を行います.
- ページのコメント数が8以上になった状態でセキュリティチェック申請が為されていないカスタムコンポーネントページは,スタッフが確認した時点でセキュリティチェックを行います.
まとめ
カスタムコンポーネントはセキュリティ上問題ないものかどうかセキュリティチェックが行われる.
セキュリティチェックで問題ないと判断された脆弱性なしのカスタムコンポーネントは作者以外の第三者が使用可能である.
----
2. カスタムコンポーネントの査読条件の変更
カスタムコンポーネントの新規作成から査読までの方針の変更を行います.
これまでは,
新規作成後,5記事からのincludeで査読を提出
との方針でした.
今回の変更で
- カスタムコンポーネントページの新規作成
- 使用する前にカスタムコンポーネントページをGoogle Formで報告
- コメント数が8つ以上になり次第,テクニカルスタッフのページレビュー待ちリストに追加.(連絡有り)
- ページレビューで問題ない場合は投稿可能なカスタムコンポーネントとして扱う.(連絡有り)
と変更を行います.
- ページレビューリストに追加されてから査読開始までにページレビュー申請があった場合は申請でのrevisionを元に査読を行い,問題がある場合適宜修正を行います.
- 申請にはGoogle Formを使用して行われます.
- 参考: https://forms.gle/2jrbqPLPQ1TCDRNv5
- ページレビュー申請が無かった場合,査読開始時の最新のrevisionで査読を行い,修正内容に異議を挟むことはできません.
まとめ
カスタムコンポーネント作成後,使用前にセキュリティチェック申請を行う必要があります.
コメントが8以上ある場合,作者にPMなどの手段で通知の上でページレビュー申請を行う必要があります.
期日までに申請がない場合はスタッフ側での修正が行われます.この場合,修正に異議を挟むことはできません.
----
3. 査読の緩和
カスタムコンポーネントにはスタッフ側の想定で3種類に分けられると考えます.
- 他支部or個人wikiで作成されたコードの複製
- 自分が一から作成したテーマ/コンポーネントもしくは他人のコードを複製して作成したテーマ/コンポーネント
- テーマ/コンポーネントに分類されないinclude用ページ
これらに関して細分化した査読に関する条件を提示します.
1. 他支部or個人wikiで作成されたコードの複製
査読に関して,推奨する条件を提示します.これらは,申請時に達成されていると査読完了が速やかに行われる可能性があります.
- ページに使用されているコードのローカライズ
- creditモジュール
- サイドバー位置
- 直リンクの修正
- いくつかのリンクを除き,基本的にはストレージにアップロードし使用する必要があります.
- マニュアルの掲示
- 基本的には,テーマページでよく記述されるtab, table, ヘッダー要素(h1等)を記述
- テーマで特別に追加されている要素の使用事例
これらは,推奨する条件であり,申請時に達成する必要はありません.
2. 自分が一から作成したテーマ/コンポーネントもしくは他人のコードを複製して作成したテーマ/コンポーネント
査読に関して,できる限り達成されていることを推奨します.
- カスタムテーマ/ユーザーコンポーネントの変更制限要素の制限事項の順守
- 直リンクの修正
- マニュアルの掲示
3. テーマ/コンポーネントに分類されないinclude用ページ
基本的には投稿を行うことは考えにくい為,査読に関する条件は存在しません.
まとめ
基本的に,査読に関してかなりの悪印象を抱かれているメンバーが多いと考えます.
査読は,SCP-JP上で違和感なく動作するために行われるチェックのようなものです.そして,ほかのメンバーがもし使用する際にわかりやすくするためのものです.
その為,ある程度リファレンスの提示などでどのような動作が行えるかどうかといったことを示す必要があるなど,いくつかの労力を必要します.ですが,スタッフ側が提出時に求めるのは例えローカライズが不完全であったり,記述されているコードを全く説明ができないとしても査読提出を行うという労力のみです.査読自体を難しいものと捉え忌避する物でなくなってほしいと考えます.
以上の変更3点を草案に反映したうえで,意見募集期間を2週間延長を行います.
また,草案に関して私情により手が付けれる状態でないため一先ず上記変更案の通りに説明が変更される旨ご了承ください.
Tech Cap. of SCP-JP
このポストは投稿ミスです。