Hi.

So recently, there has been a large amount of suggestions asking for live editing of projects with multiple users. However, this leads to many problems such as PM'ing, which is already rejected, and the fact that Scratch is not designed for live editing, and therefore cannot handle it.


So, please add this common suggestion to the ‘rejected suggestion’ sticky.
Thanks!

What do you mean “live editing”?

f1lip wrote:

What do you mean “live editing”?

Basically multiple users editing the same project at the same time. Like, for example, for collaborations.

I agree with those posts. I think we should be able to report projects for PMing inside of them.

go to that sticky and ask him to add it

the2000 wrote:

I agree with those posts. I think we should be able to report projects for PMing inside of them.

The ST don't have enough resources or time to moderate every PM. And you haven't adressed the issue that Scratch cannot handle live editing.

Support.

Also, another reason for not implementing it would be because of the fact that live editing isn't how actual programmers collaborate. Encouraging this practice would also mean inefficient collaboration in the future.

iamunknown2 wrote:

Support.

Also, another reason for not implementing it would be because of the fact that live editing isn't how actual programmers collaborate. Encouraging this practice would also mean inefficient collaboration in the future.

Thank you! I'll add it to the FP.

Support.
Not to mention that remixing also adds a revision history in case something wrong happens or people want to see the development of your project.

I want this to happen. So many times I've seen a “Let's Collaborate Scratch!” suggestion and then gone to the stickies, found out it isn't on the rejected section, and sat there puzzled because I was certain it was.

Support.

I think you can just ask @jvvg on his profile

Btw the Rejector Sticky is open again, so you can ask jvvg to add it to the list there.

Support!

Bamp.

Nevermind this!

MathlyCat wrote:

Please add these types of suggestions on the Rejected sticky…



Thanks!

I already did, I'm just waiting for jvvg's response.

I agree that it isn't something we can support right now, because of the moderation and technical issues, however I don't agree with the statement that it teaches bad collaboration techniques. Just because it isn't the way something is done now, or by most people, isn't always a good reason to reject it.

I do think it should be added to the rejection list because the moderation and technical issues are quite substantial and I don't think we should spend time discussing it until we have more resources available to address those.

Paddle2See wrote:

I agree that it isn't something we can support right now, because of the moderation and technical issues, however I don't agree with the statement that it teaches bad collaboration techniques. Just because it isn't the way something is done now, or by most people, isn't always a good reason to reject it.

I do think it should be added to the rejection list because the moderation and technical issues are quite substantial and I don't think we should spend time discussing it until we have more resources available to address those.

Thanks for the input!

Paddle2See wrote:

Just because it isn't the way something is done now, or by most people, isn't always a good reason to reject it.

Although I agree with this statement generally, I think learning the state-of-the-art collaboration is essential for good collaboration, because of the very nature of collaboration. Sure, you could make radical designs for architecture, but collaboration is different - if your form of collaboration is ‘incompatible“ with others’ form of collaboration, you and the others would have a hard time collaborating.

There are advantages to current models for collaboration as opposed to the Google Drive like model. For example, offline access can be pretty painful - sure, you could wait to get online to sync your changes back, but what if someone had already made changes to it? You would probably say ”merging", but the 2 branches of code could have a chance of conflicting and merging weirdly/not merging at all, and thus dumping someone else's entire weekend of work . Although you could create an entire system that allows you to manually solve merging conflicts, there are other problems needed for solving e.g limited bandwidth (which is always a problem with live editing protocols), single point of failure (one server down and you're doomed!).

Some may argue that we will not need offline access (because we'll have 100% coverage and no oligopolies putting data caps on us) in the future, but I think that's a milestone very far away.

However, with systems like git, most of your time is offline, working on your full local copy of the code in your separate branch. If the main server's copy corrupts, any person with the local copy (which is required for your to work) could provide the copy and get the server back up and running. If there are merging conflicts, you can solve them manually. The list goes on and on.

Support.