sharkode wrote:

I don't see a point in including manual unsharing, since you know the consequences and are ok with them if you unshare it manually

So then why should it be different for censoring? For example, what if you want your updates to be silent (keeping the upload date) as opposed to loud (updating the upload date)?

Okay, before people (sharkode as an example) get their knickers in a knot between only changing the upload date for manual unsharing and changing it for censoring, how about a yes or no modal box that says something like “Do you want to change the upload date?” when you reshare a project.

This will act much like the report modal box. Here's a mockup of it.

No support,

If your smart enough and looking at the project ids (these are examples: this and This

Even if i just reshared the first one it doesnt change the project id, if the first one starts with a 5 and the other starts with a 6, the first one is older regarding share dates

OhOkSir12345 wrote:

No support,

If your smart enough and looking at the project ids (these are examples: this and This

Even if i just reshared the first one it doesnt change the project id, if the first one starts with a 5 and the other starts with a 6, the first one is older regarding share dates

Yes but not all people would pay attention to that url, especially people on mobile devices and people who don't even know that a smaller number in the URL means an earlier release. When making decisions, you have to remember that a lot of people on this website are really young, or could be ignorant to jey details before reporting. Simply having it so the original publish date is always shown could help bring an end to the problem.

Bump.

DifferentDance8 wrote:

Okay, before people (sharkode as an example) get their knickers in a knot between only changing the upload date for manual unsharing and changing it for censoring, how about a yes or no modal box that says something like “Do you want to change the upload date?” when you reshare a project.

This will act much like the report modal box. Here's a mockup of it.

I like this idea! This would help preserve the upload date of a project if “Keep” was selected. And if “Change” was selected, it would let people know the project was reuploaded again. It's really obvious for Weekend, because after being false reported a month ago, its new upload date is October 4th 2022.

OhOkSir12345 wrote:

(#106)
No support,

If your smart enough and looking at the project ids (these are examples: this and This

Even if i just reshared the first one it doesnt change the project id, if the first one starts with a 5 and the other starts with a 6, the first one is older regarding share dates

But why would this be a bad thing? I don't want the share date on my projects from the last decade to be ruined by some mass reporter idiots, or have someone mass report my April fool's day project only for it to have a share date on November, also, there is a way to steal a project and get a smaller ID, and it's surprisingly easy to do, I'm not going to tell you how to do it but it's possible to do.

Bump! This suggestion hasn't been getting any attention in about one third of a year.

support, mass reporting is a problem and we need to fix it

OhOkSir12345 wrote:

No support,

If your smart enough and looking at the project ids (these are examples: this and This

Even if i just reshared the first one it doesnt change the project id, if the first one starts with a 5 and the other starts with a 6, the first one is older regarding share dates

I see a lot of people getting confused on old projects because they wonder why the one with the higher id has an older date on the page.
Such as this:
scratch.mit.edu/projects/104
scratch.mit.edu/projects/105

Support because most Scratch users don't know that smaller project id number means older project which may cause a group of people to mass-report the project because they think it's an exact copy even though it's older than the other copy.

54387a wrote:

Support because most Scratch users don't know that smaller project id number means older project which may cause a group of people to mass-report the project because they think it's an exact copy even though it's older than the other copy.

Yeah, I've seen people ask why projects have remixes from x when it was shared on y.

Support, this would be good because it keeps the original project date after getting censored, and it prevents confusion.

Support, I’ve seen so many people that I can’t count (just saw yet another one) believe that a project was created on a certain date when it wasn’t, and then confused after looking at the remixes/comments/studios, or seeing someone or something say that it wasn’t created on that date, especially if they have no idea that resharing changes the date. There could also be an indicator if it’s an old project or a project created in an old version because I have seen people say in the comment sections of old projects “it’s broke”/“no code”/similar stuff (3.0 hid the code of some projects but you can tell it’s still there if there was a loop or something preventing it from stopping because of the green flag.
There should be a way to see the current share date and the first share date.
Edit: I’ve also seen users who unshared their old projects and later regretted it because it doesn’t keep the old date when you share it.

bump

Support! This would be amazing.

I am going to bump this because this is a very useful suggestion/idea.

This would be very nice. Would it cause problems to show the share date, and a note saying (Returned by ST on July 22, 2023)?

Elijah999999 wrote:

(#120)
This would be very nice. Would it cause problems to show the share date, and a note saying (Returned by ST on July 22, 2023)?

No because people might assume there was something that breaks the rule on the project which could lead to the user being harassed

Huge support. Adding to the OP, confusion on which project's the original wastes precious time that could've been used to moderate the website.

sharkode wrote:

Elijah999999 wrote:

(#120)
This would be very nice. Would it cause problems to show the share date, and a note saying (Returned by ST on July 22, 2023)?

No because people might assume there was something that breaks the rule on the project which could lead to the user being harassed

They would? How could they come to that conclusion if it was still up? Users who got taken down usually tell everyone about it anyway. But although I think what you said is unlikely, it's still possible, and that would cause more harm than it would help, so maybe I should just drop the idea altogether.