[Update] Collaborative Editing is going to be the new default in Team Create

Heads up for all Developers!

This is now LIVE! Based on your feedback, we display a warning dialog if you publish the game and have uncommitted scripts in Drafts.

We improved script collaboration with Collaborative Editing in Team Create. It was opt-in, like a Beta feature, so we could monitor feedback on any impact it had on your workflow. From the games that use this, we have seen an objective improvement and are ready to move it forward.

At some point in next couple of weeks, we are going to turn Collaborative Editing ON by default in Team Create.

What does this mean for you?

  • If you are using Team Create and already turned on Collaborative Editing - you are all set!

  • If you are using Team Create but didn’t turn on Collaborative Editing yet, we will turn this on for you next week. Editing scripts will no longer lock your team members out. Scripts that you edit will be shown in the Drafts widget that you can commit when you are ready.

For now, you can still turn the setting back to OFF. But please give us feedback if you feel this wasn’t an improvement for you.

How do I turn this off?

What if I don’t use Team Create?
Then there is no change in behavior for you.

Where do we go from here?
You probably guessed this already, the next step after this will be to make Collaborative Editing just be part of Team Create. Once we have addressed any feedback we receive, we will remove this option (Game Settings > Options > Enable Collaborative Editing) in the future.


This topic was automatically opened after 14 minutes.

Editing scripts will no longer lock your team members out. Scripts that you edit will be shown in the Drafts widget that you can commit when you are ready.

The implications of this feature alone make me pretty excited to try out Collaborative Editing…


Personally, I dislike collaborative editing. It just seems like so much of a hassle just to update a script. If there was live editing (for an example, Google Docs) that would be a lot more nicer (given there’s an option for this). Plus, if the live editing had all the features we have for collaborative editing right now, that would be even better. But yeah, I don’t like the state which collaborative editing is in right now. In the future, please add an option to disable and re-enable this.

Edit: I understand if live editing isn’t possible, it’s just that collaborative editing is a hassle and I want to keep the option to enable and disable it.


AWESOME!! It’s like backseat driving but for coding. Now when someone sees a fellow coder get sloppy, they can start rewriting everything until they are so irritated they do it right the first time. :muscle:


WOOT WOOT!!! These new team create updates are amazing! Big thanks to whoever helped make this happen!! :smile:

But honestly, this one might be my least favorite, not saying you guys did a bad job, but just because of my opinion on this.


Collaborative editing does not work with my or my teams work flow. We have it off and plan to keep it off. Forcing it to not be a toggle will be a big negative for us.

Our problem is that either I’m the only scripter and I don’t need to commit my own changes every time I change one thing. It makes debugging annoying and a nightmare, especially working with multiple scripts.

The other problem is that when we do have multiple scripters were organized enough to not worry about overwriting each others work.

The main gripe is being forced to commit changes every time for every edit, and not being able to automatically commit on script close.

Until that issue is resolved me, my team, and a lot of my friends will only be annoyed by having it on by default, and even more by being forced to use it after.

Sorry for being negative, but I don’t like when features are forced upon users. I think they should always be a toggle. Also I am a fan of collaborative editing’s other features, just not how committing is handled atm.


The feature is cool and all but It does make things a little more difficult for my team, some people leave without committing drafts and then have old copies and then sometimes I commit the scripts and then they overlap it somehow.

It just makes thing a little more confusing but generally I do support Collaborative Editing, I think it might just be something my team and I have to adjust to and work out a plan.


This feature has it’s pro’s… I guess? and it’s cons.

When originally hearing about this is psyched up that us scripters would be able to edit in a live environment similar to how google docs work, as @xBeepBoop said, however after reading that it will be commits is a massive letdown.

I personally cannot find the appeal in this, forcing it upon everyone is going to be an annoyance for myself as well as my fellow project members.

When using this in beta it was way to much of a hassle to touch that I ended up disabling it within the first few minutes, it wasn’t worth my time now and I doubt it will be then.

Sorry for being so negative but this feature was a letdown to me.


I have very similar sentiment to @SnakeWorl on this, and will disable Collaborative Editing on all my projects the moment this switch happens.

Usually I am a solo scripter on my projects and wanted to use Team Create to bring in friends who wanted to help build or make single assets. When working with anyone else who may be opening scripts I’m live in a voice chat with them and we can simply communicate access requirements to individuals scripts.

Collaborative Editing introduces the following disruptions to my workflow:

  • I need to commit changes after every edit. I may be testing small changes or debugging code or updating old code which requires dozens of small changes and tests. Suddenly my workflow goes from Edit Script > Test, to Edit Script > Commit Changes > Test. This one extra step can add tons of time and missing it could result in thinking something is broken that has already been fixed.
  • I’m not a fan of forking code to collapse later. I’d rather one source exist and be locked from edits while I work on it than have to take the time later to collapse changes committed by different people at different times that may not actually work with eachother causing duplicate work.

As others have stated I’m far more a fan of live doc editing such as Google Docs uses than a Git style revision management system. I see the benefits, but I feel like it runs into the same pitfalls Gits do in that you either end up with people not working on something till a change is committed to avoid forking/collapsing, or you end up with forks that don’t work together.

I find it really cool that this feature exists as opt-in, but I dislike that I’m going to have to opt-out every time I make a team create.


I use Collaborative Editing in Team Create, and I’ve gotten used to the current workflow. However, there are definitely some quality-of-life features that need to be added. In particular:

  1. The “Drafts” window dynamically opens and closes based on whether you have edited a script. Unfortunately, though it remembers the position it was docked in, it doesn’t automatically open until you begin editing a script, unless you manually open it every time through View -> Drafts. It would be nice if there were a way to always automatically have this window open upon opening a place in studio.
  2. It’s particularly confusing for non-scripters due to the lack of indication that a script has been edited outside of the Drafts window (which non-scripters tend to ignore). The previous script editing system had an asterisk by the script window that indicated that you have unsaved changes to the server version of the script; there’s also an “Apply Edits” option in this context menu, but no “Commit” button. I see no reason why the asterisk and context menu option can’t be implemented to replace the “Apply edits” system for collaborative editing. image
  3. All commits are tied to a single script/module. This can cause breaking changes for those who have made changes to a critical script that are not yet merged (as happened with my non-scripter team member, for which it took about an hour to troubleshoot the reason why his game was breaking, yet mine wasn’t). We need the ability to bundle changes across multiple scripts in one commit, so that collaborators never end up with broken code due to an un-merged difference on a single module.
  4. It’s very inconvenient to always have to go to the drafts menu and commit the changes to every single script at once, and like I mentioned before, this can lead to broken code for those who are simultaneously editing a critical script, if they forget to merge their own changes. It’s also inconvenient that the drafts menu is the only place where you can commit/merge changes.

While this can mostly be solved with technical knowledge, for my non-programmer partner, it leads to some awkward situations when he edits code that I am simultaneously editing and forgets to apply his edits.


I understand where Roblox engineers are coming from with the commit structure, however most people that prefer that workflow are already using rojo. This type of collaborative editing can be confusing and prohibitive for new programmers.


100% agree. I understand the benefits that come from the structure, but people who get the most use from it opt-in or are using similar tools already. It’s not a fit for all teams and all styles though.

As I said, “I find it really cool that this feature exists as opt-in, but I dislike that I’m going to have to opt-out every time I make a team create.”

Somehow I predicted that people would be complaining about the git-style commit system despite live editing being a mess to handle (do you want people overwriting you code as you write it? Because that’s what’ll happen).

My only complaint is that often projects consist of one scripter, and I can see it being annoying to have to commit every change you make when you’re the only person working on the game’s code.

I guess the obvious question that I don’t think I asked on the original announcement is why not just go all the way with git? It seems like it would be preferable to interface with the program instead of implement its features on your own.


Come on now roblox we need REAL TIME COLLABORATIVE EDITING :eyes:


I’ve heard many scripters complain about how they dislike Collaborative Editing, but as a builder I don’t feel affected by this at all. I feel we should keep the default as it has always been, since it benefits everyone and not just builders. I’m not very informed on this though since i’m only a beginner in scripting

1 Like

Probably because the community already thinks the concept of committing alone is too much of a hassle.

Git was designed by people who wrote the Linux kernel, which is partly why I’ve spent the last week watching even adults run around in circles with Git. Probably not the best pick for Roblox, and the replies so far seem to reinforce that.


i dont really script, but i know how you feel about toggle able features that you don’t like, or don’t want in some places, be forced onto you later on anyway…


I’m not sure if this has enough UX polish to comfortably be an on-by-default or always-on feature yet.

Since December 13 there have been 4-5 bug reports in Post Approval about script changes not saving that were caused by users simply forgetting to commit their changes or not understanding the drafts widget. Since this measure is on the DevForum where users (hopefully) have some higher level of experience with Studio, it stands to reason that a lot of developers who don’t use the forum are getting confused about this too.

I’m paying attention to see if this number grows after Collaborative Editing becomes enabled by default. I’ll let people know if this happens.

Currently, the drafts widget design does not clearly communicate important information.

When I start working in a script I tend to have tunnel vision on either my keyboard or what I’m typing onscreen, so I don’t notice the Drafts window opening automatically sometimes, and nothing about the widget’s interface communicates to me that I have pending changes that must be committed.

For example, what does “Saved” mean? To someone unfamiliar with the term “commit”, this suggests that nothing else needs to be done, but to those familiar with the term, it’s shown nowhere on screen and there’s no obvious indicator that a commit must be done other than the fact that the script exists in the widget, which does not communicate what needs to be done clearly enough.


I’d suggest adding a redundant “commit” button into the line item with an eye-catching color that changes into a grey confirmatory icon when clicked to commit changes. This would move the action the user needs to take somewhere visible and convenient and provide visible, reassuring feedback. Giving this button a “Commit changes” tooltip would further help improve understanding.

Also, to address one of the big pain points of Collaborating Editing (needing to commit changes all the time), maybe consider adding a toggleable setting that automatically commits non-conflicting/non-merging script changes when scripts are closed. This would enable behavior similar to old TC script editing, which would help old TC developers adopt this feature.

I think this alone would be a pretty substantial QoL improvement.