ocular rewritten

Why can't there be collaborations on Scratch? 2 people working on a project at the same time is rejected, but instead of doing that, they would get turns.

Pros of getting turns:

• Better able to encourage Scratchers to cooperate and share their ideas
  
• Would not take up as much server space/memory as 2 people working on a project at the same time
  
• Is a fair system, as it includes giving credit to both people in the collaboration
  

(Idea from @Nambaseking01):

Nambaseking01 wrote:

Maybe you should also mention that not giving credits to the user that helped with the collaboration could also cause legal issues because Scratch's license requires people to give credits (which will be automated, but I feel like this needs to be clarified in OP)

Cons of getting turns: (None)

Also, please see https://scratch.mit.edu/projects/356058879/ for a visual/explanatory representation of how this might look like on Scratch.

The quote below helps Scratchers understand this suggestion better.

Za-Chary wrote:

Okay, I think I understand what you mean now. I would like to rescind my earlier post, and make a new one.

Support, but only with the following critera:

1. The project is always accessible to the public from the project owner's profile. As you indicate, “the project would be on the last person was working on the collab project's “My stuff” page.” I think this could work well, but the project should still be on the project owner's profile since he/she started it. Would it be accessible on the collaborator's profile as well? Perhaps. But it shouldn't “bounce back and forth” between profiles.
   
   
2. Rather than immediately adding users, you must invite them. That is, the user must accept the request to collaborate. I imagine this would work similarly to how studio invites work. It might lead to more notifications, but it's a small sacrifice to the alternative, which is “collaborating” on projects you don't actually want to work on. Furthermore, only the “project owner” (the user who started the project) can invite users, to reduce unwanted invites.
   
   
3. All users who helped collaborate on the project get credit in some way. This could be as simple as putting “by Za-Chary and LuckyLucky7” under the project title, with the user who initially started the project having their name put first. Obviously we don't want to steal credit from anyone. Furthermore, once added to a collaboration, no one's credit can be removed, although their privileges of working on the project may be revoked (again, by the project owner).
   
   
4. There is a “timeout” mechanic. Without one, you could share a project, invite me to collaborate on it, and then allow me my turn to work on it. At this point, I could just quit Scratch (be inactive), and you would never get your turn. With the timeout option, after a week (regardless of inactivity or not), you (as the project owner) automatically gain control of the project again, although the project would still say that I helped collaborate on it. If I was actually working on it and took a week off, you could just send me a “It's your turn” message again.
   
   
5. There is a maximum number of 2 people allowed to work on a project at a time. That is, you can only send an invite to one other person. This way we don't have any games of “owner keep-away” where 3 other people send “It's your turn” messages to each other, and not the project owner. Doing this would also eliminate any use of “invite everyone” projects, which could just get confusing.
   

Perhaps some of this was implied in your original suggestion, in which case, I'm sorry for going into so much detail. I do like your suggestion now — I think this could work well. Let me know what you think of my feedback.

Additionally, there could be a place where the owner of the collaboration would be able to access a project version history(suggested by @gaming271):

LuckyLucky7 wrote:

gaming271 wrote:

I like it! But, if this is not there, then please add this to the discussion, make it so that if somebody is finished with their turn, it will make a saved copy and add a button that allows you to assess a “history” of the copies, so if somebody deletes the project's code or makes a unwanted change, then the other user can restore the code by accessing his previous turn in the history. If you do not understand, you can ask for clarification. Also add that the “user2” is not able to delete the project and only the main person can do it. (user1) When the project is deleted, the collab is deleted.

Interesting idea.

However, what if there are millions of projects in the project history just because of every single change? I think that a new project should be added to the project history every hour, depending on how much the project changes. For example, if the other user uploaded a project that they downloaded onto their device and then uploaded it into the collab, the project that was there before the file got uploaded would be added to the project history.

There should also be a non-duplicate checker in the history of the projects. What this does is remove projects from the project history if they are exact copies of one another.

The quote below helps Scratchers know that they got or lost their turn to edit the collaboration project..

LuckyLucky7 wrote:

TonyBrown148 wrote:

Overall result: Support!
Community benefits: Medium, makes collabs easier.
Implementation difficulty: Medium, a little bit complicated, but not very hard.
Possible improvements: A message will be sent if the user gets or loses the turn to edit.

Good suggestion. It would let Scratchers know that they are in a collaboration and they would probably decide to work on it when they can.

EDIT:
Since I have edited this post, everything above this edit was last edited by me on July 16, 2020 08:28:47.

Since this topic and the project that has been made for it have been getting a lot of attention recently, a petition to support this suggestion has been made! You can sign the petition using the comments section in this petition.

No support.

This is an easy way to do private messaging, which is rejected. Although you could easily report the person, there are things that you can put in a project that are much worse than things you can comment. This includes scary, violent, and graphic images which could scar some of the younger users.

Real-time collaboration is not the only way of collaboration, and it's not the only reason the Scratch Team isn't doing collaboration.

Edit: I made this post back when I didn't understand exactly what @LuckyLucky7 was suggesting.

Za-Chary wrote:

This is an easy way to do private messaging, which is rejected. Although you could easily report the person, there are things that you can put in a project that are much worse than things you can comment. This includes scary, violent, and graphic images which could scar some of the younger users.

You can already do that with normal projects, and I don't think this feature will facilitate or encourage that.

To use this feature to message privately is effectively the same as having two independent projects containing hidden messages from each user since you have to wait for the other user to read your messages before deleting them (rather than creating and then deleting the messages in real time).

Sheep_maker wrote:

Za-Chary wrote:

This is an easy way to do private messaging, which is rejected. Although you could easily report the person, there are things that you can put in a project that are much worse than things you can comment. This includes scary, violent, and graphic images which could scar some of the younger users.

You can already do that with normal projects, and I don't think this feature will facilitate or encourage that.

To use this feature to message privately is effectively the same as having two independent projects containing hidden messages from each user since you have to wait for the other user to read your messages before deleting them (rather than creating and then deleting the messages in real time).

The difference with this suggestion, as I'm interpreting it, is that projects will not be shared throughout this whole process. The way Scratch is set up now, a project must be publicly shared in order for others to access it, in which case anyone can see it and report it.

However, with this suggestion, anything malicious done in a project could be directed towards one user only, and only that user would be able to see it, before it gets reported. But by then, the damage would be done.

Za-Chary wrote:

The difference with this suggestion, as I'm interpreting it, is that projects will not be shared throughout this whole process. The way Scratch is set up now, a project must be publicly shared in order for others to access it, in which case anyone can see it and report it.

I doubt that the Scratch Team would implement the suggestion like this. Additionally, many previous suggestions for collaboration specified that projects would have to be shared beforehand, and it's reasonable to assume the same for this as well.

The problems you list are problems with allowing projects to be privately shared, not problems directly of this suggestion.

With this suggestion, are the projects not privately shared among two people? Perhaps there is something I'm not understanding.

Bump.

LuckyLucky7 wrote:

Bump.

You shouldn't bump without responding to unanswered questions.

Za-Chary wrote:

With this suggestion, are the projects not privately shared among two people? Perhaps there is something I'm not understanding.

They could make it so that the projects are shared, but two users have access to editing it.

RandomPersonGRAA wrote:

Za-Chary wrote:

With this suggestion, are the projects not privately shared among two people? Perhaps there is something I'm not understanding.

They could make it so that the projects are shared, but two users have access to editing it.

Well, if that were the case, can't two people just keep remixing the same project instead, which is possible now?

Za-Chary wrote:

RandomPersonGRAA wrote:

Za-Chary wrote:

With this suggestion, are the projects not privately shared among two people? Perhaps there is something I'm not understanding.

They could make it so that the projects are shared, but two users have access to editing it.

Well, if that were the case, can't two people just keep remixing the same project instead, which is possible now?

The point of the suggestion is to make collaboration easier. Although that is already a solution, it will be harder for those 2 people to keep track of the remixes and access them.

LuckyLucky7 wrote:

The point of the suggestion is to make collaboration easier. Although that is already a solution, it will be harder for those 2 people to keep track of the remixes and access them.

I understand what you're trying to suggest, although maybe I don't understand it fully. The projects have to be publicly shared somehow, otherwise we run the risk of private messaging.

Is your suggestion saying that the project would be shared, and then someone can collaborate with you on it as long as the project is shared, via a checkbox mechanism (perhaps similar to the “Draft” box)?

Za-Chary wrote:

LuckyLucky7 wrote:

The point of the suggestion is to make collaboration easier. Although that is already a solution, it will be harder for those 2 people to keep track of the remixes and access them.

I understand what you're trying to suggest, although maybe I don't understand it fully. The projects have to be publicly shared somehow, otherwise we run the risk of private messaging.

Is your suggestion saying that the project would be shared, and then someone can collaborate with you on it as long as the project is shared, via a checkbox mechanism (perhaps similar to the “Draft” box)?

Yes.

What I'm getting from this is that, you share a project, but choose to only allow another person to edit it, though people can remix and look inside the project and see code, but it's just a project that is created by 2 people with out private messaging since it would have to be shared?

that probably made no sense, so I'll try again.
2 people can edit 1 project with out having to remix, but only when it's shared
since the project is shared other people can remix the project, and see inside it, as to prevent private messaging

Did I get it right?

Okay, I think I understand what you mean now. I would like to rescind my earlier post, and make a new one.

Support, but only with the following critera:

1. The project is always accessible to the public from the project owner's profile. As you indicate, “the project would be on the last person was working on the collab project's “My stuff” page.” I think this could work well, but the project should still be on the project owner's profile since he/she started it. Would it be accessible on the collaborator's profile as well? Perhaps. But it shouldn't “bounce back and forth” between profiles.
   
   
2. Rather than immediately adding users, you must invite them. That is, the user must accept the request to collaborate. I imagine this would work similarly to how studio invites work. It might lead to more notifications, but it's a small sacrifice to the alternative, which is “collaborating” on projects you don't actually want to work on. Furthermore, only the “project owner” (the user who started the project) can invite users, to reduce unwanted invites.
   
   
3. All users who helped collaborate on the project get credit in some way. This could be as simple as putting “by Za-Chary and LuckyLucky7” under the project title, with the user who initially started the project having their name put first. Obviously we don't want to steal credit from anyone. Furthermore, once added to a collaboration, no one's credit can be removed, although their privileges of working on the project may be revoked (again, by the project owner).
   
   
4. There is a “timeout” mechanic. Without one, you could share a project, invite me to collaborate on it, and then allow me my turn to work on it. At this point, I could just quit Scratch (be inactive), and you would never get your turn. With the timeout option, after a week (regardless of inactivity or not), you (as the project owner) automatically gain control of the project again, although the project would still say that I helped collaborate on it. If I was actually working on it and took a week off, you could just send me a “It's your turn” message again.
   
   
5. There is a maximum number of 2 people allowed to work on a project at a time. That is, you can only send an invite to one other person. This way we don't have any games of “owner keep-away” where 3 other people send “It's your turn” messages to each other, and not the project owner. Doing this would also eliminate any use of “invite everyone” projects, which could just get confusing.
   

Perhaps some of this was implied in your original suggestion, in which case, I'm sorry for going into so much detail. I do like your suggestion now — I think this could work well. Let me know what you think of my feedback.

Za-Chary wrote:

-snip-

Support if the reasons above are done

Za-Chary wrote:

Okay, I think I understand what you mean now. I would like to rescind my earlier post, and make a new one.

Support, but only with the following critera:

1. The project is always accessible to the public from the project owner's profile. As you indicate, “the project would be on the last person was working on the collab project's “My stuff” page.” I think this could work well, but the project should still be on the project owner's profile since he/she started it. Would it be accessible on the collaborator's profile as well? Perhaps. But it shouldn't “bounce back and forth” between profiles.
   
   
2. Rather than immediately adding users, you must invite them. That is, the user must accept the request to collaborate. I imagine this would work similarly to how studio invites work. It might lead to more notifications, but it's a small sacrifice to the alternative, which is “collaborating” on projects you don't actually want to work on. Furthermore, only the “project owner” (the user who started the project) can invite users, to reduce unwanted invites.
   
   
3. All users who helped collaborate on the project get credit in some way. This could be as simple as putting “by Za-Chary and LuckyLucky7” under the project title, with the user who initially started the project having their name put first. Obviously we don't want to steal credit from anyone. Furthermore, once added to a collaboration, no one's credit can be removed, although their privileges of working on the project may be revoked (again, by the project owner).
   
   
4. There is a “timeout” mechanic. Without one, you could share a project, invite me to collaborate on it, and then allow me my turn to work on it. At this point, I could just quit Scratch (be inactive), and you would never get your turn. With the timeout option, after a week (regardless of inactivity or not), you (as the project owner) automatically gain control of the project again, although the project would still say that I helped collaborate on it. If I was actually working on it and took a week off, you could just send me a “It's your turn” message again.
   
   
5. There is a maximum number of 2 people allowed to work on a project at a time. That is, you can only send an invite to one other person. This way we don't have any games of “owner keep-away” where 3 other people send “It's your turn” messages to each other, and not the project owner. Doing this would also eliminate any use of “invite everyone” projects, which could just get confusing.
   

Perhaps some of this was implied in your original suggestion, in which case, I'm sorry for going into so much detail. I do like your suggestion now — I think this could work well. Let me know what you think of my feedback.

1a. (about who's profile the collab would be accessible on) This detail does make sense, therefore it has no problems.

1b. (part about the “bounce back and forth” and my stuff pages) This detail has no problems, but does have some exceptions. For example, if it is not my turn and I click on the collab project, there would have to be a popup(like the 3 tag limit popup) saying that it is not my turn, and instead it would be your turn. The project would show up on both of our “my stuff” pages, but on my page, it would be inaccessible and you would be the only person that could actually be able to access the project.

2-4 has no problems.

5. The problem with this detail is that people can use the say blocks, comments, etc. to private message each other. If you are referring to the maximum amount of people that can work on the project, then that number should be 3 people.

LuckyLucky7 wrote:

5. The problem with this detail is that people can use the say blocks, comments, etc. to private message each other. If you are referring to the maximum amount of people that can work on the project, then that number should be 3 people.

Yes, I was referring to a maximum of 2 collaborators, not that they can work on the project at the same time. If the maximum number is 3 people, you can still play “owner keep-away” somehow, which would be unfortunate. There'd need to be a way to counteract that.

Za-Chary wrote:

LuckyLucky7 wrote:

5. The problem with this detail is that people can use the say blocks, comments, etc. to private message each other. If you are referring to the maximum amount of people that can work on the project, then that number should be 3 people.

Yes, I was referring to a maximum of 2 collaborators, not that they can work on the project at the same time. If the maximum number is 3 people, you can still play “owner keep-away” somehow, which would be unfortunate. There'd need to be a way to counteract that.

There could be an order of who the project goes to first, second, and third(this depends on collab joining order).

Here's my suggestion:
Collaborating will be very similar to remixing. But to start, you must invite 1+ people to do the collab. Next, when/if the users invited accept, the owner of the collab (AKA the person who invited the other users) can start the collaboration. The owner will start, then the next person invited, etc, etc… and then will start over again. The big difference will be that this will remain as one project. Not like when you collaborate through remixing and every single remix is shared. (Unless you unshare it afterwards) The owner along with all of the collaborators will have this project on their profile.

This will be completely public, and will make the collaboration processes much easier!

Oops, I didn't see Za-Charry already had this idea, sorry!

Eee support, even if it's possibly a dupe.

Also, even if they didn't add private messaging, it could easily be done with notes. So that's not really a fair argument.

Za-Chary wrote:

Okay, I think I understand what you mean now. I would like to rescind my earlier post, and make a new one.

Support, but only with the following critera:

1. The project is always accessible to the public from the project owner's profile. As you indicate, “the project would be on the last person was working on the collab project's “My stuff” page.” I think this could work well, but the project should still be on the project owner's profile since he/she started it. Would it be accessible on the collaborator's profile as well? Perhaps. But it shouldn't “bounce back and forth” between profiles.
   
   
2. Rather than immediately adding users, you must invite them. That is, the user must accept the request to collaborate. I imagine this would work similarly to how studio invites work. It might lead to more notifications, but it's a small sacrifice to the alternative, which is “collaborating” on projects you don't actually want to work on. Furthermore, only the “project owner” (the user who started the project) can invite users, to reduce unwanted invites.
   
   
3. All users who helped collaborate on the project get credit in some way. This could be as simple as putting “by Za-Chary and LuckyLucky7” under the project title, with the user who initially started the project having their name put first. Obviously we don't want to steal credit from anyone. Furthermore, once added to a collaboration, no one's credit can be removed, although their privileges of working on the project may be revoked (again, by the project owner).
   
   
4. There is a “timeout” mechanic. Without one, you could share a project, invite me to collaborate on it, and then allow me my turn to work on it. At this point, I could just quit Scratch (be inactive), and you would never get your turn. With the timeout option, after a week (regardless of inactivity or not), you (as the project owner) automatically gain control of the project again, although the project would still say that I helped collaborate on it. If I was actually working on it and took a week off, you could just send me a “It's your turn” message again.
   
   
5. There is a maximum number of 2 people allowed to work on a project at a time. That is, you can only send an invite to one other person. This way we don't have any games of “owner keep-away” where 3 other people send “It's your turn” messages to each other, and not the project owner. Doing this would also eliminate any use of “invite everyone” projects, which could just get confusing.
   

Perhaps some of this was implied in your original suggestion, in which case, I'm sorry for going into so much detail. I do like your suggestion now — I think this could work well. Let me know what you think of my feedback.

I like these reasons, and though I supported it before, I think I support it much more now!

Bump.

Bump.

Bump.

Bump.

Bump.

LuckyLucky7, I do believe bumping this post isn't great, considering as it has had at least 5 bumps with no comments, let alone constructive ones.

RandomPersonGRAA wrote:

LuckyLucky7, I do believe bumping this post isn't great, considering as it has had at least 5 bumps with no comments, let alone constructive ones.

Eventually, there will be more posts(besides bumps).

Bump.

EDIT: Ok, why are the forums not saying that this post is the latest post? I didn't even edit anything…

Bump again(Because the forums are not bumping my posts properly)…

EDIT: Ok, now it's fixed…

Za-Chary wrote:

Okay, I think I understand what you mean now. I would like to rescind my earlier post, and make a new one.

Support, but only with the following critera:

1. The project is always accessible to the public from the project owner's profile. As you indicate, “the project would be on the last person was working on the collab project's “My stuff” page.” I think this could work well, but the project should still be on the project owner's profile since he/she started it. Would it be accessible on the collaborator's profile as well? Perhaps. But it shouldn't “bounce back and forth” between profiles.
   
   
2. Rather than immediately adding users, you must invite them. That is, the user must accept the request to collaborate. I imagine this would work similarly to how studio invites work. It might lead to more notifications, but it's a small sacrifice to the alternative, which is “collaborating” on projects you don't actually want to work on. Furthermore, only the “project owner” (the user who started the project) can invite users, to reduce unwanted invites.
   
   
3. All users who helped collaborate on the project get credit in some way. This could be as simple as putting “by Za-Chary and LuckyLucky7” under the project title, with the user who initially started the project having their name put first. Obviously we don't want to steal credit from anyone. Furthermore, once added to a collaboration, no one's credit can be removed, although their privileges of working on the project may be revoked (again, by the project owner).
   
   
4. There is a “timeout” mechanic. Without one, you could share a project, invite me to collaborate on it, and then allow me my turn to work on it. At this point, I could just quit Scratch (be inactive), and you would never get your turn. With the timeout option, after a week (regardless of inactivity or not), you (as the project owner) automatically gain control of the project again, although the project would still say that I helped collaborate on it. If I was actually working on it and took a week off, you could just send me a “It's your turn” message again.
   
   
5. There is a maximum number of 2 people allowed to work on a project at a time. That is, you can only send an invite to one other person. This way we don't have any games of “owner keep-away” where 3 other people send “It's your turn” messages to each other, and not the project owner. Doing this would also eliminate any use of “invite everyone” projects, which could just get confusing.
   

Perhaps some of this was implied in your original suggestion, in which case, I'm sorry for going into so much detail. I do like your suggestion now — I think this could work well. Let me know what you think of my feedback.

I support, but only with these conditions. This would greatly help collabs on Scratch. It also doesn't clog up space on the Scratch server with so many remixes.

Bump.

…

Abstain.

This certainly sounds great, especially with @Za-Chary's conditions, however since I have never collaborated before and probably won't on the same project I see no use for me personally. I understand other people may need it though.

Bump.

Necrobump.

Necrobumps are like necroposts but it is technically not a necropost because this suggestion currently does not have an existing workaround or duplicate topic. Plus, it's just bumping a topic.

Support!

Although I think this is a cool idea, the Scratch Team might have to approve the project before letting the other user continue the collab.
This would prevent inappropriate things and would probably help the whole safety thing.
Otherwise, this is a really good idea!

Za-Chary wrote:

Okay, I think I understand what you mean now. I would like to rescind my earlier post, and make a new one.

Support, but only with the following critera:

1. The project is always accessible to the public from the project owner's profile. As you indicate, “the project would be on the last person was working on the collab project's “My stuff” page.” I think this could work well, but the project should still be on the project owner's profile since he/she started it. Would it be accessible on the collaborator's profile as well? Perhaps. But it shouldn't “bounce back and forth” between profiles.

[…]

This would be a nice feature and would definitely prevent private messaging, but I think we should also consider Za-Chary's ideas. Since this is a huge demand by the Scratch community, I don't think I have any big objections.

Just one question to the Scratch Team: Will you manage to do it? This is pretty close to “live” collaborations so is the coding too hard?

Orangey2011 wrote:

Support!

Although I think this is a cool idea, the Scratch Team might have to approve the project before letting the other user continue the collab.

Sorry, what? Can't we just stick with the current project system and report anything that's inappropriate? I don't understand how a simple collab can cause issues like that…

Let me clarify that any posts I made on this topic, before this one, were made before I was on the Scratch Team.

I have not heard of any plans to implement collaborative features, but I believe we are still interested in it if we can find a way to make it work.

Za-Chary wrote:

Let me clarify that any posts I made on this topic, before this one, were made before I was on the Scratch Team.

I have not heard of any plans to implement collaborative features, but I believe we are still interested in it if we can find a way to make it work.

Persuade them. This can be interesting.

Nambaseking01 wrote:

Za-Chary wrote:

Let me clarify that any posts I made on this topic, before this one, were made before I was on the Scratch Team.

I have not heard of any plans to implement collaborative features, but I believe we are still interested in it if we can find a way to make it work.

Persuade them. This can be interesting.

Yes, let's persuade the Scratch Team. First, let me think about how to make this suggestion better…

Bump.

I updated the OP and created a project(which is just a concept) to go along with this suggestion so the suggestion flows better as a system in Scratch 3.

The OP also includes a list of pros and cons about implementing this suggestion.

I think this is a brilliant idea!

But, why have a limit of two people? Couldn't it be like a loop? Scratch could automatically pass it around. To avoid problems with people being inactive, if you don't do something within 24 hours of gaining access to the project, it will automatically pass it on. Then you can't pick who gets to edit the project.

Dragonlord767 wrote:

I think this is a brilliant idea!

But, why have a limit of two people? Couldn't it be like a loop? Scratch could automatically pass it around. To avoid problems with people being inactive, if you don't do something within 24 hours of gaining access to the project, it will automatically pass it on. Then you can't pick who gets to edit the project.

I think that having 2 people in a collaboration is enough. There is a way to collaborate with more than 1 Scratcher using this system, but it would involve removing Scratchers repeatedly.

I think that things should start simple. If this suggestion gets implemented into Scratch and turns out to be successful, then maybe there could be a way that having more than 2 people in a collaboration could also be successful.

We'll have to wait and see for ourselves…

Bump.

Bump.

Bump.

Hmm… Just a question (I've already posted here, seems like), would you be able to set the maximum date for inactivity?

Nambaseking01 wrote:

Hmm… Just a question (I've already posted here, seems like), would you be able to set the maximum date for inactivity?

If you're talking about collaboration activity or user activity in the collaboration, you cannot set any of these because I think that these are reasonable times.