Maybe split the engines dsicussions out of the API forums. Currently, you really need to read the description to see that engine specific discussions should go into the API and tools forum.

This is along the lines of what I'm thinking. We certainly have a place for engine discussions, but it's not obvious. Maybe a little reorg/rename is in order.

Well, what advantage would there be to split "Engine" specific API discussion out into its own section, rather than just making things clearer to people to use the existing API section for "Engine" stuff?

So just to fill in guys that aren't from the Unity board..

They used to run XenForo and it was really solid. They wanted to interconnect more site features so they licensed Lithium. They made the Xenforo forum read-only and fired up the Lithium version a few days later after migrating the databases.

Well unfortunately the migration was a complete disaster. Swathes of posts disappeared, no PM's migrated, no thread subscriptions migrated, the default layout is unanimously abhorred by the entire community, and lots of other problems/complaints. Essentially they went live with what appears to be a completely untested system after the first pass at data migration.

No one likes it, no one is happy and they're currently trying to communicate with Lithium but its all across the pond so time zones bork any kind of rapid scheduling and its taking forever to get solutions on what is involved with rollback etc while leadership is in SF, the forum team is in Coopenhagen and Lithium guys are somewhere else I think.

So while that basically leaves most users trying to avoid the forums now, I wouldn't expect loads of people to shift over to a generic forum with a single section for Unity because it will never compare to the quality, convenience, integration and 'officialness' of the legacy XenForo Unity forums. For myself, I just got a color inverter so I could read the text but all I post there for now is to update my asset threads.

This is fascinating to me. I love learning from the mistakes of others.

I would consider this to be a significant deployment and roll out failure due to insufficient testing. With the way you describe it, it sounds like their sysadmin just did a database migration, didn't check to make sure everything migrated perfectly, assumed it was all good to go, turned one system on and the other off, and felt the blowback when people lost data and capabilities.

It sounds like the cross system compatibility capabilities they were looking for sounded like a solid business case which benefits them and customers, but they botched the execution of it. Now, they face a public support crisis and the project is tainted, so if they try again in the near future, people will bring their bad memories of the last failure and be opposed to the change. Fascinating. This is why you can't screw up your deployment and integration step. There's always going to be a subsequent user training step in the SDLC which generates user resistance, but deploying an 80% solution is going to multiply your end user resentment, no matter the validity of the business case.

The interesting question to follow up with is, "How could this have been done better?"
"Move fast and break things" is the wrong policy approach here. I think if they could migrate the data from one database to another, there is no reason they couldn't run two instances of the forum software. Let the new instance be publicly accessible. Let people vet it before you go live with it. Mirror the data from the production database to the staging database on a 24 hour cycle. Let your engineers figure out how to build the interconnected services. When everything is working smoothly, make the staged software the production version, and then set the current production version to a hot spare which gets its data synched from the new production instance. If there's an unexpected catastrophe, you have an immediate go back plan. I would set the deployment and integration cycle for this forum software roll out at something gradual like 6 months.

When it comes to user training, people like familiarity. Your forum UI is like a brand, and when you change a brand, you don't want to change it more than 10% from what it was previously. If you want people to adapt to your new systems, adapt the new systems to look and behave like the systems they're familiar with, and then gradually and incrementally, add additional capabilities.

Anyways, all of this is a heavy mix of policy and technical work working together. Surely a company as big as Unity, with the capabilities to build the worlds leading game engine, has the technical capabilities to handle this phased deployment of forum software.

I want to hold a referendum. Its obvious the lounge has suffered greatly from gamedev.net's mismanagement of inmigrants, allowing them to walk freely into the union, without ever contributing anything back. I say the Lounge does not need gamedev.net, neither it needs to support its less populated subforums, that have been stagnant for not accomodating to the latest dank memes, unlike the Lounge.

I vote for making the Lounge great again.

Age you beat me to it!

We are going to build a Firewall and we are going to make Unity pay for it! They are bringing bad posts and they are bringing spam! We need a temporary ban on all Unity refugees until Unity figures out what it's doing over there!

Lol jokes aside welcome guys! I'm a huge Unity dev myself! Sad to see the forum destroyed like that.