Scratch 3.0 への提案

ITM126

#8014 コメントをよく見てください。　#8015例えているものがおかしくありませんか？「一般的組織では、一人が直接管理可能な人数は多くて数十人です。」と「一つの美術館で学芸員（居ても数十人？）の人事権を持つ管理者（マネージャー）が40人も必要なはずがありません。
どれだけ大きな美術館なのでしょう？」これはあなたの主観的事実です。

p_nuts

ITM126 wrote:
#8014 コメントをよく見てください。　#8015例えているものがおかしくありませんか？「一般的組織では、一人が直接管理可能な人数は多くて数十人です。」と「一つの美術館で学芸員（居ても数十人？）の人事権を持つ管理者（マネージャー）が40人も必要なはずがありません。
どれだけ大きな美術館なのでしょう？」これはあなたの主観的事実です。

確かに主観的事実ですがあくまで意見です(関係者以外が回答して申し訳ない)
そもそも「私は賛成です(反対です)」などの投稿はたくさんありますがそれは主観的事実です
そして私はinokingさんの考え方に賛成です(主観的事実)

Es-2

#8016

ITM126 wrote:
#8014 コメントをよく見てください。　

なぜ、活動のない人をキュレーターにしたいのか、言葉で説明してほしいです。
活動がない人をスタジオに入れる意味はあるのでしょうか？

ITM126 wrote:
例えているものがおかしくありませんか？

スタジオを美術館に例えることは、スタジオが昔ギャラリーと呼ばれていたことからもわかるように、自然なことです。

inoking

ITM126 wrote:
#8015例えているものがおかしくありませんか？
～略～
これはあなたの主観的事実です。

主観ですがそれは #8013 なども同様です。
その言い回しを多用されているようですが、反論にはなりません。

この例えに合理性があるかどうかは多くの読者には明白でしょう。

k_mario

スタジオアップデートの前に作られ、マネージャーが40人を超えているスタジオも多いと思います。
そのような時に降格するような機能があってもいいと思います。

00giri

#8020
これはあくまでも推測ですが、マネージャーの入れ替えの目的は拡散ではないでしょうか? そうであれば、その更新はスタジオ機能の向上に貢献しないと思います。その機能を実現するには「本来のスタジオの使い方」における必要性を説明する必要があると思います。
あえてデメリットを挙げるとすれば、
・更新のScratchに対する貢献度と労力が見合わない
・意図しないスタジオの使い方を促進することになる
です。

ITM126

#8018引退している方でも、思い入れ深い方だったら残したくなるものでは（）
#8019そうですか。

ITM126

#8022すみません、「マネージャーの入れ替えの目的は拡散」だったとしても、なぜそれが「スタジオ機能の向上に貢献しない」につながるのか理解できません。

00giri

#8024
拡散は本来のスタジオの目的ではないからです。この前のスタジオの更新もスタジオが本来の目的で使われていなかったために行われました。スタジオはあくまでもプロジェクトを集めたりする場であり、拡散の道具ではありません。

ITM126

#8025なるほど、そうゆうことでしたか。

k_mario

思ったんですが、頻繁に入れ替わると信用できない人をマネージャーにしてしまって荒らされそう。

Ke0

スタジオアップデード前にも降格機能がなかったわけですから、マネージャーには信頼できる人を任命していたのでしょう。人数制限があろうとなかろうと、対して状況は変わっていません。ただ、現在の方がより'ふるい'にかけねばならなくなっただけです。

まず、降格機能によって引き起こされる問題として、管理のできていないスタジオが増えることが危惧されます。いつでも資格を奪える状況ならば、一度の任命に対して責任は覚えないでしょう。「失敗したら辞めさせればいい」という考え、これが問題です。しっかりと選んだ時よりも圧倒的に「失敗する」人を任命するリスクも高くなります。(しっかり考えてもなくなるとは限らないのが難しいところではありますが)

「デメリットがないならば実装しろ」という意見があるようですが、ここまでのリスクを負ってまで実装するメリットがわかりません。

Last edited by Ke0 (Dec. 27, 2021 02:56:55)

k_mario

ただ、削除ではなく降格となると甘い気持ちでマネージャに任命されやすくなりそうです。

Ke0 wrote:
スタジオアップデード前にも降格機能がなかったわけですから、マネージャーには信頼できる人を任命していたのでしょう。

そんなことは無いと思います。拡散目的だったスタジオは招待してもらうためにどんどんマネージャーを増やしていました。

Last edited by k_mario (Dec. 27, 2021 03:15:04)

Ke0

#8029
追放すれば良いのになぜ降格機能が欲しいのでしょう。てっきり追放は選択肢から消えていると思い込んでいました。

「しっかり読んでますか？」と言われそうなので追記しておきますが、活動してない人を残したいなら、わざわざ降格する必要はありませんよね。そもそも活動していないのですから、マネージャー権限が暴走するリスクも少ないでしょう。
#8030
もしそうなら、実装によりその動きは加速するでしょう。それでいいのでしょうか？

Last edited by Ke0 (Dec. 27, 2021 03:49:44)

inoking

「本来の使い方」をする限り、マネージャーをひんぱんに入れ替える必要はないはずです。
逆に、「本来の使い方」をしていてもそれが必要な例があるようなら挙げてみてください。

punipuni5854

削除

Last edited by punipuni5854 (Dec. 27, 2021 08:44:56)

3659662244

確認できるものはしました。被っていたら本当にごめんなさい。
◆スタジオ関連
・キュレター招待の時にフォロワー全員を招待というボタンが欲しい。
新しくなり、フォロワー全員招待どころか一覧も無くなってしまいました。また、「招待が大変」と言うこともあるので，あった方がいいなと思います。
・マネージャーなぜ制限が？
理由は知らない(自分が)のですが、マネージャー無制限だったのに新しくなってマネージャーが40人の制限になりました。重くならない点ではいいのかもしれませんが、僕的にはちょっと残念です。
◆「プロジェクトを作る」画面でのブロック
・前のコスチュームにする
前まで自分で作っていましたが、やっぱり大変です。これは単純にみんな欲しいと思っているかもしれません。
◆拡張機能・アドバイス
・なめらかになるブロックの組み合わせを教えてほしい
単純ですが、僕なめらかにする方法あまり知らないと言うか、そもそも演算苦手ですし、小4(2021年12月時点)なのであまり理解しておりません。僕はそのアドバイスが欲しいです。
・QRコードの読み取り
実際にscratchで議論されているらしいですし、ここでもあるので、僕的には増えて欲しいです。
これが今の所の僕の意見です。ほんとうに被っていたらすいません。

Creepers4321

変数名[]という名前の変数を作成する

変数[変数 v]のx座標を () 、y座標を () にする

などのブロックが欲しいです。
あと、コスチュームのテキストのフォントを.ttfなどで拡張する機能もHTML5では夢ではないと思います。

ITM126

#8034 フォロワー一斉招待は確かにサーバーに負荷がかかるのでやめておいたほうが良さそうです。マネージャー40人も、もしサーバーに負荷がかかるという理由なら仕方のないことかもしれません。
#8031まあ再招待は手間がかかるという面もあったので…しっかり読んd…((ry

ITM126

#8035　「変数x座標を…y座標を…にする」とはどういうことですか？

Discuss Scratch