SMG4fan7236 wrote:

Za-Chary wrote:

VedanshS933 wrote:

remix tree is rejected

https://scratch.mit.edu/discuss/post/8773749/

That's a surprise.

I think I'd like to add it to the list — seems popular — but unfortunately not much of a reason was given as to its rejection. I've seen some possible reasons in this thread; how plausibly official do these reasons sound?

In particular, if I add this to the list, I'd really like to avoid any mention of NFE (I have been trying to do this from the start), even though preventing NFE detectors from working sounds like one very likely reason for removing the remix tree (assuming this is true). Is there a way that I can explain its rejection without explicitly mentioning NFE?

My topic explains why it was rejected.

Catscratcher07 wrote:

SMG4fan7236 wrote:

Za-Chary wrote:

VedanshS933 wrote:

remix tree is rejected

https://scratch.mit.edu/discuss/post/8773749/

That's a surprise.

I think I'd like to add it to the list — seems popular — but unfortunately not much of a reason was given as to its rejection. I've seen some possible reasons in this thread; how plausibly official do these reasons sound?

In particular, if I add this to the list, I'd really like to avoid any mention of NFE (I have been trying to do this from the start), even though preventing NFE detectors from working sounds like one very likely reason for removing the remix tree (assuming this is true). Is there a way that I can explain its rejection without explicitly mentioning NFE?

My topic explains why it was rejected.

Just because it was implemented after your suggestion doesn't mean that it was implemented for the same reasons as brought up in your suggestion, nor that it was implemented exactly how you suggested it. I do not see sufficient evidence to be 100% certain that re-adding it is rejected, and no moderator has asked for it to be added to TOLoRS (as you suggested), let alone directly added it.

Za-Chary wrote:

-snip-

yell [is this a rejected block?] ::looks

eyeball8899 wrote:

yell [is this a rejected block?] ::looks

<If [message v] received::events>
<When [message v] received::events>

SMG4fan7236 wrote:

I suggested to remove the remix tree page entirely because of users able to see inappropriate thumbnails of previously shared projects associated with terminated accounts. I think that explains why re-adding it is rejected.

SMG4fan7236 wrote:

Catscratcher07 wrote:

SMG4fan7236 wrote:

Za-Chary wrote:

My topic explains why it was rejected.

Just because it was implemented after your suggestion doesn't mean that it was implemented for the same reasons as brought up in your suggestion, nor that it was implemented exactly how you suggested it. I do not see sufficient evidence to be 100% certain that re-adding it is rejected, and no moderator has asked for it to be added to TOLoRS (as you suggested), let alone directly added it.

I suggested to remove the remix tree page entirely because of users able to see inappropriate thumbnails of previously shared projects associated with terminated accounts. I think that explains why re-adding it is rejected.

WigglyJoey wrote:

Maybe edit the voting featured projects suggestion because what the community is loving/remixing is gone and FPCs are paused for now.

nikky10000000 wrote:

For the ones where theres an ambiguity, cant we just.. do both?

<If [message v] received::events>
<When [message v] received::events>

mtaka4 wrote:

kind of?

Catscratcher07 wrote:

this was closed as a suggestion list, not a rejection.

cheddargirl wrote:

Suggestion 2: exclusion of clickers and platforms from SDS studios and other featured studios.
-> this is NOT okay to put forth for consideration, because it is a discriminatory agenda rather than a suggestion. Scratch was designed for beginners and young children in mind, and platformers and clickers are popular beginner-type projects. To exclude them would mean going against Scratch's values.

Catscratcher07 wrote:

nikky10000000 wrote:

For the ones where theres an ambiguity, cant we just.. do both?

<If [message v] received::events>
<When [message v] received::events>

That does not resolve the ambiguity of the blocks.

<(broadcast v) running?::events>

when gf clicked
say [text 1] for (2) seconds
broadcast (say other text v) and wait
say [text 3] for (2) seconds
when I receive [say other text v]
say [text 2] for (2) seconds

Catscratcher07 wrote:

-snip-

Just because you made a suggestion that might have been the reason the ST removed it doesn't mean that it is rejected to re-add it. Just because something has been removed does not mean re-adding it is rejected, it is entirely possible (although very unlikely) the remixtree is being reprogrammed to avoid the issues it has. Unless a moderator gives a clear rejection of re-adding remixtrees, it whould not be considered rejected.

Paddle2See wrote:

Sorry - this is not a bug. That feature was removed back when we moved to 3.0. It remained accessible through the URL for a while. But it has not been a feature and it has not been supported. It was finally redirected when it was noted that it was possible (in some cases) to see deleted content through the remix tree.

mtaka4 wrote:

Catscratcher07 wrote:

this was closed as a suggestion list, not a rejection.

I'm reffering to

cheddargirl wrote:

Suggestion 2: exclusion of clickers and platforms from SDS studios and other featured studios.
-> this is NOT okay to put forth for consideration, because it is a discriminatory agenda rather than a suggestion. Scratch was designed for beginners and young children in mind, and platformers and clickers are popular beginner-type projects. To exclude them would mean going against Scratch's values.

medians wrote:

Catscratcher07 wrote:

nikky10000000 wrote:

For the ones where theres an ambiguity, cant we just.. do both?

<If [message v] received::events>
<When [message v] received::events>

That does not resolve the ambiguity of the blocks.

What about this?

<(broadcast v) running?::events>

For example, if you had only one sprite:

when gf clicked
say [text 1] for (2) seconds
broadcast (say other text v) and wait
say [text 3] for (2) seconds
when I receive [say other text v]
say [text 2] for (2) seconds

It would report true when “text 2” is being said, and false otherwise

SMG4fan7236 wrote:

Catscratcher07 wrote:

-snip-

Just because you made a suggestion that might have been the reason the ST removed it doesn't mean that it is rejected to re-add it. Just because something has been removed does not mean re-adding it is rejected, it is entirely possible (although very unlikely) the remixtree is being reprogrammed to avoid the issues it has. Unless a moderator gives a clear rejection of re-adding remixtrees, it whould not be considered rejected.

Look at this:

Paddle2See wrote:

Sorry - this is not a bug. That feature was removed back when we moved to 3.0. It remained accessible through the URL for a while. But it has not been a feature and it has not been supported. It was finally redirected when it was noted that it was possible (in some cases) to see deleted content through the remix tree.

Catscratcher07 wrote:

SMG4fan7236 wrote:

Catscratcher07 wrote:

-snip-

Just because you made a suggestion that might have been the reason the ST removed it doesn't mean that it is rejected to re-add it. Just because something has been removed does not mean re-adding it is rejected, it is entirely possible (although very unlikely) the remixtree is being reprogrammed to avoid the issues it has. Unless a moderator gives a clear rejection of re-adding remixtrees, it whould not be considered rejected.

Look at this:

Paddle2See wrote:

Sorry - this is not a bug. That feature was removed back when we moved to 3.0. It remained accessible through the URL for a while. But it has not been a feature and it has not been supported. It was finally redirected when it was noted that it was possible (in some cases) to see deleted content through the remix tree.

While this does confirm why it was removed, it is on a BaG topic and therefore was closed for not being a bug, not as a rejection. While it is very likely rejected, there is still enough of a possibility that the original rejection was referring to adding a button to a non-existent remixtree rather than re-adding the remix tree (with it's flaws removed) that it cannot be considered undoubtedly rejected, as is required for TOLoRS.

7.18 Bring back the Remix Tree
While the Remix Tree was a useful tool for some users to visualize a project's remix history, it contained a significant security and moderation vulnerability. The page could, on occasion, display the thumbnails or titles of deleted projects, including content that was moderated and removed for being inappropriate (mostly from deleted accounts that had previously shared projects). This presented an unacceptable risk of exposing young users to harmful content. Since the Scratch Team's top priority is to provide a safe and kid-friendly environment, we cannot re-implement a feature with this kind of security flaw. The decision to remove the Remix Tree was made to eliminate this risk entirely and protect all members of the community.

A good reason why this suggestion was rejected can be found on this post.

SMG4fan7236 wrote:

Catscratcher07 wrote:

SMG4fan7236 wrote:

Catscratcher07 wrote:

-snip-

Just because you made a suggestion that might have been the reason the ST removed it doesn't mean that it is rejected to re-add it. Just because something has been removed does not mean re-adding it is rejected, it is entirely possible (although very unlikely) the remixtree is being reprogrammed to avoid the issues it has. Unless a moderator gives a clear rejection of re-adding remixtrees, it whould not be considered rejected.

Look at this:

Paddle2See wrote:

Sorry - this is not a bug. That feature was removed back when we moved to 3.0. It remained accessible through the URL for a while. But it has not been a feature and it has not been supported. It was finally redirected when it was noted that it was possible (in some cases) to see deleted content through the remix tree.

While this does confirm why it was removed, it is on a BaG topic and therefore was closed for not being a bug, not as a rejection. While it is very likely rejected, there is still enough of a possibility that the original rejection was referring to adding a button to a non-existent remixtree rather than re-adding the remix tree (with it's flaws removed) that it cannot be considered undoubtedly rejected, as is required for TOLoRS.

We could do this:

7.18 Bring back the Remix Tree
While the Remix Tree was a useful tool for some users to visualize a project's remix history, it contained a significant security and moderation vulnerability. The page could, on occasion, display the thumbnails or titles of deleted projects, including content that was moderated and removed for being inappropriate (mostly from deleted accounts that had previously shared projects). This presented an unacceptable risk of exposing young users to harmful content. Since the Scratch Team's top priority is to provide a safe and kid-friendly environment, we cannot re-implement a feature with this kind of security flaw. The decision to remove the Remix Tree was made to eliminate this risk entirely and protect all members of the community.

A good reason why this suggestion was rejected can be found on this post.

SMG4fan7236 wrote:

Catscratcher07 wrote:

~snip~
While this does confirm why it was removed, it is on a BaG topic and therefore was closed for not being a bug, not as a rejection. While it is very likely rejected, there is still enough of a possibility that the original rejection was referring to adding a button to a non-existent remixtree rather than re-adding the remix tree (with it's flaws removed) that it cannot be considered undoubtedly rejected, as is required for TOLoRS.

We could do this:

7.18 Bring back the Remix Tree
While the Remix Tree was a useful tool for some users to visualize a project's remix history, it contained a significant security and moderation vulnerability. The page could, on occasion, display the thumbnails or titles of deleted projects, including content that was moderated and removed for being inappropriate (mostly from deleted accounts that had previously shared projects). This presented an unacceptable risk of exposing young users to harmful content. Since the Scratch Team's top priority is to provide a safe and kid-friendly environment, we cannot re-implement a feature with this kind of security flaw. The decision to remove the Remix Tree was made to eliminate this risk entirely and protect all members of the community.

A good reason why this suggestion was rejected can be found on this post.

SMG4fan7236 wrote:

We could do this:

7.18 Bring back the Remix Tree
While the Remix Tree was a useful tool for some users to visualize a project's remix history, it contained a significant security and moderation vulnerability. The page could, on occasion, display the thumbnails or titles of deleted projects, including content that was moderated and removed for being inappropriate (mostly from deleted accounts that had previously shared projects). This presented an unacceptable risk of exposing young users to harmful content. Since the Scratch Team's top priority is to provide a safe and kid-friendly environment, we cannot re-implement a feature with this kind of security flaw. The decision to remove the Remix Tree was made to eliminate this risk entirely and protect all members of the community.

-snip-

bfdifan2013 wrote:

SMG4fan7236 wrote:

We could do this:

7.18 Bring back the Remix Tree
While the Remix Tree was a useful tool for some users to visualize a project's remix history, it contained a significant security and moderation vulnerability. The page could, on occasion, display the thumbnails or titles of deleted projects, including content that was moderated and removed for being inappropriate (mostly from deleted accounts that had previously shared projects). This presented an unacceptable risk of exposing young users to harmful content. Since the Scratch Team's top priority is to provide a safe and kid-friendly environment, we cannot re-implement a feature with this kind of security flaw. The decision to remove the Remix Tree was made to eliminate this risk entirely and protect all members of the community.

-snip-

(responding to underlined part) This might sound slightly dumb, but can't the Scratch Team just edit the remix tree to filter all project thumbnails if their visibility status is anything other than the normal status, and then readd it once it's fully fixed?