パスワードを忘れた? アカウント作成
383810 journal

NoGoodの日記: [FR提案]編集・審査中タレコみ公開システム案(要望) 10

日記 by NoGood

このコメントで記述した案を Feature Requests に登録しました。
コメントの内容と全く同一ですが、周知のため日記エントリにも再掲します。
───── 以下提案内容 ─────

編集・審査中のタレコみキューを公開する場合の運用を考えてみたんですが、以下のようなアイディアはいかがでしょう?

まず、問題のあるタレコみがあった場合の対策として、「非公開」チェックボックスを用意します。
このチェックボックスは編集者にしか見えず、編集者にしか操作できません。
この「非公開」チェックボックスがチェックされていると、

「非公開」の“タレコみ人”による“トピック”トピック・“セクション”セクションのタレコみが編集・審査中です(“”内は対応する名称に置換)。

という表示だけが公開されるようになる、という挙動になります。
もちろん、「非公開」チェックボックスがチェックされていない場合にはタレコみ全体が公開されます。

タレコみが行われてから公開・非公開に至るシステムおよび編集者の挙動としては、まず安全側に倒して、タレコみがあった直後(つまり全てのタレコみ)は「非公開」チェックボックスがオンになった状態でキューイングされます。
編集者はタレコみ内容を一通りながめ、問題ないと判断したら(大半がそうなるはずですが)「非公開」チェックボックスのチェックを外します。
こうすることで公開されます。
問題のある内容の場合、チェックボックスは外さずに放置しておくことで、なんらかのタレコみがあったことだけがユーザに周知されることになるわけです。

もし、他の編集者がやっぱりこのタレコみは公開しておくのはマズい、と判断したら再度チェックボックスをチェックして非公開に、という操作も特に問題なさそうです。

この方法の問題点として、チェックボックス操作の分、編集者に少し負担になってしまう、という点と、編集者がサボる(^^;といつまでも公開されない、という点ですが、そこは努力していただくとして(^^;

さらに編集者に負担を強いる機能強化としては、上の非公開のままで放置するものについては、「非公開タレコみの概要」を記述してもらい、上の表示に加えこの概要を表示する、というものです。

「非公開」の…

という部分が

“概要”のため非公開の…(“”内は対応する名称に置換)

で置き換わり、具体例としては

個人を誹謗中傷する内容のため非公開の…
 
シェアウェアのライセンスキーが含まれている内容のため非公開の…
 
支離滅裂・意味不明のため非公開の…

などといった内容になることを想定しています。

こちらのアイディアの問題点も編集者の怠慢で機能しなくなる点です(^^;

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 編集者が、このタレコミを採用するかしないか迷っている時などに活用できそうですね。
    • > 編集者が、このタレコミを採用するかしないか迷っている時などに活用できそうですね。
      編集・審査過程を公開してもらえれば、この間の gcc 4.1 の記事 [srad.jp]のような誤った内容を掲載してしまう、といったようなことを、誰かが掲載前の時点で指摘することで未然に防げるようになる…かもしれません、というメリットもありますね。
      # タレコみでフレームが発生したりしそうですけど ;-p
      --
      mobile ID portable_NoGood [slashdot.jp] 併用中
      親コメント
      • 確かに。
        ただ一般の方がコメントを付けるような形は思わしくないかも。
        それなら投票システムのように 採用推薦/取り下げ希望/不実/ガセビア(ぇ とか(笑
        親コメント
        • Re:面白いかも。 (スコア:2, すばらしい洞察)

          by NoGood (6817) <nogoodNO@SPAMchobi.net> on 2005年11月29日 21時10分 (#839698) ホームページ 日記
          > ただ一般の方がコメントを付けるような形は思わしくないかも。
          > それなら投票システムのように 採用推薦/取り下げ希望/不実/ガセビア(ぇ とか(笑
          いやいや、そこまで新たに機能を追加するようなことは想定していなくて、既にある機能だけで済むよう、別件として新たにタレコむことによって編集者に通知するような状況を念頭においています。
          特定のタレコみに対し編集者に通知したい(例えば誤報であることを知らせたい)場合、
          「~という件がタレコまれているようですが、これは誤報です。ソースは…です。」
          といったような内容で独立したタレコみをしてもらえば済むだけの話かな、と。
          # 今までも、タレコんだ直後に内容訂正の追加タレコみをした、とかいう話をどなたかの日記で読んだ記憶があります。

          ただ、“~という件”ではあいまいなので、編集・審査中のタレコみを表示する際には「日付-連番」くらいの通し番号とか付加してもらって、「No.???のタレコみについてですが…」と記述できるくらいのコード追加はあってもいいかな、とは思います。
          --
          mobile ID portable_NoGood [slashdot.jp] 併用中
          親コメント
          • >いやいや、そこまで新たに機能を追加するようなことは想定していなくて、既にある機能だけで済むよう、別件として新たにタレコむことによって編集者に通知するような状況を念頭においています。

            同意です。投稿前のたれこみにコメント機能を付けると(特にマンパワー的な)負荷が高いです。

            ># 今までも、タレコんだ直後に内容訂正の追加タレコみをした、とかいう話をどなたかの日記で読んだ記憶があります。

            日記で書いた記憶はないですが、何度かあります。同じタイトルで末尾に「(修正版)」とか書いて。
            修正前のが却下数にカウントされるのであまり好きではないのですが。

            >ただ、“~という件”ではあいまいなので、編集・審査中のタレコみを表示する際には「日付-連番」くらいの通し番号とか付加してもらって、「No.???のタレコみについてですが…」と記述できるくらいのコード追加はあってもいいかな、とは思います。

            これを実装すると、基本的にたれこみの履歴(データベース)を作らないといけないので、システムが複雑になる度合いが一気に高くなり、コード量が増えたり、システムの負荷が高まるのではないでしょうか。とは言え、(slashcodeは読んでいないのですが)日付と大まかな連番(?)も合わせて公開するのは比較的簡単なのでしょう(現在のシステムでも、この数字は採用されると記事のURLにも含まれているようです。御存知かとは思いますが)。
            上記したように、これまで訂正版をたれこみした場合でも編集者には問題なさそうだったので、たれこみ量が現状程度なら無くても大丈夫かも知れません。

            たれこみを修正する場合にはタイトルを同じにして、末尾に「(修正版)」と書きましょう、とFAQに書き加えると良いのかも。と、ここまで書いて、要らないかなとも思いつつ、コメント [osdn.jp]しておきました。

            親コメント
            • > これを実装すると、基本的にたれこみの履歴(データベース)を作らないといけないので、システムが複雑になる度合いが一気に高くなり、コード量が増えたり、システムの負荷が高まるのではないでしょうか。
              そこまでキチンとした採番システムを想定していたわけではなくて、履歴管理とかをしないタレコみ受付番号、みたいな感じです。
              例えて言うなら同一営業日中は単調増加の番号札を発行する銀行の窓口待ち受けシステムみたいな感じでしょうか。

              具体的には、タレコみボタンを押した時には「このタレコみはタレコみ受付番号 2005-11-30-00001 でキューイングされました」とか表示されて、編集・審査中公開システムのほうにも
              2005-11-30-00001:「非公開」の“タレコみ人”による“トピック”トピック・“セクション”セクションのタレコみが編集・審査中です
              とか表示されるわけです。
              この受付番号は履歴として管理したりせず、発番したらそれっきり(ユニークな番号であることをシステム側で保証するだけ)というようなものを想定しています。
              それで 2005-11-30-00001 が採用されても、却下されても、その通し番号は再び使われることはない、というわけです。
              この番号が使用済みであるかどうか、というようなことは採番時に同じ番号を発番しない(日付+連番で連番部分がループしなければ良いので)ことだけで保証し、使用済みの番号一覧を抱えたりはしない、それで十分じゃないかなと。

              とはいえ、日付-連番の形式だと、連番部分の桁数が溢れないよう十分に大きな桁数(一日なら int で十分じゃないでしょうか)を確保しておく必要がありますが、万一溢れた場合、連番部分はループさせて、日付-連番-枝番 にシフトする、というようなコードを埋め込んでおけば、もうタレコみ DoS が発生しても大丈夫、という気がします。
              > 現在のシステムでも、この数字は採用されると記事のURLにも含まれているようです。御存知かとは思いますが
              確かに掲載された記事の sid を見ると連番になってないので、タレコんだ時点で(たとえそれが却下される内容のものであっても)過去の記事・タレコみに対してユニークな sid を採番している可能性は高いと思います。
              もしそうであれば sid を表示してもらえば済む話なので、上のタレコみ受付番号は不要ですね。
              # あれは単なる連番じゃなくてハッシュ値とかで掲載時に採番、とかいう話だと上のタレコみ受付番号の話が復活するわけですが ;-p
              --
              mobile ID portable_NoGood [slashdot.jp] 併用中
              親コメント
              • # 帰ってきました。

                タレコみに対してユニークな sid を採番している可能性は高いと思います。

                はい、タレコミにはsubidという連番がついています。

                で、出かけているあいだに思い出したのですが、編集者用のメッセージの設定 [srad.jp]に「新しいタレコミ」というのがありまして、タレコミがあると以下のようなメールが届くようにできます。

                Anonymous Coward has submitted a new story on スラッシュドット ジャパン .

                    強盗を生中継するシステム
                    (編集画面へのURL)

                subidは編集画面へのURLに含まれています。

                このメッセージングを一般に公開するというのも一つの方法かもしれません。その場合、編集画面へのURLは、権限がないとアクセスできないはずですが、一般向けには別の形にした方がいいかも。

                親コメント
              • > タレコミにはsubidという連番がついています。
                ではこの subid を表示してもらうということで解決ですね ;-)
                > このメッセージングを一般に公開するというのも一つの方法かもしれません。
                直接公開してしまうと、題名そのものに公開してはマズイ内容が含まれていた場合に問題になるような気がします。
                # これは以前 Acanthopanax さんに指摘されたことだったと思いますが…(^^;
                --
                mobile ID portable_NoGood [slashdot.jp] 併用中
                親コメント
              • 直接公開してしまうと、題名そのものに公開してはマズイ内容が含まれていた場合に問題になるような気がします。

                希望者のみメール配信なら、不特定多数が閲覧可能というわけではないのでよいかと思ったのですが、たしかに特定多数ではあるので、やっぱりマズいかもしれませんでした。

                親コメント
              • > 希望者のみメール配信なら、不特定多数が閲覧可能というわけではないのでよいかと思ったのですが
                あ、「一般に公開」というのはメッセージングのシステムをそのまま踏襲するイメージでしたか。
                私は Slashcode2.5 β運用時に動いていた、編集・審査待ちページのイメージでした(^^;
                > たしかに特定多数ではあるので、やっぱりマズいかもしれませんでした。
                メッセージングの仕組みを使う場合には ID 限定で希望する人のみが閲覧することになるとはいえ、問題になるケースはありそうですね。
                --
                mobile ID portable_NoGood [slashdot.jp] 併用中
                親コメント
typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...