[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.1 [url=https://scratch.mit.edu/discuss/post/634620/]"Broadcast received" boolean block[/url][/b]
This in theory would allow a project to detect when a broadcast is sent, but there is ambiguity on how this would work.  Would it return true if the broadcast was run at any point after the green flag was clicked, or only on the instant the broadcast was run, or something else?  Workarounds for this block exist depending on your intended use; for more information, see [url=https://scratch.mit.edu/discuss/post/9091338/]this post[/url].

This extends to a "message recieved number times" block, which would not completely resolve the ambiguity. See [url=https://scratch.mit.edu/discuss/topic/882003/?page=1#post-9319228]this post[/url]. 

However, the blocks "repeat until broadcast received" and "wait until broadcast received" are NOT rejected.  You can discuss them on [url=https://scratch.mit.edu/discuss/topic/324844/]this topic[/url].

[scratchblocks]
<[message v] received? :: events>
[/scratchblocks]
[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.2 [url=https://scratch.mit.edu/discuss/post/2070854/]"When stop sign clicked" hat block[/url][/b]
This block would allow users to click the stop sign to run a script.  However, the stop sign is designed to stop all the scripts in the project.  With this block in place, more scripts will start when you want the project to stop, thus defeating the purpose of the stop sign.  Regardless, there are workarounds for this block using the timer or ghost effect blocks; these can be found in [url=https://scratch.mit.edu/discuss/post/3547555/]this post[/url] or [url=https://scratch.mit.edu/discuss/post/8005188/]this post[/url].

This extends to any block that causes a script to be run as a result of the stop sign being clicked, not just the specific hat block below.  For more information, see [url=https://scratch.mit.edu/discuss/post/6871820/]this post[/url].

[scratchblocks]
when @stopSign clicked :: events :: hat
[/scratchblocks][/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.3 [url=https://scratch.mit.edu/discuss/post/3603084/]"Pointing towards sprite" boolean block[/url][/b]
This in theory would allow a sprite to detect if it is pointing towards another sprite, but there is ambiguity on how this would work.  Would it return true if the sprite is pointing in any general direction towards another sprite, or strictly at the center of that sprite?  This depends on your intended function of the block, at which point you may consider implementing your own workaround.

However, a block that removes this ambiguity by describing where specifically the sprite is pointing is NOT rejected.  You can discuss that on [url=https://scratch.mit.edu/discuss/topic/753149/]this topic[/url].

[scratchblocks]
<pointing towards (sprite v)? :: sensing>
[/scratchblocks][/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.4 [url=https://scratch.mit.edu/discuss/post/3669210/]Social action reporter blocks[/url][/b]
This block could be used, for example, to obtain the current number of loves of the project.  However, project creators can easily use these blocks to prevent Scratchers from playing unless the project is given enough loves.  If a user presses the love button on a project, it should be because they enjoyed the project, not because they are trying to reach some sort of goal.  Social actions are not intended to be a way to interact with a Scratch project.

This extends to all social actions, including views, loves, favorites, remixes, comments, and followers.  It also extends to boolean blocks which involve social actions.

[scratchblocks]
(number of [loves v] :: sensing)
[/scratchblocks][/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.5 [url=https://scratch.mit.edu/discuss/post/3528653/]Cloud lists[/url][/b]
This block would allow you to create lists available for everyone to see, similar to cloud variables.  However, cloud lists would require similar restrictions as cloud variables, and the moderation and storage issues present with cloud variables would only grow with the addition of cloud lists.  You can still use cloud variables to create a list which contains entries everyone can see.

[scratchblocks]
(☁ list :: list)
[/scratchblocks][/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.6 [url=https://scratch.mit.edu/discuss/post/3684338/]2D lists[/url][/b]
2D lists, also known as 2D arrays, nested lists, or matrices, are a type of data structure that allows you to put an entire list as an element of another list; that is, it allows you to put lists inside of lists.  These sorts of data structures are used widely in other programming languages and functions similarly to a table.

This block, and others, would allow you to create 2D lists to store information.  However, this is too complicated for what is supposed to be an introductory programming language.  There are workarounds possible by using an ordinary list and an indexing function.  For those who are interested, it may be worth checking out [url=https://snap.berkeley.edu/]Snap![/url].  It is a block-based programming language designed for experienced programmers and has more advanced data structures than Scratch does.

[scratchblocks]
add [] to sublist () of [list v] :: list
[/scratchblocks][/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.7 [url=https://scratch.mit.edu/discuss/post/272115/]3D Scratch[/url][/b]
A 3D Scratch interface, involving a z-axis in the project stage, could make it easier to create 3D projects.  However, Scratch is a language that is designed to be as easy as possible for beginners to learn.  The purpose of Scratch is to teach beginners basic programming concepts, which is best accomplished with a 2D interface.  Adding a 3D interface could make Scratch more difficult to learn and teach.  This includes having a separate website for 3D Scratch.  This also includes the possibility for virtual-reality "Scratch VR" features, where a lot of the same difficulties come up; for more information, see [url=https://scratch.mit.edu/discuss/post/4149704/]this post[/url].

For those who are interested, it may be worth checking out Snap's [url=https://snap.berkeley.edu/beetle]3D Beetle extension[/url] or [url=https://creaticode.com/]CreatiCode[/url].  They are block-based programming languages similar to the Scratch editor, but with 3D features.  There is another similar program to Scratch that contains block programming with 3D features, called [url=https://education.mit.edu/project/starlogo-tng/]Starlogo TNG[/url].
[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.8 [url=https://scratch.mit.edu/discuss/post/4186455/]Blocks that control the mouse pointer[/url][/b]
This block, and others, could be used to hide the mouse pointer, change the way that it looks, freeze it, or prevent it from leaving the project screen.  These blocks, however, do not significantly change the types of projects that can be created with Scratch; for more information, see [url=https://scratch.mit.edu/discuss/post/3889314/]this post[/url].  In addition, they may confuse users by having them wonder where the mouse pointer went.

However, changing the look of the mouse pointer to one of the default mouse pointers is NOT rejected.  You can discuss that on [url=https://scratch.mit.edu/discuss/topic/512009/]this topic[/url].

[scratchblocks]
hide mouse pointer :: looks
[/scratchblocks]
[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.9 [url=https://scratch.mit.edu/discuss/post/4034761/]"Forever if" C block[/url][/b]
This block was in the Scratch 1.4 editor, and worked the same as putting an "if" block inside a "forever" loop.  It was removed in Scratch 2.0 because many beginners found it to be confusing.  The aforementioned workaround is evidently simple and more intuitive.  An "if, then forever" block (putting a "forever" loop inside an "if" block) is also rejected [url=https://scratch.mit.edu/discuss/post/9295879/]for the same reason[/url].

[scratchblocks]
forever if <> {

} @loopArrow :: control cap
[/scratchblocks]
[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.10 [url=https://scratch.mit.edu/discuss/post/4903222/]Comment block[/url][/b]
In principle, the comment block has no effect, but it would be used to write comments in-line with other blocks in a script.  This would be useful for those who want to explain how their code works, for example.  This block was found to be too confusing for beginners, who expected all blocks to do something (the comment block does not do anything).  As a result, the Scratch Team created the existing comment system, where comments can be attached to a block in a way that is clearly separate from the rest of the blocks in the script.  There is an easy workaround: create a custom block with a text input, and don't put anything in its definition.

[scratchblocks]
comment [] :: #aeaeae
[/scratchblocks][/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.11 [url=https://scratch.mit.edu/discuss/post/4336855/]"Jump to code" block[/url][/b]
This block could be used to allow a program to jump to another point in the code, even within the same script, similar to the "goto" statement used in other programming languages.  This could cause confusion, however; by implementing less [url=https://en.wikipedia.org/wiki/Structured_programming]structured programming[/url], this could cause code to be confusing to read and write.

[scratchblocks]
jump to [block v] :: control
[/scratchblocks][/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.12 [url=https://scratch.mit.edu/discuss/post/1333242/]Money blocks[/url][/b]
This suggestion refers to Scratch blocks in the editor which can be used to exchange digital currency.  The problem with such money blocks is that many users on the website are young and do not quite know how money works (and most do not even have a credit card account).  Users could make projects which require others to pay a large amount of money to access the project.  Overall, it adds further complexity to the website and would limit users' access, without any clear benefit towards the educational value.

A very good detailed analysis for why users should not be able to make money on Scratch can be found on [url=https://scratch.mit.edu/discuss/post/3509160/]this post[/url].

[scratchblocks]
ask for [$ v] () and wait :: extension
[/scratchblocks]
[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]1.13 [url=https://scratch.mit.edu/discuss/post/8131219/]Bad word detector block[/url][/b]
Even if a block such as the one below doesn't actually cause users to see bad words in the project, it would still not be useful.  In a project that doesn't use cloud variables, the only user who can enter text is the user playing the project, so they are the only one who is seeing bad words.  In a project that uses cloud variables, this block would only be useful if the project was a cloud chat project, which is already not allowed; for more information, see #3.1 on this list.

[scratchblocks]
<() contains bad word? :: operators> 
[/scratchblocks][/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]2.1 [url=https://scratch.mit.edu/discuss/post/1958869/]Live or private collaboration[/url][/b]
Any forum of collaboration that involves live editing (similar to Google Docs) or the project only being viewable to users added to work on it would be difficult to moderate not only due to technological limitations but also because it could lead to private messaging; for more information, see #8.1 on this list and [url=https://scratch.mit.edu/discuss/post/9245581/]this post[/url].  If you would like to work on a project with another Scratcher, you can remix each others' projects.

Other forms of collaboration, such as a [url=https://scratch.mit.edu/discuss/topic/322107/]turn-based collaboration system[/url] for shared projects, are NOT rejected.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]2.2 [url=https://scratch.mit.edu/discuss/post/3471767/]Text-based syntax in Scratch[/url][/b]
Some users wish to code Scratch not with the blocks, but with typing code instead (similar to how more advanced programming languages work).  Others are interested in an option to view, convert, or download Scratch code to other programming languages.  However, the Scratch Team has discussed this possibility multiple times and has decided every time that it would not be beneficial for beginners or teachers.

This extends to coding, viewing, converting, or downloading Scratch in [i]any[/i] text-based language, including BBCode, Javascript, some form of pseudocode, or some other programming language.  If you wish to code using another language, then you can learn it on your own, but it would have to be done outside of Scratch.  For those who are interested, it may be worth checking out [url=https://tosh.blob.codes/]Tosh[/url].  It is a text-based programming language that serves as a text editor for Scratch projects.  Another option is [url=https://arcade.makecode.com/]MakeCode Arcade[/url], a programming language that can convert between block-based and text-based programming within the editor.  Advanced programmers can use [url=https://leopardjs.com/]Leopard[/url] to make Scratch projects directly using JavaScript.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]2.3 [url=https://scratch.mit.edu/discuss/post/3303002/]Official Scratch to EXE converter[/url][/b]
On Scratch, an important goal is to have anyone be able to look at the code for any project.  This philosophy is not only important for learning code and remixing, but is also important for moderation purposes; for more information, see #3.2 and #4.1 on this list.  Converting to EXE (or any other black box executables) will prevent users from looking at the code, and hence goes against this philosophy.  Third-party converters do exist, and you are allowed to use those, but the Scratch Team will not make an official converter.
[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]2.4 [url=https://scratch.mit.edu/discuss/post/375856/]Increase the 300 clone limit[/url][/b]
The clone limit is set in place to prevent projects from becoming unplayable.  Otherwise, users could create a large number of clones very quickly and crash someone's browser page.  Plus, the Scratch Team wants to make sure that all projects run smoothly for as many people as possible.  Increasing the limit to even 500 clones might make the project run slowly on some users' devices.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]2.5 [url=https://scratch.mit.edu/discuss/post/3983340/]Scratch editor for video game consoles[/url][/b]
The Scratch Team does not have the resources to put a Scratch editor onto a video game console.  This includes making a Scratch editor for any gaming console.

However, the ability to connect gaming controllers to a computer or tablet to use for Scratch is NOT rejected.  You can discuss it on [url=https://scratch.mit.edu/discuss/topic/280263/]this topic[/url].[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]2.6 [url=https://scratch.mit.edu/discuss/post/7749389/]Default list in a new Scratch project[/url][/b]
When you make a new Scratch project, a variable called "my variable" is automatically created.  Some Scratchers have suggested that a list should automatically be created, for example called "my list".  However, lists tend to be more complicated for newer users, and hence not used as much.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]2.7 [url=https://scratch.mit.edu/discuss/post/4094599/]Letters in cloud variables[/url][/b]
Some users would like an easy way to set cloud variables to values which include letters.  However, allowing letters in cloud variables would cause a lot of moderation issues.  For example, it would be too easy to make inappropriate cloud chat projects; for more information, see #3.1 on this list.

It is possible to simulate letters in cloud variables by encoding and decoding between numbers in cloud variables and letters in normal variables.
[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]3.1 [url=https://scratch.mit.edu/discuss/post/3622655/]Allow chat projects with cloud variables[/url][/b]
Although it is possible to make a chat project using cloud variables, it is not allowed to make such a project.  This is because there is a high potential for bullying and inappropriate messages, and the Scratch Team does not have the resources to moderate these chat rooms.  This includes adding a block that filters out inappropriate language, as such a block would only be useful for cloud chat projects, which are not allowed.  For more information, see #1.13 on this list.

Chat projects on Scratch which contained a whitelist (that is, the user could only chat using certain words) used to be allowed on Scratch.  Over time, however, the moderation issues got too high, and some users attempted to use such projects to get around the [url=https://scratch.mit.edu/community_guidelines/]Community Guidelines[/url].  As a result, the Scratch Team has decided that these kinds of projects are not allowed on the Scratch website, even if they contain a whitelist of words.  However, [i]whitelisted phrases[/i] are okay, provided that users cannot freely write their own sentences using the cloud chat project.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]3.2 [url=https://scratch.mit.edu/discuss/post/1222338/]Disable remixing[/url] or [url=https://scratch.mit.edu/discuss/post/1034040/]censor minor remixes[/url][/b]
One of the most important ideas of Scratch is the [i]share[/i] aspect.  Scratch is a website not only for displaying your work, but also for [i]sharing[/i] it with others, and by posting your project on the Scratch website you agree to allow others to remix your work.  This includes allowing others to use the backpack to use your creations in their own projects.  You are not allowed to ask others not to remix your projects; you may get alerted for this, because it discourages remixing.  This extends to the ability to require permission to remix a project, as you have already given permission to others to use your creations by sharing a project on Scratch; for more information, see [url=https://scratch.mit.edu/discuss/post/5302901/]this post[/url].

A remix of a project is allowed on Scratch, even if the remix only contains minor changes (this includes recolors).  However, when you remix a project, you should put in the Notes and Credits what you changed.  If you see a project that contains no noticeable changes, please use the Report button on it so the Scratch Team can take a look at it.  This extends to "extremely minor remixes," such as a remix of a game that gives you 2 points per second instead of 1.  As long as the user explains what they changed about the project and gives proper credit, this is okay.

However, a feature that prevents unchanged remixes from being shared is NOT rejected.  You can discuss it on [url=https://scratch.mit.edu/discuss/topic/39464/]this topic[/url].[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]3.3 [url=https://scratch.mit.edu/discuss/post/3187896/]Ban certain franchises[/url][/b]
Generally, the Scratch Team does not censor projects based on a certain franchise unless a large number of inappropriate projects were made with the franchise.  In general, it is usually possible to make appropriate projects based on a certain franchise.  Depending on the franchise itself and the types of projects made with it, the Scratch Team may choose to ban a franchise from Scratch if they need to, but that is at their discretion.  Of course, you should always use the Report button on inappropriate projects of any kind.

Note that, in general, it is also rejected to relax or remove restrictions on franchises that are already banned from Scratch; for more information, see [url=https://scratch.mit.edu/discuss/post/8986096/]this post[/url].[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]3.4 [url=https://scratch.mit.edu/discuss/post/4541993/]Censor projects with no coding[/url][/b]
Scratch encourages creativity of many kinds, not just programming.  As a result, many kinds of projects are allowed, such as algorithms, games, art, animations, music, and others.  Some of these projects do not necessarily need any scripts in them, and the Scratch Team will not require that they do.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]3.5 [url=https://scratch.mit.edu/discuss/post/4600199/]Remove the automatic project censoring system[/url][/b]
The automatic project censoring system, with the accompanying temporary account block, is extremely useful to ensure that the community stays safe.  Without this system, users who make inappropriate projects could keep making them without immediate consequence if a moderator is not online at the time.  That would just expose more people to inappropriate content.  While the Scratch Team is open to making improvements to this system, neither removing the automatic project censor nor removing the automatic temporary account block are the solutions.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]3.6 [url=https://scratch.mit.edu/discuss/post/6735765/]Ability to see Scratchers' unshared projects[/url][/b]
If a Scratch project is unshared, then it is not intended to be seen by anybody other than the project creator and the Scratch Team.  Allowing anybody to view unshared projects made by other Scratchers has the potential for abuse: Scratch projects could be leaked before they are ready to be shared, personal information could be exchanged, or someone could encounter inappropriate content that was intended to be removed from the Scratch website.  Keeping unshared projects hidden from other Scratchers helps prevent this abuse from happening.

While the Scratch Team is open to implementing features to make collaboration easier, allowing Scratchers to view others' unshared projects is not the solution.  For more information, see [url=https://scratch.mit.edu/discuss/post/6358631/]this post[/url].[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]3.7 [url=https://scratch.mit.edu/discuss/post/8649601/]Ban the use of AI images in Scratch projects[/url][/b]
It is not possible to tell with 100% certainty whether or not a particular image was made with AI, and this would only get more difficult as AI improves, so it would not be possible to enforce such a ban.  Moreover, AI has some benefits for enhancing creativity, including making it easier for Scratchers to make the costumes they want for their coding-focused projects, as well as inspiring Scratchers to make new stories based on the images they generate.  As long as proper credit is given to the tool used to generate the images, it is allowed to use AI images in Scratch projects.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]3.8 [url=https://scratch.mit.edu/discuss/post/9038420/]Short-form Scratch content[/url][/b]
Some Scratchers have suggested a way to browse Scratch projects by scrolling through short projects, similarly to YouTube and other social media websites, commonly called "Scratch Shorts."  The problem with this is that Scratch projects do not have a definitive runtime, so any system that attempts to determine the "length" of a Scratch project simply would not work like it does on YouTube and other video-based social media websites.  Note also that a system to browse random projects is rejected; for more information, see #8.8 on this list.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]4.1 [url=https://scratch.mit.edu/discuss/post/2038330/]Disable “See Inside”[/url] or [url=https://scratch.mit.edu/discuss/post/1071234/]private sharing[/url][/b]
Some users want an option to prevent Scratchers from looking inside their project and using their artwork, scripts, or sounds.  However, the core ideas of Scratch are "Imagine, Program, [i]Share[/i]."  By sharing a project on the Scratch website, you are allowing others to see the code and potentially remix or reuse the data inside, as long as they give credit.  This includes allowing others to use the backpack to use your creations in their own projects.  That being said, please use the Report button on any project that uses content from another Scratcher without giving credit to them.  If you do not want other users to see inside your project, then do not share your project on the Scratch website.

Private sharing so that only certain users can view the project is also not going to be implemented.  It is important for projects to be publicly shared for everyone to see so people can report them if they are inappropriate.  Only allowing certain users to view projects could increase the chances of inappropriate projects being shared on the website.  "Unlisted projects," similar to a YouTube feature, will also not be implemented for the same reason; for more information, see [url=https://scratch.mit.edu/discuss/post/3742815/]this post[/url].  It could also be used for private messaging; for more information, see #8.1 on this list.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]4.2 [url=https://scratch.mit.edu/discuss/post/1958521/]Dislike button[/url] or [url=https://scratch.mit.edu/discuss/post/2749716/]a project rating system[/url][/b]
Generally, a user's first several projects are something rather simple, such as test projects, remixes, or projects made using tutorials.  Because these projects are simple, other users may give the projects low ratings since they are not advanced.  With low enough ratings, the creator might be discouraged enough to stop using Scratch.  Moreover, constructive feedback is encouraged on Scratch.  A dislike button may show the creator how many people disliked their project, but it tells nothing about what the creator could do better.  If you do not like a project, you could choose not to love it, or you could leave a [i]respectful and constructive[/i] comment telling the user how to improve, in addition to saying what you like about the project.

With that, a dislike button is rejected for anything, including projects and comments.  This includes a dislike or "thumbs down" emoji for comments.  This also includes a decoy dislike button that does not raise any number in a "dislike counter"; for more information, see [url=https://scratch.mit.edu/discuss/post/4482219/]this post[/url].  However, a like button for comments is NOT rejected.  You can discuss it on [url=https://scratch.mit.edu/discuss/topic/43677/]this topic[/url].[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]4.3 [url=https://scratch.mit.edu/discuss/post/3268569/]Ability to see who viewed a project[/url][/b]
Views are different from loves and favorites in that users can view a project to see if they like it, and then love or favorite the project if they do like it.  With this suggestion, drama could be started if a user sees that another user viewed a project, but did not love or favorite it.  Moreover, projects generally get significantly more views than loves, favorites, or comments, so if users got notifications for this, it would lead to lots of unwanted messages.  Despite all this, there is a workaround for this which uses cloud variables, so one could potentially see who viewed a project.  This includes the ability to see who viewed a comment, profile, studio, or forum post.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]4.4 [url=https://scratch.mit.edu/discuss/post/6643659/]Ability to see who reported a project[/url][/b]
Reports are intended to be anonymous.  With this suggestion, drama could be started if a user sees that another user reported their project.  Some may even retaliate by reporting their projects in return (whether or not the projects deserved to be reported).  This includes the ability to see who reported a comment, profile, studio, or forum post.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]5.1 [url=https://scratch.mit.edu/discuss/post/2621530/]Remove studio activity messages[/url][/b]
Although they may seem annoying at times, they are rather helpful for some users.  Removing such messages entirely does not have a clear benefit for everyone.  If you find it annoying, one easy way to solve this is to not curate so many studios.  

However, the option to turn them off is NOT rejected.  You can discuss it on [url=https://scratch.mit.edu/discuss/topic/76356/]this topic[/url].

While these messages are currently not being sent, this is because of a bug; they have not been removed and will likely start being sent again at some point in the future.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]5.2 [url=https://scratch.mit.edu/discuss/post/3190328/]"Invite all followers" button for studios[/url][/b]
This feature existed in Scratch 2.0, but it was an extremely easy way for one user to create lots of notification spam for other users, most of which was unwanted.  By removing this feature, users are forced to work a little bit to invite a large number of users.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]5.3 [url=https://scratch.mit.edu/discuss/post/67636/]Remove "add everything" studios[/url][/b]
These studios are not against the Community Guidelines and are also rather harmless.  Certain friendships or collaborations could also be formed as a result of such studios.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]5.4 [url=https://scratch.mit.edu/discuss/post/5452511/]Increase the studio reply limit[/url] or [url=https://scratch.mit.edu/discuss/post/8361711/]remove the manager limit[/url][/b]
The reply limit of 25 replies in studios was implemented to keep studio conversations open to the community and to improve website performance.  Load times and server stresses tend to increase with larger reply limits, particularly due to the large number of Scratch users on the website.  The number 25 was chosen as a practical one to mitigate these issues while also encouraging open conversation in studios.

A manager limit was also implemented for similar reasons, in particular to prevent spam studios and allow users to be more intentional about who they promote to manager in a studio.  The Scratch Team does not plan to remove the manager limit.  For more information, see [url=https://scratch.mit.edu/discuss/topic/526539/]this post[/url].[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]5.5 [url=https://scratch.mit.edu/discuss/post/7184283/]Add multiple studio hosts[/url][/b]
The restriction of only allowing one studio host in a studio was implemented to help prevent studio raids and confusion over who edited the studio description.  By allowing multiple studio hosts in one studio, this introduces the same problems that the studio host role was intended to solve in the first place.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]5.6 [url=https://scratch.mit.edu/discuss/post/7967876/]Prevent your projects from being added to studios[/url][/b]
One of the key values of Scratch is the sharing aspect, and allowing others to add your projects to their studios is part of sharing.  You do have the option to remove your projects from studios if you choose to do so.  If the studio is being used in a disrespectful manner, you can use the Report button on it.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]6.1 [url=https://scratch.mit.edu/discuss/post/1939992/]Delete or edit your comments everywhere[/url][/b]
The inability to delete your comments everywhere is put in place so users do not post inappropriate comments or spam comments on other users' profiles, projects, or studios, just to delete them later on.  In contrast, you are not really likely to spam your own projects or profile.  The only benefits to this are to remove comments that you did not mean to post and to fix spelling errors.  The former could be solved by thinking carefully before posting any comments, and the latter could be worked around by typing slowly and/or stating your mistakes in a reply to the comment.  This also applies to forum posts; that is, a feature for Scratchers to delete their own forum posts will not be implemented.  This extends to the ability to delete your own comments even if nobody has seen them yet.

Editing comments could similarly lead to comment manipulation, such as a user commenting "I like this project," waiting until someone replies with "I agree," and then editing the original comment to say "I hate this project."  Allowing Scratch Team members to view the edit history of a comment does not make it easy to moderate, since then they have to look carefully at the context of each edit, which takes time.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]6.2 [url=https://scratch.mit.edu/discuss/post/3577897/]Remove character limits on text fields[/url][/b]
The character limit exists to prevent spam.  If any character limits were removed entirely, spammers could use this to paste large blocks of text, effectively slowing down the website.

Simply raising the limits, however, is NOT rejected.  You can discuss various character limits on the following topics: [url=https://scratch.mit.edu/discuss/topic/16406/]About Me and What I'm Working On[/url] or [url=https://scratch.mit.edu/discuss/topic/118446/]studio descriptions[/url].[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]6.3 [url=https://scratch.mit.edu/discuss/post/4221/]Notification for being mentioned in comments[/url][/b]
Some users would like to be notified whenever someone mentions their username in a comment on the website.  Although such an option was considered, it was not added due to the potential for spam.  For instance, someone could write @Scratcher multiple times to spam that user's notifications.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]6.4 [url=https://scratch.mit.edu/discuss/post/4264317/]Live commenting[/url] or [url=https://scratch.mit.edu/discuss/post/4445027/]streaming[/url][/b]
This refers to some system where you would not need to refresh the webpage to see new comments that are posted.  Some Scratchers think this would be convenient if you are engaged in a conversation with someone so that the conversation moves more quickly (somewhat like how texting works).  However, aside from the technological barriers this would bring, it would also put a greater emphasis on the social media aspect of Scratch, moving the focus away from the project-creating aspect.  Indeed, project creating is intended to be the primary focus of Scratch.

Streaming is similarly rejected, as is video chat, as they are forms of live commenting.  With streams, it is easy to share personal information without anyone being able to report it, which the Scratch Team does not want to risk.  Although one solution would be to have the Scratch Team moderate the streams, they do not have the resources to do that effectively.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]6.5 [url=https://scratch.mit.edu/discuss/post/8554785/]Detailed information on why a comment was filtered[/url][/b]
Some Scratchers have suggested that the filter should be more clear by showing which letters/words tripped the filter.  However, such a suggestion would make it easier to write comments or forums posts that are disrespectful or inappropriate but do not trip the filter.  When a Scratcher is prevented from posting a comment or forum post due to the filter, the Scratch Team wants to encourage them to think carefully about why, so that they can refrain from writing similar comments or posts in the future[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]6.6 [url=https://scratch.mit.edu/discuss/post/8821116/]General chat section of the Scratch website[/url][/b]
This suggestion refers to the ability to chat with other Scratchers in a place that is not "owned" by a Scratcher (that is, not a profile, project, or studio).  However, the Scratch Team does not have the resources to moderate a general chat section of the website.  This would also put an emphasis on the chatting aspect of the Scratch website, taking away the intended focus of Scratch as a coding website.  This extends to voice chat on the Scratch website; for more information, see [url=https://scratch.mit.edu/discuss/post/4583863/]this post[/url].[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]7.1 [url=https://scratch.mit.edu/discuss/post/663346/]Ban "follow for follow" (F4F)[/url][/b]
Although many Scratchers do not enjoy seeing follow for follow requests, asking someone to participate in follow for follow is relatively harmless.  If someone asks you to do follow for follow, and you do not want to, just [i]politely[/i] decline their request.  If they keep spamming you with requests, you can use the Report button on their comments.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]7.2 [url=https://scratch.mit.edu/discuss/post/3513044/]Allow Scratchers to moderate the website[/url][/b]
A community moderator program used to exist where Scratchers could moderate the website, but it was removed due to some very inappropriate things showing up in the report queue, among other reasons.  A volunteer program could also encourage trolls to use moderator tools to cause problems on the website.  As a result, the Scratch Team has decided to only allow adults to moderate the website, including the forums, and those adults would need to join the Scratch Team as a paid position in order to moderate the website.

If you are 18 or older, legally allowed to work in the United States, and are interested in moderating the website, check out the "Careers" link at the bottom of the website to see if there are any openings for the "Community Moderator" position.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]7.3 [url=https://scratch.mit.edu/discuss/post/2706108/]Scratchers and Scratch Team members should not promote political views[/url][/b]
According to the Community Guidelines, [i]"Scratch welcomes people of all ages, races, ethnicities, religions, abilities, sexual orientations, and gender identities."[/i]  As long as someone's beliefs and statements are respectful and welcoming towards all groups of people, they are allowed to express them on the Scratch website.  This includes all users, including members of the Scratch Team; in particular, the Scratch Team will continue to feature projects and studios that they believe promote the core values of Scratch and its community.

More detailed explanations in the case of Scratch's LGBTQ+ ideas can be found in [url=https://scratch.mit.edu/discuss/post/4455151/]this post[/url] and [url=https://scratch.mit.edu/discuss/post/2704445/]this post[/url].[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]7.4 [url=https://scratch.mit.edu/discuss/post/3023560/]Relax or remove the extension policy[/url][/b]
Browser extensions, userscripts, and userstyles are not allowed to be mentioned on Scratch as per the [url=https://scratch.mit.edu/discuss/topic/284272/]extension policy[/url].  Although such extensions may be useful, it is not easy to tell if the extension is harmful to your device.  The Scratch Team believes that the potential risks and harm in allowing browser extensions outweigh the benefits, and are not looking for ways to improve this policy.  This includes browser extensions, userscripts, and userstyles made by anyone, including Scratchers or well-known companies like Google.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]7.5 [url=https://scratch.mit.edu/discuss/post/3983330/]Propose your own projects to be featured[/url][/b]
Scratchers can suggest projects that they think should be featured in the [url=https://scratch.mit.edu/studios/28715018/]Propose Projects to be Featured[/url] studio.  One of the rules of proposing projects is that you cannot propose your own projects to be featured.  There are several reasons why this rule is in place.  First, if users could propose their own projects, then there would be more requests in the studio, and it would be difficult for curators to add them all.  Second, proposing someone else's project helps emphasize that Scratch is a helpful and supportive community, as proposing someone's project to be featured is an indication that the project creator has made a good project.  Lastly, this verifies that at least one other person has seen the project and agrees that it is a feature-worthy project, leading to higher-quality proposals.

If you would like your own project to be featured, keep in mind that you can actually ask someone else to propose your project for you.  Be sure to practice good advertising as described in [url=https://scratch.mit.edu/discuss/topic/396541/]this topic[/url], and be polite when asking.  Keep in mind that they may decide not to propose it; you should not try to force them to propose it.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]7.6 [url=https://scratch.mit.edu/discuss/post/4287696/]Ability to vote on featured projects[/url][/b]
There are three [url=https://scratch.mit.edu/discuss/topic/845057/]temporarily paused[/url] front page categories that are controlled entirely by the Scratch community: "Projects Curated by", "What the Community is Remixing", and "What the Community is Loving."  The "Featured Projects" row is useful to give the Scratch Team a chance to showcase projects that they feel are inspirational, highlight specific cultures, and are not very popular.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]7.7 [url=https://scratch.mit.edu/discuss/post/7752840/]Change the types of projects to be featured[/url][/b]
The Scratch Team has a list of types of projects they are looking to feature in the [url=https://scratch.mit.edu/studios/28715018]Propose Projects to be Featured studio[/url].  Such a list has existed for years, and the Scratch Team is happy with the kinds of projects they have been featuring.  While some Scratchers are unhappy with the types of projects being featured, it is ultimately up to the Scratch Team to decide what to feature.[/quote]

[quote][b]Catscratcher07 wrote, in [url=https://scratch.mit.edu/discuss/topic/896403/]TIaULoRS[/url]:[/b]
[b]7.8 [url=https://scratch.mit.edu/discuss/post/7841418/]Official contests on Scratch[/url][/b]
Scratchers often host contests about making a certain type of Scratch project, and it has been suggested that the Scratch Team should host an official contest.  However, Scratch is not about competition; the Scratch Team would prefer to emphasize the fun of creativity and learning without doing so in a competitive environment.  Scratchers are still allowed to host their own contests, but the Scratch Team will not hold any official contests.[/quote]