markvanlan

We don’t want this to be a user’s decision or preference. It’s up to the administers to decide how their site should function. The two paradigms are very different and users shouldn’t be interacting so differently on the same content. That’s our current thought at least.

If it were my community I would test in isolation first. On the other hand we would get more valueable feedback faster by you enabling for your whole community :wink: . Jokes aside, I do think testing in isolation is probably smart but there is no destructive data migrations here. It can be enabled and disabled safely. No decision you make here will lock you in either direction.

I guess I sorta accidently answered this part! Enabling nesting simply creates a nested_topic record for each topic in the DB and kicks off a job to calculate reply counts down the ancestry tree. Disabling nesting removes that nested_topic record and you’re back to flat, no issue.

Feel free to play with it in this category:

Yes I do agree with you. This is a limitation for now, and something we will absolutely keep thinking about.

The big reason why I chose not to convert historical topics in a category when it is enabled, is that users are likely going to interact differently. In flat mode, the various Reply buttons don’t matter as much. The post is going at the bottom of the topic. I’m not sure users always intentionally press the “right one” that would translate to the nested view.

Basically I worry that admins will enable it for historical topics and then suddenly the conversation is unreadable. We’ll keep thinking about it. The easiest change I can think of is when the category setting is toggled, we have a modal popup saying “do you want to apply this to existing topics?”

Yep, toggling is an option for bulk actions :slight_smile: