Hi Lindsey,

I understand your point of view, but let me explain why I think disabling this feature (or any other) could be useful at least until it is tested long enough to see it is stable and very few issues are reported if any.

This feature does not only affect the user who is writing their post, although they could indeed fix any issue before posting their message assuming they find a solution to post it correctly.

I think some users don’t even notice that they are in Rich Text mode. I didn’t notice it when I first started to write my previous bug report here. I’m not saying it is not noticeable, but when you don’t need a lot of formatting, it could look like any text. The asterisk (*) character could be confused with a bullet point in a rendered HTML on some screens, so users work on a long post, realize something was broken, switch to Markdown and could make it worse (as I noticed yesterday and mentioned in Rich Text editor in topics breaks white-space characters in multiple ways).

Then they don’t want to spend a lot of time on fixing their post so just send it hoping it will be understandable.

Then moderators, helpers work more to understand the question, ask the users to fix their post, explain to them that they should not use the Rich Text mode when sharing code. It means a lot of extra communication and time instead of helping, while we are waiting for fixed code blocks. It matters on a forum where most of the posts contain some kind of code blocks or if not, they should, but users were not familiar with Markdown (which was surprising to me, but this is the reality ). So the Rich Text editor could indeed be a great addition, and this is how we looked at it first even though I would still prefer Markdown, but why not let other users choose what they like. So yes, I agree.

But in some cases, moderators, or admins have to decide whether a feature makes more problems than it solves, so I believe they should be able to disable it temporarily until the feature is stable enough to activate again. Users coming for help will not necessarily know which editor mode is best for them, when they don’t know about the bugs.

Now I wouldn’t think of trying to disable the “bold” or “quote” buttons as these buttons do very little and it is very easy to notice if something is wrong. But I see that there were multiple reports about the Rich Text editor. It is a potentially great feature, but can also break a lot. People also had problems with MarkDown, but that is okay, we already know and can handle it as we did before.

In some cases moderators try to help with formatting and not just linking a formatting guide, but also fixing the message for them. It can be useful especially when they would not have time to fix their own post as new users or the one day already passed since they sent the message. If the Rich Text mode is not stable, I can imagine editing their post and breaking it instead of helping.

So I totally get the intention of letting users decide what they want to use to write their post, but there is another side of it. The fact that users might not know which editor they want or what issues they will cause, and they just make a lot more work for moderators and also get a bad experience on the forum which could have been solved by temporarily disabling the feature.

I read about the CSS-based solution. The problem is even though we use CSS for customization, I also know that CSS could also break things so I try not to use CSS unless absolutely necessary. This way I can avoid the feature appearing again after a Discourse upgrade or when someone adds an extra CSS for something unrelated not noticing that it breaks disabling a feature.

I hope I could describe it clearly enough

update:

When I came back after a notification, I realized I did not write about the exact same thing as the OP, but I believe the main point remains the same: I can imagine forum admins want to disable some features if that causes lot of problems. Whether it is MarkDown or Rich Text or the ability to switch between them after starting a post is less important.