In recent times, many deprecations and changes to legacy features on the Roblox platform have been met with widely negative pushback from the community. Often, this is because the teams responsible for the changes have not accounted for some detail that the community strongly values. While there have been greater efforts to incorporate community feedback and developer review into the process via dedicated Developer Relations processes, this has clearly still not been sufficient to ensure that the critical details to get right are communicated to the teams who need to know this information before making executive decisions about the direction of legacy features.
Attempting to objectively evaluate this state of affairs, the conclusion I have come to is that it instead seems wiser to take advantage of the community feedback being publicly posted in these threads as part of a revised deprecation process. I have conviction that this will allow for a smoother transition that respects the wishes of the community to continue using legacy features, while allowing new features to be rolled out widely to users and be polished and refined to the level at which they become acceptable substitutes for the legacy features that they replace.
Case study
To better illustrate these words, I would like to first point to the recent announcement regarding dynamic heads.
Please keep in mind that this is not the focus of the post, but merely a case study - I intend to use this as an example of a currently inadequate deprecation process.
Community sentiment is that the new heads are not sufficiently similar to act as a substitute for the legacy face textures that they are designed to supersede:
One of the primary points of contention that was not later addressed by the staff reply was the issue that legacy faces were being taken off-sale in the Marketplace whenever a new Dynamic Head was rolled out to supersede it. The community felt that this deprecation and removal of legacy faces from the public-facing Marketplace was too early considering the product they were receiving as a substitute.
The reason why the community does not like this, to be clear, is that the new heads are not considered by the community to yet be polished and featureful enough to stand in as a like-for-like substitute for the legacy faces. If the visual representation of the legacy face were virtually identical between the two, then it would be far easier to accept the transition. As it is, these face types are not even compatible between different head shapes - reducing axes for user expression - let alone enough of a visual match for the face they are replacing even on the ideal head shape.
The key here is that this is a community sentiment. It simply does not matter if Roblox have internally determined they are fungible, because this assessment does not reflect whether the community is willing to accept the change. The current deprecation process relies on internal determination rather than community sentiment to decide when a legacy feature is to be phased out.
In defense of internal determination
Before detailing why I believe community sentiment is the right metric to measure here, I would first like to acknowledge a shortcoming of relying on community sentiment for determining the end date of legacy features.
It is true that it may be difficult to move past legacy features for which the community has a specific affinity for, regardless of fitness for purpose, technological roadblocks, etc. I have reason to believe that this is a motivating reason for Roblox to sometimes decide to act against common sentiment; for example, perhaps before many people’s time here on the DevForum, this is how Roblox had to handle the rollout of FilteringEnabled which ended up disrupting huge portions of Roblox’s back catalogue of experiences.
I acknowledge the existence of this problem. It can sometimes manifest as non-actionable responses (which some people colloquially call the ‘change bad’ response), which I understand is hard for internal teams to take away and do something productive with. However, I think that this phenomenon is not necessarily completely unproductive, as it helps to highlight the areas in which Roblox should pay much closer attention to ensure newer features can preserve aesthetic, function and utility of legacy features precisely, to the accuracy the community is concerned with.
In short, I believe that difficulty sunsetting or deprecating legacy features most often indicates that a community need has not been addressed to a sufficient level of quality that the community can accept. While it may not be possible to always satisfy this need for technological reasons, I believe nonetheless that the best outcomes for both parties is reached when these needs are best reconciled via collaboration.
An actionable feedback-driven deprecation model
I would now like to specifically outline actionable steps that can be employed in future to effectively manage community sentiment against technological or corporate needs to move beyond legacy features.
It is a three-stage model directly inspired and informed by previous successful migrations, such as the multiple features added to Roblox Studio over time, or the ongoing migration between R6 and R15. These migrations and deprecations have proven to be effective, successfully counterbalancing initially sceptical community sentiment and eventually bringing most developers on board in an amicable way.
Stage one is to merely introduce the replacement feature without disturbing the legacy feature. Allow both features to coexist completely peacefully. The observation this is based upon is that, more often than not, replacement features are not perfect upon first release to the public, and the community will likely point out several themes and points for improvement. For this reason, this is not yet the time for deprecating anything. Instead, it is a time to gather feedback, evaluate sentiment, and figure out what the path forward looks like for this replacement feature.
Stage two is an iterative process. Once the initial sentiment has been evaluated, an ongoing process may begin where community feedback is incorporated to improve the replacement feature. Specifically, an eye should be cast towards the places where the replacement and legacy feature are divergent. Where do the community feel that the two features do not match? Do these mismatches matter to the community? How does the community envision these problems should be solved? Can any concrete end goals be extracted from this, against which performance can be measured? The community should be kept in the loop and iteration should extend for as long as necessary, until the broad consensus has been reached that the replacement feature has been polished to a level where it can serve the same purposes as the old feature, hard technological limits notwithstanding.
Stage three is the ultimate deprecation and removal of the legacy feature. It is important not to rush this! The replacement feature must be deemed by the community to be ready as a substitute, or otherwise there will be significant blowback as demonstrated time and time again. The deprecation of legacy features is more than simply a product affair; it can also be a personal sacrifice for community members. This is why empathy, clear signalling, advance notice and continual integration of community sentiment is paramount. There will most probably be at least a minute level of discontent around any deprecation or removal, however it is important to remember that any non-insignificant discontent indicates that stage two of the process may not have been extended to run for long enough to appease community concerns.
To summarise in simpler form:
- Stage one introduces the replacement feature alongside the legacy feature without any sort of removal. Within this environment, the community is introduced to the feature without any associated threat.
- Stage two works to bring the two features closer together to minimise any different in user experience. Within this environment, the community is tightly integrated to help direct the evolution of the feature to encompass its final goals.
- Stage three works to tactfully, carefully and respectfully sunset the legacy feature only once the community have had the time to understand the new feature and shape it in the image of what they desire to use it for.
The benefits to investors & shareholders
By actively executing on a tight feedback loop with the community, and more successfully sunsetting legacy features, Roblox will demonstrate to investors and shareholders that, in every new feature they ship, they are capable not just of flashy headlines, but also are dedicated thorougly to ensuring the highest level of quality is possible, and that they have the full force of their community proving socially that Roblox’s features are successfully serving the needs of real people and communities around the world.
The benefits to Roblox staff & engineering teams
The modern-day announcement post is often riddled with emotional or non-actionable responses of an accusatory nature. Understandably, Roblox staff often cannot do anything with this information, and as a result, it becomes much easier to lose the posts that can help better direct the internal teams towards more successful feature launches and reshaping. By taking the long view and allowing for extended iteration to occur before deprecation and removal, internal teams are better positioned to receive the feedback that they need in a more constructive and actionable form, such that the velocity of iteration can be expedited and focus clarified on internal roadmaps about how best to address the issues of today’s Roblox.
The benefits to the Roblox developer community
Community members are often not opposed to the principle that Roblox benefits from updating outdated features to match modern desires. The primary point of contention has always been that changes increasingly seem to not live up to the community’s quality expectations. By employing this integrated approach to feature iteration, the community is given a more direct chance to voice their concern about any divergence they perceive, and ultimately to work alongside all talent at Roblox regardless of experience level to reconcile what the company envisions with how the community believes that vision can fit into their user story, so that they can continue enjoying Roblox in the ways that reflect them best.
In summary, I believe that adopting a three-stage deprecation process for all legacy feature removals going forward would best ensure the needs of all involved parties are met to a satisfactory degree, cutting down on inefficient lossy integration of feedback and improving the velocity and quality of feature iteration and ultimately executing on the delivery of higher quality results.