you know you can upload images to the ticket itself (much easier to see and also won't get lots when image hosts go down)
but no. I really don't like that, having it as an optional "ad-on" sure. but default-wise I think doing it exactly like the mb is the way to go.
I know I'm biased here, but "rich text editor" will just create loads of bogus html/whatever in the text - like if I paste an url it encodes it as [url=http.example.com/]http.example.com/[/url] or something. I dislike that immensely.
Like the mb example, having the actual formatting on-page is useful. That way it's easy to see what does what. Also, initially, most of our users are from MB anyway - we also have some from the now defunct bookogs. Eventually we'll have more casual revisioners, so probably not a bad idea to enable an ability for an "add-on" later, but for now, just a simple text area that respects spaces/tabs and wikimarkup is what we need.
I would strongly suggest to go with some basic Markdown (CommonMark would be a good target) to begin with. See the discussion on OTHER-77 for what has currently been explored. Yes, this won’t be everything that CQ wants (sorry), but MB’s mediawiki-like annotation markup isn’t that used in the grand scheme of MetaBrainz things. CritiqueBrainz, forums, GitHub, and documentation all use some Markdown flavour or other and per OTHER-77 Markdown is generally the direction we want to move towards. Implementing something other than Markdown now will almost surely mean that we already know we’ll have to figure out how to migrate Soon™ as well.
Also, IME, WYSIWYG editors for Markdown and similar don’t have the same problems that HTML ones have, where you get a jumbled mess of markup code in the result.