改ページにつき全文引用

apple502j wrote:

inoking wrote:

別話題ですみません。
Scratch 3.0 への提案 #1493 からもってきました。

以下のような状況について
システム的に対応できることがありますか？

1. リミックスした
2. その後、リミックス元の作者がリミックス先から逆に完全コピーした

どちらが完全コピーしたのか分からない

編集日時とかですかね?

リミックス元が微細な変更をしただけかもしれません。

Windows1000000_2 wrote:

そもそも報告によって作品が消されることがなかったら報告の意味ではありません。

作品が消させることだけが報告の意味ではありません。
消されなかったとすれば、報告が間違っていた、あるいは、証拠が不十分だったということになり、その作品に問題がないことが分かります。
また、消されないとしても、共有が解除されるだけという処分もあります。

#120 について：
#81 と照らし合わせて疑問に思ったのですが、編集日時はscratch のサーバーにログとして残っているものなのでしょうか？その時に追加したり削除したブロックなりコードなりの情報と合わせて、という意味ですが。

そして、#118 ですが、現実問題としては無理ではないかと想像しているのですが、システム的に対応するためには「プロジェクトを保存中」のときのやっていることをログとして保存（例えば３年間くらい）しておくことではないかと思います。

https://ja.scratch-wiki.info/wiki/%E3%83%AA%E3%83%9F%E3%83%83%E3%82%AF%E3%82%B9
も見てくださいね。

konnbusann wrote:

https://ja.scratch-wiki.info/wiki/%E3%83%AA%E3%83%9F%E3%83%83%E3%82%AF%E3%82%B9
も見てくださいね。

そのリンクとどういう関係があるのでしょうか。

konnbusann wrote:

https://ja.scratch-wiki.info/wiki/%E3%83%AA%E3%83%9F%E3%83%83%E3%82%AF%E3%82%B9
も見てくださいね。

そのURLはScratch-Wikiの「リミックス」の記事ですね。
次回からリンクを張る際はリンク先のことも見出しだけで良いので書いていただけると助かります。

さて、本題に戻りますが、現在このトピックでは konnbusannさんがリンクを張ってくださった「リミックス」の記事の「課題」の節に記載されている

リミックスに関して、最近問題となっているのは、中身の加工なしでの共有である。中身を一切変えないで投稿されていたりする作品に対する処置が、議論の対象になったりもする。また、本当に僅かに変更を加えたものを、リミックスと認めるかどうかも、議論の対象になっており、課題の一つとなっている。(それを完コピとも言う) これまでに、完コピが原因でプロジェクトの投稿をやめてしまった、あるいは、気力をなくしてしまったScratcherもたくさんいる。

の部分について議論しています。
議論の範囲については、下の画像を参照してください。
ーーーーーーーーーーーーーーーーーーーーーーーーーーー

ーーーーーーーーーーーーーーーーーーーーーーーーーーー

現在このトピックの議論によって出ている現状の「完コピリミックス対策」の問題点は

1. 完コピを機械的に判定する方法が存在しないこと
2. 「報告」が機能していないと感じる場面がある

の大きく2点となっています。
その解決案として

1.についてはプロジェクトの差分を取って n% 以上の変更点が無いとリミックスできないようにする
と言う案が出ています。

また 2. については解決案は出ていないものの、報告を機能させるためにはどのように我々が行動すべきかを考えよう
と言うことを主眼に置いて議論を進めています。

STへの報告について、そもそもSTの人的リソースが足りていないことは明らかです。
また、基本的に報告は英語で送る必要がありますが英語に堪能な方は日本に少なく、
Google翻訳などの機械翻訳サービスを頼った報告になりがちかと思われます。

そこで、「報告」機能について「チェックリスト」を用いて客観的なスコアをSTに送信する方式を取り入れることを提案したいです。

現状の「報告」の問題点は

1. 大前提としてSTは毎日数百(場合によっては数千)以上の「報告」を受け取っているものと思われる
2. 文章を書く形式になっているため報告する側の負担が大きく、ST側も原因特定が困難になる場合があると予想される
3. いたずらで適当な文章を送ることができる

の3点だと思います。

1については「統計情報」から 2019年3月 ~ 2020年3月までのプロジェクト増加数は1日あたり平均約34,186 件となっています。
また、Wikiの「Scratchチーム」のページからSTの現在の人数はおそらく46人と思われます(メンバーの節の最終更新は2020年3月12日)。
このことを踏まえて、1日当たりその日のうちに共有された5%のプロジェクトが報告されたと仮定すると約1,709件となり、
もしST全員が対応を行ったとしても1人当たり約37件の報告を検証・対応しなければならないことになります。
これは現実的に考えてほぼ不可能な数字です(勤務時間を1週間で40時間、1週間を7日とすると、10分に1件対応を終わらせなければ報告が溜まっていく計算)。

2については現在の「報告」機能は英語圏寄りの色が強いため、英語をしゃべることができない人たちへの敷居が比較的高いものと思われます。
その結果、ほとんどの場合でGoogle翻訳などの機械翻訳を頼ることと思われますが、そうなった場合私たちが思っている本当のことを
STに正しく伝えられないかもしれません。これは私たちにとってもSTの方々にとっても負担となります。

3についてはそのままの意味です。スパムの報告を簡単に送ることができてしまうことは問題があると思います
(もちろん相応の処分があると思われますが、その処分にもSTの方々の貴重な労働時間が消費されます。)

以上の3点をカバーすることができる方法が「チェックリスト制の報告」だと考えました。

チェックリストはあらかじめ対応する翻訳を行っておけばわざわざ翻訳する必要もありませんし、
チェックリストにすることで感覚のずれ(完コピの度合いの裁量など)を減らすこともできると思います。
また、Scratchの機能そのものの改変を行わずとも、報告用のページを作成してサイトに組み込む程度の改変で済むため、改修コストも比較的小さいと思われます。

加えて、チェックリストの内容は最低でも50問以上とし、そのうち n% 以上の該当項目がある場合のみSTに送信される仕組みにするとSTの方々への負担軽減につながると思います。
50問以上と言うのはカテゴリ・チェック項目を細分化することにより、明確にそのプロジェクトの良くない部分と問題ない部分をふるいにかけることが目的です。場合によっては50問以上が適切かもしれませんしその逆かもしれません。
実際に送信されるレポートは「Yes」回答の部分のみが抽出されたものとなることを想定しています。

長々と書いてしまいましたが、この意見についてどのように感じたか書いていただけるとありがたいです。

#127:
ですが、チェックリスト制の報告にしても、そのチェックリストの中に該当する報告理由がない部分がある場合、そこを文章でSTに詳しく説明する必要があるので、そこは考えなければと思います。

50問以上というのは多すぎで途中で挫折する人が絶えないでしょう。
ユーザーには、報告させたくないと捉えられると思います。

inoking wrote:

50問以上というのは多すぎで途中で挫折する人が絶えないでしょう。
ユーザーには、報告させたくないと捉えられると思います。

私が考えているのは必要な項目にチェックをつけるものです。
50問直列に質問が続くものではないです。

例えば以下のような構成になります。

カテゴリ：完コピ
チェック1：その作品は誰かの作品のリミックスですか？
チェック2：その作品は誰かの作品の完全な複製ですか？
チェック3：その作品は適切なクレジットが表記されていますか？
・・・

カテゴリ：不適切な作品
チェック1：その作品には暴力表現が含まれていますか？
チェック2：その作品には性的な表現が含まれていますか？
チェック3：その作品には差別的表現が含まれていますか？
・・・

このようなカテゴリごとにScratchで報告対象となるものをリストアップしておき、
その中で問題のある項目にのみチェックをつけ、提出すると、その問題点のみがSTに報告される仕組みです。
上の例にチェックをつける場合、例えば

カテゴリ：完コピ
✔　チェック1：その作品は誰かの作品のリミックスですか？
✔　チェック2：その作品は誰かの作品の完全な複製ですか？
チェック3：その作品は適切なクレジットが表記されていますか？
・・・

カテゴリ：不適切な作品
チェック1：その作品には暴力表現が含まれていますか？
チェック2：その作品には性的な表現が含まれていますか？
チェック3：その作品には差別的表現が含まれていますか？
・・・

上記のようにチェックがつけられた場合はSTには

カテゴリ：完コピ
✔　チェック1：その作品は誰かの作品のリミックスですか？
✔　チェック2：その作品は誰かの作品の完全な複製ですか？

というレポートが送信されます。

Windows1000000_2 wrote:

#127:
ですが、チェックリスト制の報告にしても、そのチェックリストの中に該当する報告理由がない部分がある場合、そこを文章でSTに詳しく説明する必要があるので、そこは考えなければと思います。

そのような事がないように網羅することが目標です。
また、そのような不完全なシステムを作るのであれば現状と変わりません。

まずいろんな人に必ずコミニティガイドラインと利用契約を読んでもらう必要があると思う。

「利用契約」ではなく「利用規約」ですね。
コミニティガイドラインはScratcherになる際に読みますが、一度読んだだけで完全に記憶できるわけではないと思います。自分は毎週見ているのに覚えられないのに、「コミニティガイドラインなんてどうでもいい」といい普段読まない人が一度読んだだけで記憶できるとは思いません。
利用規約は英語で、長いので、読む気が起きないんだと思います。

そういえば、完コピの禁止って利用規約のどこに書いてありますか。4.4ですか。

yukku wrote:

「利用契約」ではなく「利用規約」ですね。
コミニティガイドラインはScratcherになる際に読みますが、一度読んだだけで完全に記憶できるわけではないと思います。自分は毎週見ているのに覚えられないのに、「コミニティガイドラインなんてどうでもいい」といい普段読まない人が一度読んだだけで記憶できるとは思いません。
利用規約は英語で、長いので、読む気が起きないんだと思います。

そういえば、完コピの禁止って利用規約のどこに書いてありますか。4.4ですか。

それなら利用規約を翻訳する取り組みが必要だと思います

翻訳することで、意味が変わってしまうことがあるので、翻訳してないそうです。

konnbusann wrote:

それなら利用規約を翻訳する取り組みが必要だと思います

では聞きます。TOEIC 990点を持ってる人が長文を翻訳しても、その翻訳文は100%正しいと言えるのでしょうか。言えませんよね?
翻訳しても、原文と意味と違うということも十分あります。

「契約書 翻訳 依拠」で検索してみるとよいかもしれません。
ボランティアで翻訳した場合はあくまで参考訳となると思います。
いずれにしても、Scratchの翻訳サーバーに利用規約のエントリーがないため、公式のWebサイトでは翻訳できません。

Windows1000000_2 wrote:

konnbusann wrote:

それなら利用規約を翻訳する取り組みが必要だと思います

では聞きます。TOEIC 990点を持ってる人が長文を翻訳しても、その翻訳文は100%正しいと言えるのでしょうか。言えませんよね?
翻訳しても、原文と意味と違うということも十分あります。

あ…ほんとだ…

konnbusann wrote:

それなら利用規約を翻訳する取り組みが必要だと思います

非公式ですが、日本語訳ならあります。
ただあくまで非公式なので、参考程度に見ていってください。

yukku wrote:

そういえば、完コピの禁止って利用規約のどこに書いてありますか。4.4ですか。

4.4はざっくりですが、「カスタムしたscratchエディターで作品をアップロードしてはいけない」ということを述べていると思うので、違うような気がします…“利用規約なら”(質問コーナーでも述べましたが)僕は、

3.1スクラッチチームは表現の自由をサポートします。ただし、Scratchは幅広いユーザーを対象としており、一部のコンテンツはScratchコミュニティには不適切です。Scratchサービスを次のように使用することはできません。
～～～
2. 他の人がスクラッチユーザーであるかどうかにかかわらず、他の人を脅迫、嫌がらせ、または脅迫する。

この文面にある嫌がらせに該当するからだと思います。daikonnbatakeさんと被りましたね…
また、abeeさん曰く完コピはコミュニティーガイドラインの建設的になろう。や誠実であること。に、該当するとのこと。
今一度利用規約を読み直してみましたが、具体的な完コピに関する表現は見つかりませんでした。

クラウド変数がリミックスされたときには保持されない特徴を生かしてリミックスされたときに「リミックスありがとう。変更を加えてね」とメッセージを出すことはできると思うのですが悪用すればリミックスブロッカーも作れてしまいますね。