ポケモンスリープ攻略・検証Wiki

補足ありがとうございます！考察の検討中の記述は共通項として下の補足事項に移動しておきました。
案６については「データは上の方にまとまっていてほしい」で意見が一致していた複数の編集者の案を集約したものなので、とくに補足は無いんじゃないかと思います～

それもそうかも知れませんね。補足が無ければそれはそれで。

案６のcontentsxをやめて項目へのリンクにしてみたら122ms→84.3msに改善されて、案５(96.8ms)と大差ない感じになりました！　contentsxって結構重かったんですね…
各ページの負荷は軽い方が良いのはごもっともですし、

考察, 厳選, 使用感の3つを即座に移動できるような目次を作成し、「考察」の下辺りに配置するのはどうでしょうか？仮に文章が長くなり過ぎてしまったとしても、知りたい情報（文章）にすぐ飛べるよう設定しておくこと

という意見(議論板B#110)を取り入れるだけならわざわざcontentsxを使わなくても大丈夫でしたね。

「考察」の部分だと思います。
特定の睡眠タイプを狙って睡眠計測をしたり、分割睡眠や絶食厳選を積極的に推奨したくは無いので、「○○のフィールドで出現しやすい」とか「○○だと出現しない」みたいな情報を軽く扱う程度で良いと思っています。

案5だとフレンドポイントの記述は「仲間にする」の項目にだけ書くので重複はしていないと思います。
文章作成にルールを設けると編集を重ねていくうちに消えたり、どこに情報があるか分からなくなったり、変更があった場合に修正が難しくなるので避けたいです。

案5の一番上の表が繋がっていないように見える

これは後で修正できると思います。

待ってください～！

案5の一番上の表が繋がっていないように見える

そう思うということはスマホでの閲覧かな？と思うのですが、これはPCで横並びにしている(縦幅を抑えるためにflex_boxを使っている)影響なので、表をピッタリくっつけることはできません。
案５だと右ブロックが一行しかないので、余計にそう見えますよね…ちょっと書式指定を考える必要がありそうです。

離れている部分は、経験値タイプと博士に送った時のアメの数
この2つは、他の種族値的なデータとは分類的にも違うものですし、分離していても問題ないのではと思います
むしろ、見た目は少々不格好だとしてもそこは分離したほうが分かりやすい可能性もあります
つながってないのは案6も同じですし

案5の左上の表（スマホなら一番上の表）がとてもいい

ありがとうございます。この表は案6にある表とほぼ同じものですが、お手伝い時間とかメインスキルを一つの表にまとめた方が良いという事ですかね。

そうです！
「とくい、お手伝い時間、きのみ、食材、所持数、メインスキル」
これらが合わさって「ポケモンの性能（本編で言う種族値みたいなもの）」になるわけです
これらが一つの表にまとまって配置されていると、性能を見たい時に役立つし見やすいです

投票はいったん止めていただけますか？

というのも、現状で既に編集差分ログに投票ページの更新がたくさん載ってしまっています。
以前問題になったときに比べて票数が少ない＝現時点ではログに流れた回数も少ないとはいえ、これを許してしまうと、「じゃあこの投票も人数が少ないだろうからOKだよね！」みたいになって線引きが曖昧になってしまいます。

ここ（編集相談板）の過去のやり取りで、おおむね「wiki内の投票機能は使用せず、zawazawaを利用して投票を行う」という流れになっていましたので、今からでもそのようにしていただきたいです。

そのために必要なzawazawa板の話は後述します。

zawazawa板新設の話です。

kさんは>> 257さんですよね。すみません、あのコメントを無視したわけではなく、あのときはまずリアクションを整備することを優先しており、板の新設を後回しにしておりました。
まず前提として、板（トピック）の作成はログインユーザーなら誰でもできます。編集相談板などで相談し、合意が取れたのであれば、管理チームでなくても建てていただいて大丈夫なものです。→編集方針

肝心の板の新設ですが、どのようにしましょうか？
「みんなの意見板」のようにしますか？
それとも、今回のような投票に使えるように、「投票板」のようにしますか？

一旦停止しました。
diff_log(編集差分ログ)に関する個人的な意見としては（こちらも完全にスルーされていましたが）

（自分が見ている範囲だと、荒らしよりも編集合戦が熱くなったり勝手に検閲する人がいたりする方が問題としてよく発生している印象ですので、編集者の特定が可能になるというデメリットの方が大きい気がします。なので、「一般ユーザーがdiff_logを扱いにくい」という状態を受け入れて、wiki内の投票機能を使うのが一番良いかなと思っています。）

という意見です。
現在活発に動いているwiki内のコメントを利用したページというのもほとんどないですが、投票だけでなくwiki内コメントによっても編集差分ログは流れてしまうので、投票だけでなくコメントも含めた編集差分ログの扱いをしっかり定めておく必要はありそうです。

まずはご対応ありがとうございます。お手数おかけします。

なるほど、diff_logが見づらいことは許容する、そもそもwiki内コメントによっても流れるのだから投票で流れようが同じこと、というようなスタンスでしょうか。

正直なことを言いますと、実は私自身、普段まったくdiff_logを見ていません。
ただ、diff_logを普段から見ている人が複数いて、その方達が「流れると困る」と言うのなら、当事者（普段見ている人）の意見を尊重すべきと考えていました。

しかし、改めて>> 171のツリーを読み直してみたところ、
「diff_logが流れても構わない派」がkさんと5ab84@62cc8さんの2名、
「diff_logを投票で流さないでほしい派」がSpectさんのみ、
のようでした。
他にdiff_logを見ている人、流さないでほしい人がいるのかどうか。いないのなら、wiki内投票を使ってもよいのかもしれません。

なるほど、diff_logが見づらいことは許容する、そもそもwiki内コメントによっても流れるのだから投票で流れようが同じこと、というようなスタンスでしょうか。

というよりも、例えば検証でよく用いられる「コメント欄を利用したデータ収集」などを行うと投票と同じように多くのログが生まれてしまうので、「投票をどうするべきか？」よりも「diff_logをどうするべきか？」の方が重要だろうということですね。

荒らしが発生した際に被害の全容把握が一般ユーザーには難しいという問題はありますが、荒らしの出現頻度は低いですし、「荒らされているページを見つけたら管理人に報告する」とすればdiff_logが無くても問題はないと思っています。

私もwiki全体の編集差分ログを参照することは無いので、他にどんな使い方があるのかは把握していないです。

投票所を慌てて作る必要はないと思います
ログの件もそうですが、投票所はしっかり内容を練ってから公開すべきかと
せっかく詳しい説明があった案の特徴も投票所にはなかったし、その辺拙速だった感もあります

「投票をどうするべきか？」よりも「diff_logをどうするべきか？」の方が重要だろうということ

なるほど。一番の焦点はここなのですね。
しかし、このままdiff_logを見ない人同士で話をしていても答えは出なさそうに思います。
「diff_logをどうするべきか？」については、改めて議論していく必要がありそうです。

とりあえず、まず今回の投票の件に絞って見た場合、今取れる選択肢は、
①diff_logを見ている人を交えて議論を行い、解決するまで投票中止
②投票を再開。diff_logを見ている当事者から何か言われたら、そのとき改めて対応する

私は②でいいかなぁと思います。（追記）
そもそも、当事者が何も言っていないのに、当事者でない私が投票をストップさせるべきではありませんでしたね。申し訳ありませんでした。

追記：
投稿が前後してしまいました。
「投票所自体をもっと練ってからやり直す」案、いいですね。

ログの件もそうですが、投票所はしっかり内容を練ってから公開すべきかと

それはそうですね。編集相談板だけでもそれなりに反響があっていろんな意見が集まる気配があるので、投票の実施はまだ先送りして良さそうです。

それはそれとして、みんなの意見等の投票ページについては「diff_logを参照できなくて困っている」という具体的な意見が挙がるまでは解禁していいのかなと思っています。

自分は時々diff_logを見る派ですが、「みんなの意見」の問題点は無期限＋複数の質問があり大量に投票(編集)が入ることだと思うので、ごく短期間(たとえば今回設けていた50～100票で終了という制限つき)であればtvoteプラグインでもいいのではと思います。

>> 275これを許してしまうと、「じゃあこの投票も人数が少ないだろうからOKだよね！」みたいになって線引きが曖昧になってしまいます

しかし、上記もたしかに考慮すべき点であると思います。

個人的にはzawazawaで「投票板(みんなの意見)」を作成してリアクションで投票＋(すべての意見を完璧に取り入れられるわけではないという注釈をつけて)意見がある場合はコメントをしてください、とするのが今後も使いまわせて良い気がしますがいかがでしょうか？

投票だけでなく、wikiwiki式コメント欄についても併せて編集方針を定めておく必要があると思います。
（デイリーギフトやゆびをふるの検証等のように大量のwikiコメントが予想される場合にはzawazawaを推奨するなど）
zawazawaでの投票のデメリットとして気になっているのは、コメントが書き込まれると流れて行ってしまう点と投票としての見にくさですね。
枝葉を利用した投票だと何が質問でどこまでが選択肢か分かりにくいですし、票数も確認しにくいです。
ただ、不便ということ以外に問題はなく、投票の仕組み自体は実装可能だと思うので、wiki内投票を禁止するという措置が下されるのであれば妥協も止む無しという感じです。

diff_logについてお答えします
>> 277

>> 282

>> 285
trackerについて、どのような編集・操作が必要が教えていただければ対応します

その他質問等も受け付けます

「diff_logを一般ユーザーが使いやすい」状態における問題点として挙げた内容は例えば通報合戦や晒しみたいなことが起こる事への懸念ですね。私としてもそこまで深刻な問題であるとは思っていません。
言いたいこととしては「一般ユーザーがdiff_logを閲覧しやすい状況」というのが手放しで望ましい状態ではないため、「diff_logを一般ユーザーでも閲覧しやすい状況を維持することの明確なメリット」が必要だろうということです。

管理者のみ閲覧できる方の編集差分ログにおいて、『voteやtvoteによる編集』を除外した差分の確認も困難であるとすれば上述の「diff_logを一般ユーザーでも閲覧しやすい状況を維持することの明確なメリット」として十分だとは思います。（うまくvoteによる編集ログだけ除外する方法があるはずだと思うのですが、自分では見つけることができませんでした）
荒らしに対してそこまで迅速な対応が必要だとは思いませんが、「投票を実装しないことで迅速な荒らしへの対応が可能である」とするなら『投票を実装することを制限する』という措置にも一応の納得感はありますね。

管理画面の編集差分ログは正規表現が使えない検索機能のみとなっており、以前あまる氏が提示されたCSSが利用可能かもしれない、といった感じですね
当方が最も利用する環境がiOSですためCSSは難しい(ショートカットAppを利用する手があるのは存じていますが毎回実行する手間を考えると厳しい)と思われます
紆余曲折ありながらも投票はzawazawaで行えるという見解で一致したことを踏まえると、投票はzawazawaでお願いしたいと考えています

余談ですが、先ほど思い出したdiff_logの利点に「先頭に:が含まれるページ」を除外表示しないというものがありました
RecentChangesや最新n件では除外されるため、#trackerの設定ページなどが荒らされると気づきにくい、というニッチな利点もあります
あまり有効な意見では無いかもしれませんが、一応記しておきます

>> 297について挙げられたものはすべてフォーム化可能でした
ポケモンの説明など他にもフォーム化できるものもありそうです
なので、フォーマットが確定したタイミングで教えていただければ必要そうな事項を見繕ってフォーム化しますね
ちなみにページの作成タイミングにもよりますが、入力事項は空白でも動きはするのですべて埋め尽くす必要もありません

また>> 296で挙げられていた「同系統のポケモンを並べて表記」もうまくいきました
サンドボックスに雑ですがフォームを設置しているので試してみてください

trackerテストありがとうございます！フォーム化してうまく動きそうなのでこのまま進めても大丈夫そうですね。

一点疑問なのですが、trackerフォームで作成したページって見出しのアンカータグの文字列までは指定できなさそうですか…？
>> 263で「考察」部分に使っていたcontentsxを軽量化のために

-[[厳選基準考察>./#select]]
-[[使用感・育成相談>./#experience]]

と見出しのアンカータグにジャンプできるように変更していたのですが、
trackerで作成したページのアンカータグがランダムな文字列で生成されてしまうのであれば、contentsxに戻した方が良いのかな？と思っています。
少々処理が重くはなってしまうものの各リサーチフィールドのページと大差ない処理速度ですし、できれば多少の重さよりは利便性を重視した方が良いように思います。いかがでしょうか？

仕様かバグか不明ですが、仰る通りアンカー文字列の指定ができないようです
wikiwiki運営は非推奨プラグインとしているようで修正には期待できないので、手動でアンカー文字列を修正するか#contentsxを利用していただければと思います

見出しのアンカー([#pokemon_data])は勝手にランダムの英数字に変わりますが、
#aname(pokemon_data)は変わらなかったので
同じことはできます。

案6-3の「考察」部分で試してみたところできました！anameって見出しにも使えるんですね。知らなかったので勉強になりました
テンプレートに組み込めるのであればcontentsxに切り替えなくても大丈夫そうです。ありがとうございます。