前提として、以下をご理解ください。

• このエッセイは質問をするにあたって他のサイトメンバーから回答をより引き出しやすくするためのエッセイです。
• このエッセイは役立つ回答がポストされることを約束するものではありません。あなたの問題が解決することを私は祈っていますが、上手くいかないときもあるでしょう。
• このエッセイは初心者を意識して執筆されています。後述の内容に関連する話として、ある程度の活動経験がある方であれば、望む答えを引き出すために検索ボックスにうち込むと良い単語のいくつかは容易に思い浮かぶでしょう。
• これはガイドではなく、エッセイです。このエッセイに他人を誘導してくださることは幸いですが、この記事の内容を基に他人、特に初心者に高圧的にふるまうのは控えてください。

• ガイドハブ - もしかするとあなたの質問は基本的なことかもしれません。SCP-JPで運用されているガイドラインの一覧はこちら。
• お役立ちリンク集 - 他のサイトメンバーに伝えたいことをまとめたエッセイやデータベースへのアクセスはここから。執筆の方法論の他にも、アノマリー分類ガイド(ACS)などの構文コンポーネントやフォーマット集、特殊オブジェクトクラスやK-クラスシナリオなどをまとめたリストまで。
  • Wikidotのつかいかたエッセイ - ホストサイトであるWikidotのつかいかたについて。
  • 批評をもらうためのエッセイ - 批評がこないというおなやみはここへ。
  • あなたの第一歩のための計画書作り - はじめての作品にチャレンジするときはもしかしたらこのエッセイが助けてくれるかもしれません。
  • 新サイトメンバーのための用語集 - 「先パイが何言ってるか分からない」「○しろまる○しろまるって何?」みたいなおなやみはここへ。

• スタッフからのお知らせ - サイトルールやガイドの変更に代表される重要な連絡が行われているスレッドです。

• Wikidotシンタックス - よく使う構文について。ここに答えが書いてあるような質問はすべきではないでしょう。
• 日本語表現用Wiki構文拡張スタイル - 縦書き、ルビなど日本文芸的な表現をしたいとき。
• 難解Wikidot構文 - SCP-JPでよく使われるちょっと便利な構文たちについて。単一ページ遷移構文や多重折りたたみなどなど。
• SCPスタイルリソース - 色んな記事で見かけるしかけたちのテンプレート集。カッコイイヘッダー、画像カルーセル、ログイン/ログアウトフォーマットなどなど。
• 第一回SCP-JP構文調査 - SCP-JPサイトメンバーが「ちょっとほしいな...」と思って作った(作ってもらった)構文がまとめられています。もしかするとあなたがほしかったものがここにあるかもしれません。

• 質問についての説明: 本文の要約
• どのような人からの手助けがほしいか: SCP・Tale・GoIF記事を書いた経験、翻訳した経験、Wikidot構文を操れるレベルなど

質問によっては以下の定義に当てはまらない情報もあるでしょう。そういうときは、「他人が読んでも、あなたの希望と状況が分かる」文章を目指してください。

一般的な質問

• 質問の背景
• 質問の動機・理由・目的
• (問題が起きているページ)
• ここまで調べたことや試したこと
• 調べた上で疑問に残ったこと

構文についての質問

• どういうことを実現したいのか
• 上記の動機・理由・目的
• あなたが実現したい機能を再現できる構文を募集するとき: 思い描いている動きとデザイン、設置先の記事のあらすじ・実際の記事(できればURLを書くこと)
• 構文が思った通りに動いていないとき: 思っていた動き・デザイン、実際の動き・デザイン、問題が起きている下書きのURL、どのような操作と思考の流れで問題が起きたか
• 構文が思った通りに動いていないとき: 問題が起きているページとそのページリビジョン
• ここまで調べたことや試したこと
• 調べた上で疑問に残ったこと

「分からないことが分からない」というがんじがらめはしばしば起きることです。この「わかる/わからない」のグラデーションには大まかに5つの段階があるとされています。この段階に合わせて、質問フォーラムに書くことを整理してみましょう。

全部わかっている
そんなあなたは質問フォーラムに用事はないはず。

わからないことがわかっている
どこにつまづいているのか言語化できている人はここです。
上で書くと良いと言われている情報をできる限り整理して、質問フォーラムに行きましょう。

わからないことがわからない
とりあえず調べた結果、それっぽいアドバイスを見つけたけど、まだもやっとしていてなんだかよく分からないという人はここです。
以下の情報をできる限り整理して、質問フォーラムに行きましょう。分かりやすく言えば、やりたいこと、やりたいことを実現するためにつまづくまでに思っていたこと、どこまで分かった・できたかを書いてください。

• 一般的な質問
  • 質問の背景
  • 質問の動機・理由・目的
  • (問題が起きているページのURL)
  • ここまで調べたことや試したこと

• 構文についての質問
  • どういうことを実現したいのか
  • 上記の動機・理由・目的
  • 構文が思った通りに動いていないとき: 思っていた動き・デザイン、実際の動き・デザイン、問題が起きている下書きのURL、どのような操作と思考の流れで問題が起きたか
  • ここまで調べたことや試したこと

わからないことがわからない状況を何とかする方法を知らない
一覧を見たもののどのガイドを参考にしたらいいのか見当もつかないあなたはここです。
以下の情報を言語化にできるか、抱えている問題に関係する言葉を知らないか、もう一度確認してください。もしできたら、ガイドハブやお役立ちリンク集から関連しそうなガイドやエッセイを探しましょう。それでもできなかったら質問フォーラムで聞いてみましょう。

• 一般的な質問
  • 質問の背景
  • 質問の動機・理由・目的
  • (問題が起きているページのURL)

• 構文についての質問
  • どういうことを実現したいのか
  • 上記の動機・理由・目的

「わからない」ことにレベルがあることを知らない
まずは上の項から始めましょう。

参考文献: 質問時に大切にしているポイント>レベルに応じた質問内容

一般的な質問

• 回答を読んだ上で疑問に残ったこと
• 回答を読んだ結果、途中までは分かった場合: なぜそう思った・分かった・考えたか

構文についての質問

• 回答をもらった上で再度つまづいた点
• つまづくまでの流れ
• 回答を読んだ上で疑問に残ったこと
• 回答を読んだ結果、途中までは分かった場合: なぜそう思った・分かった・考えたか

注意されたことがわからなくてもとりあえずごめんなさいとあやまる、そんな気の弱い人も中にはいるかもしれません。しかし、行動がなおらなければ、それは反省しておらず、自分の行動を良くしようとする気持ちがないものだと、ほとんどの人は考えています。

なぜ注意されたのかよく分からない時は、注意してくれた人に聞いてみましょう。教えてくれるはずです。

※(注記)この項はどちらかというと中堅以上むけの内容になっています。しかし以下の内容を理解できるようであれば、構文のオーダーメイドのハードルがぐっと下がることはまちがいありません。

構文の作成を頼むとき、あなたと構文を書いてくれる人の間で、完成イメージが大きく異なっていると、構文の作成に大きな苦労をすることになってしまいます。そういった事例をさけるために、相手には具体的な説明をこころがけましょう。

どうしても難しい言葉づかいになりますが、以下のような情報があるとすり合わせが楽になります。

• 構文の使用目的(その構文を設置することでそのような気持ちを読者にひき起こすか)
• 思い描いているデザイン
• クリック・マウスオーバーなどでページに変化を引き起こすとき: 思い描いている動き・機能(ページの遷移・タブの開閉・イラストの動作など)
• クリック・マウスオーバーなどでページに変化を引き起こすとき: それぞれの動き・機能が連携・分岐するのであれば、その順番/流れ
• 上記のデザインや変化、つまり機能についての設置目的・使用目的

基本的にあなたのふんわりとしたイメージは伝わりません、言語化しましょう。また、できればモックアップや完成イメージを用意してみましょう。もし既存の何かを再現・模倣したいというのであれば、それが分かるURLを伝えるとベストです。

例えば...私が以前、いつもお世話になっている方に構文の作成を依頼した際に、提示した情報をそれぞれ整理すると以下のようになります。

構文の使用目的:

• 機関リポジトリのデザインを再現することで、読者に学術機関のウェブサイトから論文を読んでいる空気感を味わせたい

思い描いているデザイン:

• テーブルのデザインは大阪大学リポジトリが一番近い(https://ir.library.osaka-u.ac.jp/repo/ouka/all/?lang=0)
• Rateモジュールに関しては既存の記事のものを色を変更して流用する

思い描いている動き・機能:

• テーブルは論文の情報(形式や作成者、言語、掲載誌等々)を記載する場所である
• テーブルは使用者によってテーブルの個数や内容を適宜変更することができる
• テーブル内に単一ページ遷移構文のリンクを設置し、本文に移動させる

完成した様子は実際の記事を参照してください。構文についてはページソースか、ディスカッションの解説ポストをご覧ください。

まとめ: 構文の作成を頼むときは完成形をくわしく言語化・画像化して共有しましょう。

ここまで読んでいただいた中堅以上のサイトメンバーの中には、間違ったことを言ったら迷惑だから回答しないでおこう......という人もいるでしょう。しかし新人のみなさんの勇気を受けて、回答を返してあげたいと思っているすばらしい人がいることも私は知っています。

回答者の立場に立ったとき、常に持っていていただきたいのが「思いやり」です。特に以下の点に注意すべきでしょう。

• 相手の知識・技能レベルに合わせた回答をしましょう
• 同じ議題について話している場合でも、定義や前提が異なるために議論がすれちがうことがあります: すり合わせをするときは押しつけにならないように・もしかしたらあなたの前提には誤謬が含まれるかもしれません
• 価値観に基づく主張なら、相手の価値観を尊重した上で妥協点を探しましょう
• 上から目線を避けましょう: 内容の平易化・敬意をこめた表現の使用・意図せず人格/価値観/知性に対する攻撃になる表現の回避、が効果的です

これらの内容は『より良いディスカッションの為に』を参考にしたものです。価値観の異なる相手との会話のとき、このエッセイは大変有益な視点を与えてくれます、特に新人さんと向き合う前は読んでおくべきです。同様の観点では『批評に関するポリシー』を読みなおすことも大事でしょう。

今回の例は、他人の記事の構文をコピーするために編集ボックスを開いたら編集してしまってそのまま保存もしてしまった!という初心者にありそうな失敗です。
この文では、質問するにあたっての背景について説明し、起こしてしまった失敗の解決方法についてたずねています。幸い自分で「リビジョンの差しもどし」機能を発見できたようですが、実際の作業に当たっての注意点を聞きたいようです。

この質問者は、第4章で紹介したグラデーションで言えば「わからないことがわかっている」段階です。質問の背景、調べた結果分かっていること、その上で分からないことまでしっかりかけている本文ですね。質問者としては実際に問題が起きているページにアクセスしなくても問題を解決できるぐらいには状況がよく書けているので、完成度は十分でしょう。

私としては差しもどした後にページのディスカッションや著者のPMに一言入れてくれれば十分なのではないかなと考えています。なお、この質問者が参考にしている『Wikidotの使い方エッセイ』では、ページを編集してしまう危険性なしにページを観察できる「ページソース」という機能も紹介されているので、恐らく回答者は回答時にページソースについても説明してくれることでしょう。

今回の例はインクルード構文で別のページの要素を呼び出そうと思ったが思い通りにいかなかったというあるあるな失敗です。今回はエラーメッセージが表示されるタイプの問題です。回答者としてはエラーメッセージを書いてもらえると、実際のページを調べてみる前に問題の概要をおおよそつかめます。エラーメッセージがでないときは、言葉を尽くして説明することで、問題を解決できそうな人に気づいてもらい、やはりURLを貼って実際の現場を見てもらうほかないでしょう。

この質問者は、第4章で紹介したグラデーションで言えば、「わからないことがわからない状況を何とかする方法を知らない」に相当する段階です。しかしエラーメッセージを含め質問の背景がしっかりと書かれているので、回答者としては解決すべき問題がほとんど分かっているという良い状態でしょう。

 [[include component:XXXXXX]]

さて、上のようなインクルード構文はinclude以下に記載されたページからそのページの要素を持ってくるという動きをしますが、サイトを指定しない限り同じサイト内(つまりここではサンドボックスIII)の指定されたページ名から持ってくるものを探してきます。この質問の場合、呼びだしたいページはメインサイト(SCP-JP)に存在するため、以下のようにサイト名を指定しなければならなかったんですね。

 [[include :scp-jp:component:XXXXXX]]

実はWIkidotシンタックスの他のページを埋め込むで紹介されている要素ですが、見出しと説明内容がいまいちリンクしておらず、ページの内容を覚えていないという人も多いでしょう。