scratch2.0の提案

kaaramochi

itnkmkw wrote:
inoking wrote:
itnkmkw wrote:
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
そのためにどうすればよいですか？
話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。

問題はないけど、いつまでもあっても困るコメント、もう用済みのコメントについては、報告は理不尽だと思います。

apple502j

itnkmkw wrote:
inoking wrote:
itnkmkw wrote:
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
そのためにどうすればよいですか？
話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。

裁判所は荒れます。(個人の意見です。)

inoking

apple502j wrote:
itnkmkw wrote:
inoking wrote:
itnkmkw wrote:
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
そのためにどうすればよいですか？
話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。
裁判所は荒れます。(個人の意見です。)

呼び名だけのことかもしれませんが「裁判」というものは既に最終手段にあたると思います。

あらためて、
略されていた元の提案を引用します。

・自分がオーナーのスタジオに投稿されたコメントの削除

削除を許してしまうと
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。

荒らしと思われるコメントに対しては
注意→警告→報告
で対応することはルールにのっとった真っ当なやり方だと思います。

「問題はないけどいつまでもあるコメント」は問題ないのだから放置しておけばよいと思います。

mochimochiking

inoking wrote:
削除を許してしまうと
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。

自分に都合の悪いコメントを削除する人が現れるのですべてのコメントを削除不可にすべきだと思います。

inoking

mochimochiking wrote:
inoking wrote:
削除を許してしまうと
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。
自分に都合の悪いコメントを削除する人が現れるのですべてのコメントを削除不可にすべきだと思います。

それは「自分のプロフィールのコメントを削除できなくする」という提案ですか？
私もそれがよいと思いますが現状なぜできているのかが謎ですね。
理由を探したほうがよいかもしれません。

mochimochiking

inoking wrote:
mochimochiking wrote:
inoking wrote:
削除を許してしまうと
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。
自分に都合の悪いコメントを削除する人が現れるのですべてのコメントを削除不可にすべきだと思います。
それは「自分のプロフィールのコメントを削除できなくする」という提案ですか？
私もそれがよいと思いますが現状なぜできているのかが謎ですね。
理由を探したほうがよいかもしれません。

「自分のプロフィールおよび自分の作品のコメントを削除できなくする」という提案です。
誰か理由を知っているかもしれませぬから、質問コーナーに投稿しました。

itnkmkw

inoking wrote:
apple502j wrote:
itnkmkw wrote:
inoking wrote:
itnkmkw wrote:
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
そのためにどうすればよいですか？
話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。
裁判所は荒れます。(個人の意見です。)
呼び名だけのことかもしれませんが「裁判」というものは既に最終手段にあたると思います。

あらためて、
略されていた元の提案を引用します。
・自分がオーナーのスタジオに投稿されたコメントの削除

削除を許してしまうと
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。

荒らしと思われるコメントに対しては
注意→警告→報告
で対応することはルールにのっとった真っ当なやり方だと思います。

「問題はないけどいつまでもあるコメント」は問題ないのだから放置しておけばよいと思います。

mochimochiking wrote:
inoking wrote:
mochimochiking wrote:
inoking wrote:
削除を許してしまうと
（自分のプロフィールのコメントのように）自分に都合の悪いコメントを削除する人が現れるのでよろしくないと思います。
自分に都合の悪いコメントを削除する人が現れるのですべてのコメントを削除不可にすべきだと思います。
それは「自分のプロフィールのコメントを削除できなくする」という提案ですか？
私もそれがよいと思いますが現状なぜできているのかが謎ですね。
理由を探したほうがよいかもしれません。
「自分のプロフィールおよび自分の作品のコメントを削除できなくする」という提案です。
誰か理由を知っているかもしれませぬから、質問コーナーに投稿しました。

ぼくは，削除できた方がいいと思うのですが…

itnkmkw

inoking wrote:
apple502j wrote:
itnkmkw wrote:
inoking wrote:
itnkmkw wrote:
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
そのためにどうすればよいですか？
話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。
裁判所は荒れます。(個人の意見です。)
呼び名だけのことかもしれませんが「裁判」というものは既に最終手段にあたると思います。

いえ。裁判と言うのは二種類有りまして，
民事裁判と刑事裁判です。刑事裁判の方をみなさん思い浮かべ，報告をこちらだけでやっているようなものだと思うのかもしれませんが，僕が言っているのは，民事裁判です。和解に導くために裁判官が仲介に入るものです。ですから，報告はできるだけ避けたいので，削除可能がいいです。自分に都合の悪いコメントとはたとえばどのようなものですか？自分の個人情報を自分のプロフィールに書かれた場合，消せた方がいいではないですか。

itnkmkw

apple502j wrote:
itnkmkw wrote:
inoking wrote:
itnkmkw wrote:
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。
もっと平和に解決したいです。
そのためにどうすればよいですか？
話し合い。そのための裁判所的なものを作る予定です。（スタジオで）方法はいくらでもある。報告は最終手段としたいです。
裁判所は荒れます。(個人の意見です。)

荒れないために裁判所があるのです。（荒れる可能性はあるけどそんなこと言ってらんない）

kan217

mochimochiking さんからの削除対象案についての検討
赤文字がinokingのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです。
灰文字がMMGISSさんのコメントです。
紫がkan217さんのコメントです。

見た目カテゴリ

このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」

→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
必要性はないと思います

調べるカテゴリ

<触れた色 ::sensing>//複数あるときに疑問

→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。

(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明

→定数とは限りません。必要性については要検討

(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明

→定数とは限りません。必要性については要検討
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。

(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明

→定数とは限りません。必要性については要検討

(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問

→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。

(押されたキー :: sensing)//複数あるときに疑問

→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。

<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能

→簡単かどうかは分かりませんが汎用性がないと思います。

(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問

→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
現状でも例えばマイクやカメラで同様の状況が発生しています。

変数カテゴリ

変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
他にはどのような意見がありますか。
https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/ についても考慮お願いします。

(変数 [ v] のx座標 ::variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

(変数 [ v] のy座標 ::variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の三つは、実装されてもいいと思います。
上の三つの実装に賛成。

変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

(変数 [ v] の表示形式::variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の二つは、どんなときに使うんでしょうか。

[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

([変数 v] のスライダーの最小値 :: variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

([変数 v] のスライダーの最大値 :: variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の四つは、そこまで汎用性があるでしょうか。

<変数 [ v] がクリックされた :: variables>//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の二つは、実装されてもいいと思います。
リストの大きさなどが勝手に変わるから実装したいということだと思うので、それが変わらないようにすればいいと思います

その他編集/実行
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。

話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
追加賛成です。
1日に賛成

・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。

その他

・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
追加に賛成

・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。

Last edited by kan217 (Sept. 26, 2017 07:59:15)

mochimochiking

mochimochiking さんからの削除対象案についての検討
赤文字がinokingのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです。
灰文字がMMGISSさんのコメントです。
紫がkan217さんのコメントです。

見た目カテゴリ

このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」

→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
必要性はないと思います

調べるカテゴリ

<触れた色 ::sensing>//複数あるときに疑問

→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。

(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明

→定数とは限りません。必要性については要検討

(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明

→定数とは限りません。必要性については要検討
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。

(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明

→定数とは限りません。必要性については要検討

(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問

→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。

(押されたキー :: sensing)//複数あるときに疑問

→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
Scratchは配列を返す言語仕様出はないため実装は難しい。

<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能

→簡単かどうかは分かりませんが汎用性がないと思います。

(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問

→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
現状でも例えばマイクやカメラで同様の状況が発生しています。

変数カテゴリ

変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
他にはどのような意見がありますか。
https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/ についても考慮お願いします。

(変数 [ v] のx座標 ::variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

(変数 [ v] のy座標 ::variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の三つは、実装されてもいいと思います。
上の三つの実装に賛成。
　なぜですか。

変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

(変数 [ v] の表示形式::variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の二つは、どんなときに使うんでしょうか。

[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

([変数 v] のスライダーの最小値 :: variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

([変数 v] のスライダーの最大値 :: variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の四つは、そこまで汎用性があるでしょうか。
値を変更する場合が思い付かない。故に要らないと思う。

<変数 [ v] がクリックされた :: variables>//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の二つは、実装されてもいいと思います。
リストの大きさなどが勝手に変わるから実装したいということだと思うので、それが変わらないようにすればいいと思います
紫に同意

その他編集/実行
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。

話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
追加賛成です。
1日に賛成
皆さん作成に賛成のようですので

・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。

その他

・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
　各自が１,2行ほどで記述すればそんなに長くならないのでは
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
追加に賛成

・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
それでは、この提案却下し、私の作品の検索機能を追加でいいですか。

inoking

itnkmkw wrote:
いえ。裁判と言うのは二種類有りまして，
民事裁判と刑事裁判です。刑事裁判の方をみなさん思い浮かべ，報告をこちらだけでやっているようなものだと思うのかもしれませんが，僕が言っているのは，民事裁判です。和解に導くために裁判官が仲介に入るものです。ですから，報告はできるだけ避けたいので，削除可能がいいです。

スレ違いなので一言にしますが、民事裁判も通常の話し合いで解決できない時の「最終手段」です。

itnkmkw wrote:
自分に都合の悪いコメントとはたとえばどのようなものですか？

不適切な言動を指摘した際に、後で指摘コメントごと消されていました。
それにより、指摘があった事実ももみ消されてしまいました。

itnkmkw wrote:
自分の個人情報を自分のプロフィールに書かれた場合，消せた方がいいではないですか。

その場合は即刻報告して削除してもらえばよいでしょう。
重要性の高いものはすぐ対応してくれると思われます（若干のタイムラグは発生しますが
書き込んだ相手にはアカウント凍結のような措置も取らないといけないので
書き込みがあった事実も消えてしまうのはよろしくありません）。

削除できるということは安易な書き込みを助長することにもなります。

itnkmkw

(押されたキー :: sensing)//複数あるときに疑問
→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。

最後に押されたキーにすればどうですか？僕はこれがなくて困ってます。

itnkmkw

inoking wrote:
itnkmkw wrote:
いえ。裁判と言うのは二種類有りまして，
民事裁判と刑事裁判です。刑事裁判の方をみなさん思い浮かべ，報告をこちらだけでやっているようなものだと思うのかもしれませんが，僕が言っているのは，民事裁判です。和解に導くために裁判官が仲介に入るものです。ですから，報告はできるだけ避けたいので，削除可能がいいです。
スレ違いなので一言にしますが、民事裁判も通常の話し合いで解決できない時の「最終手段」です。

itnkmkw wrote:
自分に都合の悪いコメントとはたとえばどのようなものですか？
不適切な言動を指摘した際に、後で指摘コメントごと消されていました。
それにより、指摘があった事実ももみ消されてしまいました。

itnkmkw wrote:
自分の個人情報を自分のプロフィールに書かれた場合，消せた方がいいではないですか。
その場合は即刻報告して削除してもらえばよいでしょう。
重要性の高いものはすぐ対応してくれると思われます（若干のタイムラグは発生しますが
書き込んだ相手にはアカウント凍結のような措置も取らないといけないので
書き込みがあった事実も消えてしまうのはよろしくありません）。

削除できるということは安易な書き込みを助長することにもなります。

もみ消された時何がいけないのか知りたいです。その不適切な言動への指摘は，その人を傷つけた可能性はありませんか？アカウント凍結だなんて，してほしくないんです。それって，相手はもしかしたら困らせる気がなく書いてしまったのかもしれません。その責任追及は必要ですが凍結はやりすぎです。削除可能でないと。僕としては他人がやったことでも穏便にもみ消したいくらい。（第一目標は個人情報の流出を防ぐためだから。）もちろん，暴言を吐き，いくら指摘してもやめない人ならもうわかっているので別ですよ。でもそういう場合も裁判すればいいし（僕なら報告はしたくない）。裁判と言う言葉が悪いようですね。「他人の仲介がある話し合い」にしておきます。（でもそれって同じですよ。）あなたがこれ以上堂々巡りをしたくないとおっしゃるなら，これについてはもうコメントしませんが，僕は，こういう話し合いがディスカッションフォーラムの意義だと思っています。

fine316

mochimochiking さんからの削除対象案についての検討
赤文字がinokingのコメントです。
青文字がapple502jさんのコメントです。
橙文字がmochimochikingさんのコメントです。
緑文字がkaaramochiさんのコメントです。
オリーブ文字がfine316さんのコメントです。
灰文字がMMGISSさんのコメントです。
紫文字がkan217さんのコメントです。
草色文字がikntmkwさんのコメントです。

見た目カテゴリ

このスプライトの色を [#000000] にする ::looks//透明色とのグラデーションの場合、どこまでが「このスプライトなのか」

→提案内容の分かる方、説明お願いします。
スプライトのすべての部分を指定色にすると推測できます。
なるほど。しかし汎用性があるかに疑問が残りますね。
+複数の色があった場合、どう処理されるかが不明です。
スプライトの透明以外のすべてを指定色で塗りつぶすのだと思います。どういうときに必要ですか？
必要性はないと思います
色の効果・明るさの効果で充分と思います。

調べるカテゴリ

<触れた色 ::sensing>//複数あるときに疑問

→提案内容の分かる方、説明お願いします。
可能性として、スペース区切りがあります。ただし、技術上できるかは不明です。

(スプライトの [縦の大きさ v] :: sensing)//定数なので取得する用途不明

→定数とは限りません。必要性については要検討

(スプライトの [横の大きさ v] :: sensing)//定数なので取得する用途不明

→定数とは限りません。必要性については要検討
上の二つは縦に()伸びるなどのブロックと合わせて検討する方がいいと思います。

(スプライトの [面積 v] :: sensing)//定数なので取得する用途不明

→定数とは限りません。必要性については要検討

(マイクの音の高さ ::sound)//音は複数の周波数で構成されているため何を返すのか疑問

→提案内容の分かる方、説明お願いします。
旧ブロック (note::sensing) のことでしょうか。

(押されたキー :: sensing)//複数あるときに疑問

→提案内容の分かる方、説明お願いします。
スペース区切りはどうでしょう。
スペース区切りを行うとき、「スペース」キーや「上向き矢印」キーなどを記述する言語(英語に揃える？)に疑問が残ります。
a b c enterといった感じでしょうか。押されている瞬間だけ反応するんですか？
押されている間ずっと反応するようにしたほうがわかりやすいと思います。
Windowsキーなど特定のプラットホームのみに存在するキーのときも疑問が残ります。
表記をany_special_keyなどとすることで無理やり押さえ込むことはできます。
Scratchは配列を返す言語仕様出はないため実装は難しい。
最後に押されたキーにすればどうですか？　僕はこれがなくて困ってます。
https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2812001/ に書いたとおり、3.0では作品側で用意できるようになるので不要と思います。

<[コスチューム1 v]の[Sprite1 v]に触れた :: sensing>//簡単なスクリプトで実装可能

→簡単かどうかは分かりませんが汎用性がないと思います。

(マウスホイールの移動量 :: sensing)//xかyか何を返すのか疑問

→ユーザーがマウスホイールを 1 目盛り回すごとにスクロールする行数のことです。
ホイールがついていないマウスもあります。
ホイールがないならその機能が使えないだけなので支障はないと思います。
ホイール機能が導入されたときに、たとえばホイール機能がプロジェクトでの重要な役割を担っているプロジェクトが作成されることが考えられます。
そうすると、ホイールが使えない一部のユーザーはそのプロジェクトができなくなってしまうと思います。
現状でも例えばマイクやカメラで同様の状況が発生しています。
マイク、カメラは認証が必要な特殊な機能です。しかし、マウスホイールは、すべての人がこの機能を使えると勘違いして組み込まれてしまう可能性があるかと思います。

変数カテゴリ

変数 [ v] のx座標を () に、y座標を () にする ::variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
他にはどのような意見がありますか。
https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2803828/ が関係するかなと。
変数やリストの表示については https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/ についても考慮お願いします。

(変数 [ v] のx座標 ::variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

(変数 [ v] のy座標 ::variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の三つは、実装されてもいいと思います。
上の三つの実装に賛成。
　なぜですか。

変数 [ v] の表示形式を [スライダー v] にする :: variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

(変数 [ v] の表示形式::variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の二つは、どんなときに使うんでしょうか。

[変数 v] のスライダーの最小値を (0) にする :: variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

[変数 v] のスライダーの最大値を (0) にする :: variables//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

([変数 v] のスライダーの最小値 :: variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

([変数 v] のスライダーの最大値 :: variables)//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の四つは、そこまで汎用性があるでしょうか。
値を変更する場合が思い付かない。故に要らないと思う。

<変数 [ v] がクリックされた :: variables>//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

リスト [ v] のx座標を () に、y座標を () にする ::list//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。

リスト [ v] の縦幅を () に、横幅を () にする ::list//https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2800013/

→削除賛成。しかし議論中。
上の二つは、実装されてもいいと思います。
リストの大きさなどが勝手に変わるから実装したいということだと思うので、それが変わらないようにすればいいと思います
紫に同意
変数・リストの見た目系ブロックは「表示する」「隠す」で充分と思います。座標や、クリックされたかどうかを判定する意図が不明ですし、そのために変数やリストがあるのではありません。

その他編集/実行
・コスチュームエディターの大きさを変数のスライダーみたいな感じで細かく変更できるようにしてほしい//用途不明
→提案内容の分かる方、説明お願いします。
サイズを大きくするときに端のドラッグ以外にも、スライダーでできるようにするor数値入力。SVGを読み込んで大きすぎ、エディターをはみ出して端もつかめない場合(経験済み)などに役立つ。

話す
・トピックの連続建て不可//徳子ぉがあるため不要
→提案内容の分かる方、説明お願いします。
スパム防止として、追加に賛成です。600秒などはどうでしょう。(New Scratcherの120秒ルールは過去は600秒)
60秒ではなぜ短いとおもうのですか。
10分は長すぎますよ。
10分でもいいと思います。そもそもトピックは頻繁に作るものではないと思うので1日でも構わないと思います。
600秒に賛成です。
追加賛成です。
1日に賛成
皆さん作成に賛成のようですので

・自分がオーナーのスタジオに投稿されたコメントの削除//コメントは皆のものだから、コメントはけせなくしたほうがよいとおもう。
→削除賛成。異論なければ却下に移動したいと思います。
削除賛成。他人のプロフィールのコメント削除はST却下。
それだとスタジオに関係ないコメントが来た時など、報告以外に消去方法がありません。
報告すればいいと思います。

その他

・リミックス時に過去の「メモと作品への貢献」が変更できないようにする//追加はできるようにすべき
→削除賛成。異論なければ却下に移動したいと思います。
これは追加に賛成です。基本、リミックスには元作品でクレジットのある素材が使われているので、クレジットが消えたら故意ではないのに削除対象となってしまいます。過去の記述の前に追加という形なら大丈夫と思います。
クレジットは残すべきだと思います。（その素材を消さない限り）しかし、合作などではメモがどんどん増えてしまいます。
　各自が１,2行ほどで記述すればそんなに長くならないのでは
「消さないように」ではなく、リミックス元のクレジットが継承できるようにしたほうがいいと思います。
追加に賛成

・私の作品で、昇順/降順の切り替え可能//人気のない作品、古い作品、リミックスされていない等の順で見る意図が不明
→提案内容の分かる方、説明お願いします。
作品の検索機能があればそれでいいのですが、要は「作品を手早く見つける手段」なのではないのでしょうか。
それでは、この提案却下し、私の作品の検索機能を追加でいいですか。

inoking

itnkmkw wrote:
もみ消された時何がいけないのか知りたいです。その不適切な言動への指摘は，その人を傷つけた可能性はありませんか？アカウント凍結だなんて，してほしくないんです。それって，相手はもしかしたら困らせる気がなく書いてしまったのかもしれません。その責任追及は必要ですが凍結はやりすぎです。削除可能でないと。僕としては他人がやったことでも穏便にもみ消したいくらい。（第一目標は個人情報の流出を防ぐためだから。）もちろん，暴言を吐き，いくら指摘してもやめない人ならもうわかっているので別ですよ。でもそういう場合も裁判すればいいし（僕なら報告はしたくない）。裁判と言う言葉が悪いようですね。「他人の仲介がある話し合い」にしておきます。（でもそれって同じですよ。）あなたがこれ以上堂々巡りをしたくないとおっしゃるなら，これについてはもうコメントしませんが，僕は，こういう話し合いがディスカッションフォーラムの意義だと思っています。

この議論を続けることは私はかまいませんが、トピ違いかもしれません。

まず、
もみ消された場合、
履歴が残らないので同様のことを繰り返しているのかどうかも分かりません。
また、「誰々が悪口を言った」等の申告が某所でされていることもありますが
既に削除されているため事実関係が把握できない、といったこともあるようです。
なお、
もみ消された指摘において私の指摘が相手を傷つけたのではないとは思いますが（もしそうなら逆指摘があるでしょうから）、
消されてしまっては確認のしようもありません。

次に、
報告に対する措置は Scratch チームが判断することです。
アカウント凍結のような措置はよほどの場合でしょう。
過去の履歴はそのための材料にもなります。

最後に、
話し合いも大事ですが
自分では想像もつかないような倫理観や価値観をもった相手が存在するのも事実です。

ルールにのっとったうえで
場合によっては毅然とした態度で臨むことも肝要かと思います。

mochimochiking

#2260(113p?)から書き漏れ分(#3 24 28 35 77 123 199 1340 1342 2269 他にもあるかも…)のうち改めて考えて有用だと思ったものを挙げさせてもらいます。

<表示された::looks>
[]と喋る::sound//発音記号が引数か?それとも言語指定するのか?
塗りつぶす::pen
消しゴムを下ろす::pen
消しゴムを上げる::pen
x座標(),y座標()の点に[MS明朝 v]のフォントで()ポイントの大きさで[]と表示する::pen
<変数::variables>
<>のとき::events hat
中が見られたとき::events hat//オープンソースでなくなる恐れ
(カウンター::control)
抜け出す::control cap
始めに戻る::control cap
実行し、<>まで繰り返す{}::control
<このスプライトがクリックされた::sensing>
<[上の v]端にふれた::sensing>
<Scratcher::sensing>//クラウド変数が使えるものとしての
<ターボモード::sensing>
<中を見ている::sensing>
<大画面::sensing>
(世界標準時との時差::sensing)
(現在の[ミリ秒 v]::sensing)
(使用言語::sensing)
([ v]をunicodeで[デコード v]::sensing)
([]を計算::operators)
(<>なら[]でなければ[]::operators)

音声認識//難しい&発音記号で返すのか?
exe出力//sb2->swf->exeの流れで現在も可
ボカロ
細筆
プログラム内での変数宣言
≠、≦、≧
3DSとの互換性
cookie//干渉しないようにたとえばproject属性だけ変更可能にするとか。
スタジオからぬけられるボタン

mochimochiking

配列リテラルがほしい。

inoking

赤文字がinokingのコメントです。コメントしていない項目は賛成も反対もしない項目です。

<表示された::looks>

<スプライトが表示されている> のことですか？それなら既にリストにあります。

[]と喋る::sound//発音記号が引数か?それとも言語指定するのか?

合成音声ですか？Scratch の範ちゅうを超えていると思います。

塗りつぶす::pen

追加賛成です。

消しゴムを下ろす::pen

消しゴムを上げる::pen

x座標(),y座標()の点に[MS明朝 v]のフォントで()ポイントの大きさで[]と表示する::pen

Scratch 3.0 でペンテキストが実装予定のためこれは不要という方向ではなかったのですか？

<変数::variables>

真偽値型の変数のことですか？

<>のとき::events hat

任意のイベントについては却下済みです https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/post/2761553/

中が見られたとき::events hat//オープンソースでなくなる恐れ

懸念があるものを追加しなくてもよいでしょう。そもそもプレイモードで動くものを作るべきです。

(カウンター::control)

使い方は？

抜け出す::control cap

break のことですか？

始めに戻る::control cap

continue のことですか？

実行し、<>まで繰り返す{}::control

do while のことですね。以上3点、何でも他の言語を真似すればよいものではないと思います。

<このスプライトがクリックされた::sensing>

現状のイベントで十分と思います。

<[上の v]端にふれた::sensing>

座標で十分と思います。初心者向けにはもし端についたら、跳ね返るもあるので。

<Scratcher::sensing>//クラウド変数が使えるものとしての

New Scratcher はスパム防止のためだけに設けられているのでその他の用途で区別されるべきではありません。

<ターボモード::sensing>

<中を見ている::sensing>

中が見られたときと同様。

<大画面::sensing>

大画面かどうかが分かったとして何をするのでしょうか？必要性が見えません。

(世界標準時との時差::sensing)

(現在の[ミリ秒 v]::sensing)

2000年からの日数で求められます。

(使用言語::sensing)

([ v]をunicodeで[デコード v]::sensing)

([]を計算::operators)

1 + 1 = 等の計算ですか？それならブロックで実現すべきです。

(<>なら[]でなければ[]::operators)

既にリストにあります。

・音声認識//難しい&発音記号で返すのか?
Scratch の範ちゅうを超えていると思います。それを実現するための音の高さを取得するブロックはあってもよいと思います。
・exe出力//sb2->swf->exeの流れで現在も可
現状でも実現方法があります。特殊用途なので標準では不要と思います。
・ボカロ
Scratch の範ちゅうを超えていると思います。
・細筆
内容説明お願いします。
・プログラム内での変数宣言
専門的すぎて初心者には意味不明と思います。
・≠、≦、≧
・3DSとの互換性
内容説明お願いします。
・cookie//干渉しないようにたとえばproject属性だけ変更可能にするとか。
クッキーで何をしたいのか説明お願いします。
・スタジオからぬけられるボタン

inoking

mochimochiking wrote:
配列リテラルがほしい。

初期化処理でリストに追加するのとそう変わらないと思います。

Discuss Scratch