パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

[FR提案]編集・審査中タレコみ公開システム案(要望)」記事へのコメント

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

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

          ただ、“~という件”ではあいまいなので、編集・審査中のタレコみを表示する際には「日付-連番」くらいの通し番号とか付加してもらって、「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] 併用中
                親コメント

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

処理中...