AVIF形式への対応に賛成です。 先日Windows10のサポートも終了したため、再度ご検討いただければ幸いです。
>> 6
新管理者が移転の提案を行うことが禁止されているのは問題
いいえ、自分はそう思いません。
自分が作ったWikiであれば、登録ユーザー（＝管理者）は自由にWikiを閉鎖（移転含む）でき、 運営は、管理放棄されたWikiを閉鎖できます。 管理権限移譲のシステムは、諸事情で閉鎖が見込まれるWikiへの救済策であり、 救済策である以上、無条件という訳にはいかないということでしょう。
利用規約に「引き継いだ管理者は、元の運営方針を尊重すべき」とあるように、 新管理者に求められるのは、前任者の意思を継いで （引き続きWIKIWIKIで）Wikiを管理・維持していくことです。
そのつもりがない人に管理権限は譲渡されるべきではありませんし、 数ヵ月後、数年後に気が変わった？ということであれば、 その人がすべきはWikiの移転提案ではなく、別の誰かに管理権限を譲渡することです。
若干別軸かもしれませんが、議論の中で生じた疑問を書き込ませて頂きました。
個人的に思うのは、「新管理人は移転の提案不可だが、議論への参加は可能」なのか、「新管理人は移転の提案も議論の参加も不可」なのか、「管理人交代が起こったwikiは移転不可」なのか、そこははっきりさせて欲しい所ですね。 いずれにせよ新管理人がやや蚊帳の外になってしまう感は否めませんが…。
他の編集者が移転の提案を行うことが認められているにも関わらず、新管理者が移転の提案を行うことが禁止されているのは問題な気がします。 既に自分が言及していますが、そもそも、移転の提案自体が私物化行為に該当するとは考えられません。 その提案自体が私物化が目的だったり、その他悪意のある理由なのであれば問題ですが、そうでないのなら正当な提案だと自分は思います。 管理人も編集者の一人であり、一編集者として他の編集者と対等な立場でwikiの方針の話し合いに参加する権利はあるはずです。
どうも勘違いされているようですね。
そもそも Wikiの移転を運営が禁止しているという事実はありません。 （そんなことをすれば、独占禁止法に抵触してしまう可能性があります）
運営が禁じているのは「譲渡されたWikiを新管理者が私物化する行為」であり、 私物化行為の一例として「移転の 提案や誘導を（新管理者が）行うこと」が挙げられているに過ぎません。
新管理者が全く関知せずに、（もしくは反対した）結果として ユーザーの総意で移転が決まったのであれば移転はOKですし、 自分が作ったWikiならば、自分だけの判断で移転も閉鎖も自由です。
元々15歳以下向けのコンテンツを扱っていた
規約違反になりますので、速やかに違反部分を削除するか、 Wikiを移転するか、閉鎖するかしてください。
確かに、最近ルールの更新がありましたし、それにより根底からWIKIWIKI本体の方針とずれてしまい、修正が難しい場合は(元々15歳以下向けのコンテンツを扱っていた等)当然ながら、WIKIWIKIでずっと運営することは出来ないため、移転が必要になります。そのため、運営や利用者と相談の上で移転を行うのは許容していただきたいと思います。
音楽付き広告ほんとに迷惑。採用しているサイトは閲覧を避けてます。表示されたらすぐ閉じます。
あまり公式コミュニティで話すことではないですが、どんなwikiプラットフォーマーでも収益減とサーバーリソースのアンバランス化に直結するwiki移転をおいそれと認めるわけにはいかないでしょう。 トラブルが頻発しているとか、収益が上がらない割にリソース喰らいになっているといった、むしろ出ていってくれた方が厄介払いになるケースを除いて移転の提案が上がること自体がwiki運営にとって有害です。 信用の安定をとるか収益の安定を取るかの違いだと思います。いい顔ばかりして運営自身と他wikiの首を締めるのも困ります。
そのルールが定められた経緯は分かりませんが 記載されている以上、相応の理由があります。
過去に移転前提でデータ抽出だけ行うような管理者がいたのかもしれません。
何らかの事情でWiki管理が難しい場合は 運営に相談してください、と管理権限譲渡の条件に記載されています。
どうしても移転しなければ解決しない問題であるならば その旨を相談すればよいのではないでしょうか。
※現時点で自分が管理するwikiの移転の予定はありません。
たしかにそうですね 全員に使い方を公開してないけど誰でも使える状態なら制限という言葉は誤解を生む表現ですね いずれにしても>> 17さんの意見に賛同です。
一方で、アニメーション利用が可能であることから、乱用によって転送量が増加し
GIF・WebPでもアニメーション可能ですので、的を射ているとは思えません。 現状のサイズ制限はアニメーション画像に対する制限としては割と厳しいので、AVIFを解禁したからと言ってアニメーション画像の乱用が増えるとは思えません。 アニメーションを乱用している人は、上述の通り既にGIFやWebPでやっているでしょう。 AVIFになったからといって新規でアニメーションを乱用する人が続出するというのはどのような考えに基づくものでしょうか？ むしろ、GIF・WebPで画質・フレームレート・サイズを落として現状のサイズ制限ギリギリまでに収めていたアニメーション画像の画質がいくらかマシになり、閲覧体験の上昇が期待できます。 OSでの閲覧環境も整いつつあり、Windows 11では標準の画像ビューワーで閲覧可能です。一昔前は何だこの画像形式ダウンロードしたのに見れねえじゃねえかよという文句がよくありましたが、緩和の流れになっています。 再検討をお願いします。
全面的に賛成します。 最近自分でwikiを建てたことは無かったため、新規に作成したwikiの実際の導線については分かりませんが、この文章の内容を考慮すると改善は必須だと感じます。
一部の編集者にのみ公開するというのも不自然じゃありませんか…？(誰でも利用可能なことに変わりはないのでしょうし。) >> 20の通りとなりますが、そうするくらいなら非推奨であることを明記して全ユーザーへ公開してほしいものです。
賛同します。使えるにも関わらずマニュアルに掲載されていないと混乱を招く原因になります。(一般論としてマニュアルに記載されていないのに使えるというのも意味不明ですし。) 仮に非推奨や今後廃止される予定があるならその旨記載されていればすんなりと受け入れることができます。(むしろ廃止予定ものを明示することで該当Wikiで早めに対処することが可能です。)
また、他のWikiを参考にすればいいというのもいささか乱暴に思えます。マニュアルを整備したうえで活用事例として紹介する分には自然ですが、不完全なマニュアルのまま「他のWikiを参考にしてください」はいかがなものでしょうか。言い方は悪くなってしまいますが、現在の姿勢はユーザーに対する透明性に欠けるものだと感じます。
@wikiwiki 制限付きプラグインについて、該当のWikiの管理者や積極的な編集者などに向けて発信していただくのは難しいでしょうか？ 対処が必要な場合に限り該当のWikiの掲示板などでご発言いただく等の対応になると思います。
というのも個別のWikiの事情にはなりますがインクルードを１３０回ほど使用して構成しているページがあり、負荷をさげるためにできることがあるのか不明な状態です。
https://wikiwiki.jp/sample/左・中・右寄せ
↑改善を……
せめて音を無くしたりバックグラウンドの音楽が流れなくなるだけでも……
運営にあまり期待できないのであれば、 有志で非公式プラグインマニュアルWikiを作るのが現実的だろうと思います。 実際（諦めて？）独自に非掲載プラグインの説明記事を載せているWikiもあります。
プラグインマニュアル、さんぷるWiki掲載分については、 運営にコピペの承諾が貰えれば、割とスムーズに整備できるのではと思います。 （全部独自記載となると大変かもですが…）
多用されると負荷が大きくなるため、あまり使用して欲しくない、一部のブラウザで動作しない、 将来機能しなくなる可能性がある、将来廃止することを検討している、お試しで実装している、 忙しくて記載する時間が取れない（さんぷるWikiの方には掲載されていたり※1、未完成下書きがあったり※2）… …そんなところだろうと思っていましたが、概ねそのようですね。
※1 font、jumplist、shadowheader、showrss2、table_edit、tag、tvote、など ※2 tomorrow_schedule、など
問題は、全て運営側の一方的な都合であることと、 ユーザーには非掲載の理由が不明なことです。 （サービス業でありながら、どちらを向いて仕事しているかという話になってしまいます）
標準プラグインと拡張プラグインに分けて掲載したいならそれでも構いませんが、 マニュアルには、実装されている全てのプラグインを掲載いただき、 非推奨の場合は、非推奨である旨とその理由、自己責任で使用する旨を記載すれば、 よろしいのではないかと思います。
現状ママでは、例えばcontentsxやinclude2、includexは積極使用OKなのか、 それとも使用はできるだけ控えた方が良いのかすら（その理由を含めて）判断できませんが、 例えば「MenuBarでの使用は、負荷が大きくなるため非推奨」など具体的なアドバイスが書かれていれば、 大いに役立つだろうと思われます。
これ、zawazawa以外のサービスのコメント欄でも見かけるようになってきたので、zawazawaの問題じゃなく、firefox自体の問題かもです
アカウントの形式自体は「匿名の権限アカウント」で十分だと考えています(但し管理者権限がある方には、荒らし対策のためどのアカウントからの編集かを閲覧出来る機能が必要な気がします。)が、アカウント制について、Fandomのビューロクラットシステムのような機能が存在することを望みます。
現状wikiwikiではメインパスワードの所持者が最高権限者となり、サブパスワードの所持者が下に付くような形になっていますが、このシステムではメイン管理者に問題が生じた場合にwikiの維持が滞ってしまうリスクがあるほか、wikiはみんなで作成する物ですが、現行のシステムだとメイン管理者一人に全責任が集約されてしまい、みんなで作るというwikiの方針から逸脱しているように感じます。 一方、Fandomのビューロクラットシステムのような機能があれば、最高権限者を複数用意することが出来、誰か一人に問題が生じてもwikiの維持に掛かる影響を最小限に抑えられるため、みんなで作るというwikiの方針とぴったり合うと考えられています。
なお、ビューロクラットシステムを実装する場合、wikiの削除に関するシステムを修正する必要があると思われます。(誰かが勝手にwikiを削除できないよう、正当な理由(サイトの移転等)があるかつ削除にwikiwiki運営の承認が必要にする。また、必要に応じて移転先のサイトへのリダイレクトに置き換える等の対応を行う等。なお、そもそもFandomにはwikiの削除機能が無いため、荒らしに勝手にwikiが消される心配は無い。)
こちらのトピックで言われている機能があれば柔軟に実現できそうです https://z.wikiwiki.jp/wikiwiki-request/topic/421
他の要望でも運営さんからの回答待ちが幾つかある中で早めにご回答いただきまして、どうもありがとうございます。
以上をもちまして、トピックは締め切りとさせていただきます。以前にお伝えしたとおり、さらに議論を要すると認識される方は新たなトピック作成をお願いいたします。
様々なご意見をいただき、ありがとうございました。
ご要望ありがとうございます。
AVIF 形式の画像については、高い圧縮率や画質面でのメリットがあり、 静止画用途としては魅力的な形式であると認識しております。
一方で、アニメーション利用が可能であることから、 乱用によって転送量が増加し、サーバーや利用者の環境に負担をかける可能性が高い点を懸念しております。
現時点では、需要もまだ限定的であることから、今回は対応を見送らせていただきます。 今後の利用状況やブラウザ対応の動向を注視しつつ、ニーズが明確になった段階で改めて検討してまいります。
ご理解のほどよろしくお願いいたします。
ご指摘ありがとうございます。
マニュアルの整備や動線についてご不便をおかけして申し訳ありません。 プラグインにはいくつかのステータスがあり、すべてを公開前提としているわけではありません。
標準公開プラグイン 一般的に利用されることを想定しており、マニュアルにも掲載しています。
制限付きプラグイン 管理用・検証用・負荷軽減・特定のWIKI向けなど。広く公開すると誤用による負荷や不具合につながる可能性があるため、限定的に利用されています。
廃止予定または移行対象のプラグイン 内部的には動作しますが、将来的に終了や置き換えを予定しているものです。新規利用は推奨していないため、マニュアルには記載していません。
このような理由から、あえて全プラグインをマニュアルに掲載していない場合があります。 とくに「使えるけれど記載がない」ものは、安定性や互換性の観点から広く推奨できません。
一方で、マニュアル不足やアクセスのしづらさは課題と認識しています。 主要プラグインの追加や、リンク配置の改善についても課題と認識しており、できるところから順次対応していく予定です。
また、補足的な学び方として他のWIKIのソースを参考にするのも有効です。 実例を見ることで、マニュアルだけでは分かりにくい工夫や応用を理解しやすくなります。
マニュアルは今後も整備を進めますので、実例とあわせてご活用いただければ幸いです。
ご意見ありがとうございます。
仕組みについて
WIKIWIKI の counter、online、popular は、PukiWiki に標準で搭載されている counter 系のプラグイン とは仕組みが異なり、Go 言語で独自に開発したカウンターサーバー で動作しています。 Amazon DynamoDB をストレージに使い、非同期で分散処理する仕組みによって、アクセスが殺到しても counter 数を壊さず、WIKI の基盤システムに負担をかけずに動かせるようになっています。
ただし、このカウンターサーバーは WIKI のページ情報そのものを持っていないため、存在していないページかどうかを判断することはできません。処理をシンプルに保つことで、大規模アクセスにも耐えられるようにしています。
公平性について
「popular の通算をリセットする機能（いわゆる counter リセット）」を導入すると、ユーザーが counter の数字を操作できることになり、各 WIKI の公平性や将来のアクセス数の目安としての信頼性が揺らぐ可能性があります。 また、rename によって counter の数字を 引き継ぐ ことも、人気ページのアクセス数を別のページへ移せてしまうため、望ましくないと考えています。
対応について
現時点で counter の数字をリセットできるようにする予定はありません。
その代わり、popular の仕組み自体を見直していて、非同期処理から半同期処理に切り替えることを検討しています。いまは非同期のリクエスト数がかなり多く、これを減らしたい狙いがあります。
仕組みとしては、WIKI の基盤システムから内部経路でカウンターサーバーの情報を取ってきて、ページの内容と一緒に出力するやり方です。最近では zrecent もこの半同期処理に移行しました。
この方法なら、WIKI の基盤で存在しないページを除外した集計が可能になります。ただし、集計の負荷がページ生成に乗ってくるため、その点は検討中です。
もしこの仕組みを導入する場合は、「負荷パネル」を見ながらユーザーの方に調整してもらう必要も出てくるかもしれません。
popular プラグインの廃止検討について
popular は、負荷の大きい集計系プラグインです。 現在では Google Analytics も利用できるため、必ずしも popular に依存する必要はありません。必要に応じて REST API を使って Google Analytics のデータを取得し、集計結果を定期的に WIKI ページとして生成する方法も可能です。
また、popular を必要以上に多用してランキングを作成するケースもあり、その結果ページ表示が重くなったり、期待通りの結果が得られないことがあります。こうした事情から、popular は 非同期処理として実装されてきました。
以上の背景を踏まえ、popular の提供方法を見直し、場合によっては廃止も視野に入れています。
私はページ名の規制を利用していないので詳しいことは分かりません。 一度設定してみて、期待通りの動作になっているかご確認ください。 該当するページ名で作成しようとした際、SMS認証画面が表示されれば有効です。 [追記]管理者ログイン状態では規制の影響を受けないため、ログアウトした状態で検証してください。
特定のページ名の作成を制限する場合、規制ルールはどのように作成すれば良いでしょうか？
対象項目:ページ名 パターン種別:いずれかを含む パターン:(禁止するキーワード),(禁止するキーワード),...
で良いでしょうか？
コントロールパネル/規制ルールの設定により特定ページの作成・編集を制限することができます。
コントロールパネルで管理できる管理者限定の機能で、NGワードのようにできるなら私も賛成いたします。 具体的には売春斡旋業者にLINE IDや未成年に見せたくないキーワードを含むページ名でページ作成されて困っており、それらのキーワードを含むページの作成を禁止したいと考えています。
日常の合間でトピックを閲覧された方、ならびに投稿してくださった匿名d9d8f@6728cさん、副管理人(WoTBWiki) さん、はやしさん、匿名01062@e41b5 & fc709@e41b5さん、01vさん、ceptさん、お疲れ様でした。(投稿順)
@wikiwiki >> 29副管理人(WoTBWiki) さんのおっしゃる通り、議論し尽くしたと認識しています。運営さんからの回答をもちまして、どのような回答であってもトピック主にしかできない「解決済」タグ付けを行って一旦、締めさせていただく予定でいます。
運営さんからの次の回答以降も議論の余地があると判断される方はお手数ですが、新たなトピックを建ててからお話しください。
参考URL
傍目には、既に十二分に必要性、あるいは不必要性が述べられているかと思います。 これ以上必要性の議論をしても平行線でしょうし、あとは運営チームに判断を委ねる形でよいのではないでしょうか。
よくまとまっていると思いますが、補強する余地がいくつかあるようなので、お話させてください。
したがって、総数と直近では差別化がなされています。
はい、総数と直近は中身が違います。これは間違いなく正しいことです。 しかし中身が違うということから、有益であると主張するのは理論の飛躍があります。なぜなら「唯一無二であるが無用なもの」であることを否定できていないからです。 「直近と違うから総数は有用だ」よりも「総数を見ることでしか得られない、こういうメリットがあるので有用だ」という説明のほうが、説得力があるはずです。
今日100と人気100はあらかじめ用意されており
たしかに、そのはずです。 しかし長く運用されてきたシステムは往々にして、「あまり要らないけど外すのも手間だし、何か起こったら嫌だから触らずにそのままにしておく」機能も多いのです。 「昔からあって今もある」ということは必ずしも、積極的に提供する意思があることや有益であることを証明しません。 論拠の一部として添えることは無駄ではありませんが、弱みがある論拠なので尊重されないかもしれません。
Googleアナリティクスなどの高度な分析ツールを理解して扱うにも、それなりの時間と専門知識が必要であり
Googleアナリティクスに関する「専門知識」とは、いったい何のことでしょうか。 私が使い始めたときの話をすると、事前の学習や訓練に費やした時間はゼロです。 サーバOSの知識やネットワークプロトコルなどの知識は、要求されません。 もっと具体的にハードルの高さを示さないと、いわゆる「食わず嫌い」と見なされて説得力がないように思われます。
これらの点は利用者全体の公平性やシステム負荷、運営方針にも関わるため、機能追加の是非については 引き続き議論が必要 になると考えています。
という部分は「利用者の個々の事情に基づく議論が活発に継続されたのち、挙げられた要望や案についてwikiwiki運営が公平性・システム負荷・運営方針をベースに総合的に判断する」と解釈しております。したがって壁打ちのような様相になっても、各利用者のそれぞれの立場からの発言は重要だと認識しております。
この解釈と利用者のあるべき議論スタンスについて討論したいわけではないので、popularプラグインに関する意見を述べさせていただきます。 はやしさんが整理された、「popularが示す数値のうち、総数ではなく直近の数字を使えばよいのでは」「Googleアナリティクスを使えばよいのでは」という２つの論点について、某スマホゲームのwikiの管理者として意見を表明します。
「今日100があるのだから人気100の重要性は薄く、削除されたページにはアクセスカウンターが増えていかないのだから、カウンターリセット等の機能がなくとも十分で、新機能の開発のリターンが薄い」という旨の主張と理解しています。 私が管理しているwikiの今日100には、最近更新されたページや、ゲーム側で追加された新要素・新キャラクター、直近で開催されるイベントがリストアップされます。 一方、人気100では、登場するキャラクターの一覧ページや、日課・週課の攻略情報が集約されたページ、ゲームシステムの解説ページなど、長期間に渡って一定数の需要があるページが上位に並んでおります。 したがって、総数と直近では差別化がなされています。両方をリストアップするページを置くことに意味があるのであれば、人気100に残りやすい、削除前・リネーム前の人気ページのカウンター数への対処を実現していただきたいのが要望です。 （wikiwikiで新しくwikiを立てるとき、今日100と人気100はあらかじめ用意されており、メニューバーにもリンクが設置されていたものと記憶していますので、wikiwiki運営側もこの２つの差別化については認識されていると考えています）
過去の款冬華さんからの発言が、十分に理論的に利用価値を説明していると思います。
編集の優先順位を決める手がかりになります。編集者はそのページの品質向上に注力できます。ボランティアベースの編集に頼っている大半のWikiは重要な動機付けとなります。閲覧者にとって、PV数が多いページは信頼性や関心度が高いと映る場合があり、さらなるサイトの探索や利用者のエンゲージメント(愛着や深い繋がり)を促進します。
すべてのWiki管理者が高度な分析ツールを導入するための技術的知識を新たに吸収して実践できるとは私自身は到底、思えません。popularプラグインは簡易な指標として価値があります。設定やアクセス解析ツールであるGoogleアナリティクスなどの高度な分析ツールを理解して扱うにも、それなりの時間と専門知識が必要であり、すべてのWiki管理者が利用できる環境を整えたり、普及活動のために技術的知識を手に入れたいとは限りません。私自身も含みますが、PCを持たずしてモバイル端末だけで管理する者もいます。
（前略）Pukiwiki1.4(2003年リリース)で標準搭載され、利用者のアクセス傾向を簡単に知ることができます。todayとtotalは共に長年、どのWikiでも作成当初からMenuBar最下部にリンク表示されて使われてきたプラグインですので有用性は十分に裏付けされているでしょう。
上記の発言に全面的に同意します。 また、専門知識に疎い管理者・編集者以外にも、利用者にも恩恵がある旨の主張も付け加えさせてください。 長期間にわたって運用されるwikiでは、どうしてもメニューバーが複雑化したり利便性が低下したりする傾向があると考えています（こちらについて事例が必要であれば挙げることもできます）。 その中で、サイト内のカウンター統計が機能している人気100は、新しくサイトを利用したユーザに対してMenuBar・サイト内検索に各ページへ遷移するためのもう一つの選択肢を付け加えることとなり、一定の利用価値がないでしょうか。 ここがリネーム等で十分に機能していない・リンク先が存在しないと表示されるのであれば、やはり修正の意義があると思います。
今の運営さんの話を元にしても議論にならない、という点については確かにそうかもしれません。 しかし最終的な判断を下すのは結局のところ、運営さんなのです。 なんとかしてもう少し運営さんから話を引き出さないと、お互い（運営さん＆機能追加を求める意見）の話がかみ合わない可能性があります。
いいえ違います。 そこの主語は不明確ですが運営であるべきです。そうでないなら運営の認識が誤りであるというのが私の意見です。 ユーザーには利用状況も内部の原理や負荷も見えないので議論になりません。何をもって公平かなど、気持ち次第でなんとでも言えるので、そこをに注力して話をしても発散するだけです。
popularは有用です。 私の例で言えば、popularやcounterのアクセス数からメニューの掲載基準や位置の決定に活用しました。 当時メニューが無法地帯だったので私はそれを整理しようとしました。 そのとき私は管理者ではなく来たばかりの新人でしたが、提案を数値に基づいて示したので話がスムーズだったと思います。
AVIF形式への対応に賛成です。
先日Windows10のサポートも終了したため、再度ご検討いただければ幸いです。
>> 6
いいえ、自分はそう思いません。
自分が作ったWikiであれば、登録ユーザー（＝管理者）は自由にWikiを閉鎖（移転含む）でき、
運営は、管理放棄されたWikiを閉鎖できます。
管理権限移譲のシステムは、諸事情で閉鎖が見込まれるWikiへの救済策であり、
救済策である以上、無条件という訳にはいかないということでしょう。
利用規約に「引き継いだ管理者は、元の運営方針を尊重すべき」とあるように、
新管理者に求められるのは、前任者の意思を継いで
（引き続きWIKIWIKIで）Wikiを管理・維持していくことです。
そのつもりがない人に管理権限は譲渡されるべきではありませんし、
数ヵ月後、数年後に気が変わった？ということであれば、
その人がすべきはWikiの移転提案ではなく、別の誰かに管理権限を譲渡することです。
若干別軸かもしれませんが、議論の中で生じた疑問を書き込ませて頂きました。
個人的に思うのは、「新管理人は移転の提案不可だが、議論への参加は可能」なのか、「新管理人は移転の提案も議論の参加も不可」なのか、「管理人交代が起こったwikiは移転不可」なのか、そこははっきりさせて欲しい所ですね。
いずれにせよ新管理人がやや蚊帳の外になってしまう感は否めませんが…。
他の編集者が移転の提案を行うことが認められているにも関わらず、新管理者が移転の提案を行うことが禁止されているのは問題な気がします。
既に自分が言及していますが、そもそも、移転の提案自体が私物化行為に該当するとは考えられません。
その提案自体が私物化が目的だったり、その他悪意のある理由なのであれば問題ですが、そうでないのなら正当な提案だと自分は思います。
管理人も編集者の一人であり、一編集者として他の編集者と対等な立場でwikiの方針の話し合いに参加する権利はあるはずです。
どうも勘違いされているようですね。
そもそも Wikiの移転を運営が禁止しているという事実はありません。
（そんなことをすれば、独占禁止法に抵触してしまう可能性があります）
運営が禁じているのは「譲渡されたWikiを新管理者が私物化する行為」であり、
私物化行為の一例として「移転の 提案や誘導を（新管理者が）行うこと」が挙げられているに過ぎません。
新管理者が全く関知せずに、（もしくは反対した）結果として
ユーザーの総意で移転が決まったのであれば移転はOKですし、
自分が作ったWikiならば、自分だけの判断で移転も閉鎖も自由です。
規約違反になりますので、速やかに違反部分を削除するか、
Wikiを移転するか、閉鎖するかしてください。
確かに、最近ルールの更新がありましたし、それにより根底からWIKIWIKI本体の方針とずれてしまい、修正が難しい場合は(元々15歳以下向けのコンテンツを扱っていた等)当然ながら、WIKIWIKIでずっと運営することは出来ないため、移転が必要になります。そのため、運営や利用者と相談の上で移転を行うのは許容していただきたいと思います。
音楽付き広告ほんとに迷惑。採用しているサイトは閲覧を避けてます。表示されたらすぐ閉じます。
あまり公式コミュニティで話すことではないですが、どんなwikiプラットフォーマーでも収益減とサーバーリソースのアンバランス化に直結するwiki移転をおいそれと認めるわけにはいかないでしょう。
トラブルが頻発しているとか、収益が上がらない割にリソース喰らいになっているといった、むしろ出ていってくれた方が厄介払いになるケースを除いて移転の提案が上がること自体がwiki運営にとって有害です。
信用の安定をとるか収益の安定を取るかの違いだと思います。いい顔ばかりして運営自身と他wikiの首を締めるのも困ります。
そのルールが定められた経緯は分かりませんが
記載されている以上、相応の理由があります。
過去に移転前提でデータ抽出だけ行うような管理者がいたのかもしれません。
何らかの事情でWiki管理が難しい場合は
運営に相談してください、と管理権限譲渡の条件に記載されています。
どうしても移転しなければ解決しない問題であるならば
その旨を相談すればよいのではないでしょうか。
※現時点で自分が管理するwikiの移転の予定はありません。
たしかにそうですね
全員に使い方を公開してないけど誰でも使える状態なら制限という言葉は誤解を生む表現ですね
いずれにしても>> 17さんの意見に賛同です。
GIF・WebPでもアニメーション可能ですので、的を射ているとは思えません。
現状のサイズ制限はアニメーション画像に対する制限としては割と厳しいので、AVIFを解禁したからと言ってアニメーション画像の乱用が増えるとは思えません。
アニメーションを乱用している人は、上述の通り既にGIFやWebPでやっているでしょう。
AVIFになったからといって新規でアニメーションを乱用する人が続出するというのはどのような考えに基づくものでしょうか？
むしろ、GIF・WebPで画質・フレームレート・サイズを落として現状のサイズ制限ギリギリまでに収めていたアニメーション画像の画質がいくらかマシになり、閲覧体験の上昇が期待できます。
OSでの閲覧環境も整いつつあり、Windows 11では標準の画像ビューワーで閲覧可能です。一昔前は何だこの画像形式ダウンロードしたのに見れねえじゃねえかよという文句がよくありましたが、緩和の流れになっています。
再検討をお願いします。
全面的に賛成します。
最近自分でwikiを建てたことは無かったため、新規に作成したwikiの実際の導線については分かりませんが、この文章の内容を考慮すると改善は必須だと感じます。
一部の編集者にのみ公開するというのも不自然じゃありませんか…？(誰でも利用可能なことに変わりはないのでしょうし。)
>> 20の通りとなりますが、そうするくらいなら非推奨であることを明記して全ユーザーへ公開してほしいものです。
賛同します。使えるにも関わらずマニュアルに掲載されていないと混乱を招く原因になります。(一般論としてマニュアルに記載されていないのに使えるというのも意味不明ですし。)
仮に非推奨や今後廃止される予定があるならその旨記載されていればすんなりと受け入れることができます。(むしろ廃止予定ものを明示することで該当Wikiで早めに対処することが可能です。)
また、他のWikiを参考にすればいいというのもいささか乱暴に思えます。マニュアルを整備したうえで活用事例として紹介する分には自然ですが、不完全なマニュアルのまま「他のWikiを参考にしてください」はいかがなものでしょうか。言い方は悪くなってしまいますが、現在の姿勢はユーザーに対する透明性に欠けるものだと感じます。
@wikiwiki
制限付きプラグインについて、該当のWikiの管理者や積極的な編集者などに向けて発信していただくのは難しいでしょうか？
対処が必要な場合に限り該当のWikiの掲示板などでご発言いただく等の対応になると思います。
というのも個別のWikiの事情にはなりますがインクルードを１３０回ほど使用して構成しているページがあり、負荷をさげるためにできることがあるのか不明な状態です。
https://wikiwiki.jp/sample/左・中・右寄せ
↑改善を……
せめて音を無くしたりバックグラウンドの音楽が流れなくなるだけでも……
運営にあまり期待できないのであれば、
有志で非公式プラグインマニュアルWikiを作るのが現実的だろうと思います。
実際（諦めて？）独自に非掲載プラグインの説明記事を載せているWikiもあります。
プラグインマニュアル、さんぷるWiki掲載分については、
運営にコピペの承諾が貰えれば、割とスムーズに整備できるのではと思います。
（全部独自記載となると大変かもですが…）
多用されると負荷が大きくなるため、あまり使用して欲しくない、一部のブラウザで動作しない、
将来機能しなくなる可能性がある、将来廃止することを検討している、お試しで実装している、
忙しくて記載する時間が取れない（さんぷるWikiの方には掲載されていたり※1、未完成下書きがあったり※2）…
…そんなところだろうと思っていましたが、概ねそのようですね。
※1 font、jumplist、shadowheader、showrss2、table_edit、tag、tvote、など
※2 tomorrow_schedule、など
問題は、全て運営側の一方的な都合であることと、
ユーザーには非掲載の理由が不明なことです。
（サービス業でありながら、どちらを向いて仕事しているかという話になってしまいます）
標準プラグインと拡張プラグインに分けて掲載したいならそれでも構いませんが、
マニュアルには、実装されている全てのプラグインを掲載いただき、
非推奨の場合は、非推奨である旨とその理由、自己責任で使用する旨を記載すれば、
よろしいのではないかと思います。
現状ママでは、例えばcontentsxやinclude2、includexは積極使用OKなのか、
それとも使用はできるだけ控えた方が良いのかすら（その理由を含めて）判断できませんが、
例えば「MenuBarでの使用は、負荷が大きくなるため非推奨」など具体的なアドバイスが書かれていれば、
大いに役立つだろうと思われます。
これ、zawazawa以外のサービスのコメント欄でも見かけるようになってきたので、zawazawaの問題じゃなく、firefox自体の問題かもです
アカウントの形式自体は「匿名の権限アカウント」で十分だと考えています(但し管理者権限がある方には、荒らし対策のためどのアカウントからの編集かを閲覧出来る機能が必要な気がします。)が、アカウント制について、Fandomのビューロクラットシステムのような機能が存在することを望みます。
現状wikiwikiではメインパスワードの所持者が最高権限者となり、サブパスワードの所持者が下に付くような形になっていますが、このシステムではメイン管理者に問題が生じた場合にwikiの維持が滞ってしまうリスクがあるほか、wikiはみんなで作成する物ですが、現行のシステムだとメイン管理者一人に全責任が集約されてしまい、みんなで作るというwikiの方針から逸脱しているように感じます。
一方、Fandomのビューロクラットシステムのような機能があれば、最高権限者を複数用意することが出来、誰か一人に問題が生じてもwikiの維持に掛かる影響を最小限に抑えられるため、みんなで作るというwikiの方針とぴったり合うと考えられています。
なお、ビューロクラットシステムを実装する場合、wikiの削除に関するシステムを修正する必要があると思われます。(誰かが勝手にwikiを削除できないよう、正当な理由(サイトの移転等)があるかつ削除にwikiwiki運営の承認が必要にする。また、必要に応じて移転先のサイトへのリダイレクトに置き換える等の対応を行う等。なお、そもそもFandomにはwikiの削除機能が無いため、荒らしに勝手にwikiが消される心配は無い。)
こちらのトピックで言われている機能があれば柔軟に実現できそうです
https://z.wikiwiki.jp/wikiwiki-request/topic/421
他の要望でも運営さんからの回答待ちが幾つかある中で早めにご回答いただきまして、どうもありがとうございます。
以上をもちまして、トピックは締め切りとさせていただきます。以前にお伝えしたとおり、さらに議論を要すると認識される方は新たなトピック作成をお願いいたします。
様々なご意見をいただき、ありがとうございました。
ご要望ありがとうございます。
AVIF 形式の画像については、高い圧縮率や画質面でのメリットがあり、
静止画用途としては魅力的な形式であると認識しております。
一方で、アニメーション利用が可能であることから、
乱用によって転送量が増加し、サーバーや利用者の環境に負担をかける可能性が高い点を懸念しております。
現時点では、需要もまだ限定的であることから、今回は対応を見送らせていただきます。
今後の利用状況やブラウザ対応の動向を注視しつつ、ニーズが明確になった段階で改めて検討してまいります。
ご理解のほどよろしくお願いいたします。
ご指摘ありがとうございます。
マニュアルの整備や動線についてご不便をおかけして申し訳ありません。
プラグインにはいくつかのステータスがあり、すべてを公開前提としているわけではありません。
標準公開プラグイン
一般的に利用されることを想定しており、マニュアルにも掲載しています。
制限付きプラグイン
管理用・検証用・負荷軽減・特定のWIKI向けなど。広く公開すると誤用による負荷や不具合につながる可能性があるため、限定的に利用されています。
廃止予定または移行対象のプラグイン
内部的には動作しますが、将来的に終了や置き換えを予定しているものです。新規利用は推奨していないため、マニュアルには記載していません。
このような理由から、あえて全プラグインをマニュアルに掲載していない場合があります。
とくに「使えるけれど記載がない」ものは、安定性や互換性の観点から広く推奨できません。
一方で、マニュアル不足やアクセスのしづらさは課題と認識しています。
主要プラグインの追加や、リンク配置の改善についても課題と認識しており、できるところから順次対応していく予定です。
また、補足的な学び方として他のWIKIのソースを参考にするのも有効です。
実例を見ることで、マニュアルだけでは分かりにくい工夫や応用を理解しやすくなります。
マニュアルは今後も整備を進めますので、実例とあわせてご活用いただければ幸いです。
ご意見ありがとうございます。
仕組みについて
WIKIWIKI の counter、online、popular は、PukiWiki に標準で搭載されている counter 系のプラグイン とは仕組みが異なり、Go 言語で独自に開発したカウンターサーバー で動作しています。
Amazon DynamoDB をストレージに使い、非同期で分散処理する仕組みによって、アクセスが殺到しても counter 数を壊さず、WIKI の基盤システムに負担をかけずに動かせるようになっています。
ただし、このカウンターサーバーは WIKI のページ情報そのものを持っていないため、存在していないページかどうかを判断することはできません。処理をシンプルに保つことで、大規模アクセスにも耐えられるようにしています。
公平性について
「popular の通算をリセットする機能（いわゆる counter リセット）」を導入すると、ユーザーが counter の数字を操作できることになり、各 WIKI の公平性や将来のアクセス数の目安としての信頼性が揺らぐ可能性があります。
また、rename によって counter の数字を 引き継ぐ ことも、人気ページのアクセス数を別のページへ移せてしまうため、望ましくないと考えています。
対応について
現時点で counter の数字をリセットできるようにする予定はありません。
その代わり、popular の仕組み自体を見直していて、非同期処理から半同期処理に切り替えることを検討しています。いまは非同期のリクエスト数がかなり多く、これを減らしたい狙いがあります。
仕組みとしては、WIKI の基盤システムから内部経路でカウンターサーバーの情報を取ってきて、ページの内容と一緒に出力するやり方です。最近では zrecent もこの半同期処理に移行しました。
この方法なら、WIKI の基盤で存在しないページを除外した集計が可能になります。ただし、集計の負荷がページ生成に乗ってくるため、その点は検討中です。
もしこの仕組みを導入する場合は、「負荷パネル」を見ながらユーザーの方に調整してもらう必要も出てくるかもしれません。
popular プラグインの廃止検討について
popular は、負荷の大きい集計系プラグインです。
現在では Google Analytics も利用できるため、必ずしも popular に依存する必要はありません。必要に応じて REST API を使って Google Analytics のデータを取得し、集計結果を定期的に WIKI ページとして生成する方法も可能です。
また、popular を必要以上に多用してランキングを作成するケースもあり、その結果ページ表示が重くなったり、期待通りの結果が得られないことがあります。こうした事情から、popular は 非同期処理として実装されてきました。
以上の背景を踏まえ、popular の提供方法を見直し、場合によっては廃止も視野に入れています。
私はページ名の規制を利用していないので詳しいことは分かりません。
一度設定してみて、期待通りの動作になっているかご確認ください。
該当するページ名で作成しようとした際、SMS認証画面が表示されれば有効です。
[追記]管理者ログイン状態では規制の影響を受けないため、ログアウトした状態で検証してください。
特定のページ名の作成を制限する場合、規制ルールはどのように作成すれば良いでしょうか？
で良いでしょうか？
コントロールパネル/規制ルールの設定により特定ページの作成・編集を制限することができます。
コントロールパネルで管理できる管理者限定の機能で、NGワードのようにできるなら私も賛成いたします。
具体的には売春斡旋業者にLINE IDや未成年に見せたくないキーワードを含むページ名でページ作成されて困っており、それらのキーワードを含むページの作成を禁止したいと考えています。
日常の合間でトピックを閲覧された方、ならびに投稿してくださった匿名d9d8f@6728cさん、副管理人(WoTBWiki) さん、はやしさん、匿名01062@e41b5 & fc709@e41b5さん、01vさん、ceptさん、お疲れ様でした。(投稿順)
@wikiwiki
>> 29副管理人(WoTBWiki) さんのおっしゃる通り、議論し尽くしたと認識しています。運営さんからの回答をもちまして、どのような回答であってもトピック主にしかできない「解決済」タグ付けを行って一旦、締めさせていただく予定でいます。
運営さんからの次の回答以降も議論の余地があると判断される方はお手数ですが、新たなトピックを建ててからお話しください。
参考URL
傍目には、既に十二分に必要性、あるいは不必要性が述べられているかと思います。
これ以上必要性の議論をしても平行線でしょうし、あとは運営チームに判断を委ねる形でよいのではないでしょうか。
よくまとまっていると思いますが、補強する余地がいくつかあるようなので、お話させてください。
はい、総数と直近は中身が違います。これは間違いなく正しいことです。
しかし中身が違うということから、有益であると主張するのは理論の飛躍があります。なぜなら「唯一無二であるが無用なもの」であることを否定できていないからです。
「直近と違うから総数は有用だ」よりも「総数を見ることでしか得られない、こういうメリットがあるので有用だ」という説明のほうが、説得力があるはずです。
たしかに、そのはずです。
しかし長く運用されてきたシステムは往々にして、「あまり要らないけど外すのも手間だし、何か起こったら嫌だから触らずにそのままにしておく」機能も多いのです。
「昔からあって今もある」ということは必ずしも、積極的に提供する意思があることや有益であることを証明しません。
論拠の一部として添えることは無駄ではありませんが、弱みがある論拠なので尊重されないかもしれません。
Googleアナリティクスに関する「専門知識」とは、いったい何のことでしょうか。
私が使い始めたときの話をすると、事前の学習や訓練に費やした時間はゼロです。
サーバOSの知識やネットワークプロトコルなどの知識は、要求されません。
もっと具体的にハードルの高さを示さないと、いわゆる「食わず嫌い」と見なされて説得力がないように思われます。
という部分は「利用者の個々の事情に基づく議論が活発に継続されたのち、挙げられた要望や案についてwikiwiki運営が公平性・システム負荷・運営方針をベースに総合的に判断する」と解釈しております。したがって壁打ちのような様相になっても、各利用者のそれぞれの立場からの発言は重要だと認識しております。
この解釈と利用者のあるべき議論スタンスについて討論したいわけではないので、popularプラグインに関する意見を述べさせていただきます。
はやしさんが整理された、「popularが示す数値のうち、総数ではなく直近の数字を使えばよいのでは」「Googleアナリティクスを使えばよいのでは」という２つの論点について、某スマホゲームのwikiの管理者として意見を表明します。
「popularが示す数値のうち、総数ではなく直近の数字を使えばよいのでは」
「今日100があるのだから人気100の重要性は薄く、削除されたページにはアクセスカウンターが増えていかないのだから、カウンターリセット等の機能がなくとも十分で、新機能の開発のリターンが薄い」という旨の主張と理解しています。
私が管理しているwikiの今日100には、最近更新されたページや、ゲーム側で追加された新要素・新キャラクター、直近で開催されるイベントがリストアップされます。
一方、人気100では、登場するキャラクターの一覧ページや、日課・週課の攻略情報が集約されたページ、ゲームシステムの解説ページなど、長期間に渡って一定数の需要があるページが上位に並んでおります。
したがって、総数と直近では差別化がなされています。両方をリストアップするページを置くことに意味があるのであれば、人気100に残りやすい、削除前・リネーム前の人気ページのカウンター数への対処を実現していただきたいのが要望です。
（wikiwikiで新しくwikiを立てるとき、今日100と人気100はあらかじめ用意されており、メニューバーにもリンクが設置されていたものと記憶していますので、wikiwiki運営側もこの２つの差別化については認識されていると考えています）
Googleアナリティクスを使えばよいのでは
過去の款冬華さんからの発言が、十分に理論的に利用価値を説明していると思います。
上記の発言に全面的に同意します。
また、専門知識に疎い管理者・編集者以外にも、利用者にも恩恵がある旨の主張も付け加えさせてください。
長期間にわたって運用されるwikiでは、どうしてもメニューバーが複雑化したり利便性が低下したりする傾向があると考えています（こちらについて事例が必要であれば挙げることもできます）。
その中で、サイト内のカウンター統計が機能している人気100は、新しくサイトを利用したユーザに対してMenuBar・サイト内検索に各ページへ遷移するためのもう一つの選択肢を付け加えることとなり、一定の利用価値がないでしょうか。
ここがリネーム等で十分に機能していない・リンク先が存在しないと表示されるのであれば、やはり修正の意義があると思います。
今の運営さんの話を元にしても議論にならない、という点については確かにそうかもしれません。
しかし最終的な判断を下すのは結局のところ、運営さんなのです。
なんとかしてもう少し運営さんから話を引き出さないと、お互い（運営さん＆機能追加を求める意見）の話がかみ合わない可能性があります。
いいえ違います。
そこの主語は不明確ですが運営であるべきです。そうでないなら運営の認識が誤りであるというのが私の意見です。
ユーザーには利用状況も内部の原理や負荷も見えないので議論になりません。何をもって公平かなど、気持ち次第でなんとでも言えるので、そこをに注力して話をしても発散するだけです。
popularは有用です。
私の例で言えば、popularやcounterのアクセス数からメニューの掲載基準や位置の決定に活用しました。
当時メニューが無法地帯だったので私はそれを整理しようとしました。
そのとき私は管理者ではなく来たばかりの新人でしたが、提案を数値に基づいて示したので話がスムーズだったと思います。