I just thought a bit about the differences between Stack Exchange, TopAnswers, and what we are striving to build, and then it occurred to me that there is a very general theme hiding in it.
First, consider Stack Exchange. There are three post types: questions, answers and comments. And for reasons that I hope will get apparent later, I’ll treat the title question not as integral part of the question, but as a separate entity.
So what is the difference between a question and an answer? Well, the answers belong to the questions. So we have a single-level tree with the question as parent node, and the answers as child nodes, So what is the parent of the question? Well, since I treat the title as separate entity, it makes sense to treat the title as parent to the question. Note that fundamentally, there’s no fundamental difference between a question and an answer, other than their position in the hierarchy.
You may argue that a question also has tags, which the answer doesn’t have. But then, one might argue that the tags could also logically be seen as attached to the title.
Now to the comments. The comments are attached to a question or an answer. Now apart of how they are displayed, how do comments differ from questions and answers? Well, they have a lower maximal length, and only a subset of Markdown is interpreted for them. But other than that, it’s again just a post with a single parent, but no children
So for Stack Exchange, we have s simple hierarchy: The title is at the top. A title has a single, mandatory question as child. A question has a title as parent, and any number of comments and answers as children. An answer has a question as parent, and any number of comments as children.
Now in Codidact, we want to have threaded comments. So what changes? Well, not much; just that comments may have children, which are other comments.
OK, let’s look at TopAnswers. Note that this is not about how things are actually implemented there (that I don’t know), but just abstractly thinking about what is presented to the user.
TopAnswers doesn’t have comments, but a chat. Apart from presentation, how does the chat differ from comments? Well, as far as I can tell, they are not attached to another post, but they are related to a specific question. So I’d say a chat message is like a comment, but attached directly to the title.
There are also global chats, that are not attached to a question. Those are in chat rooms which have their own names. But what is a name, if not a (very short) title? So those chat rooms are just titles which have only chat messages as children.
Also, on TopAnswers there are blog post. Blog posts differ from questions only in that you cannot answer them.
Let’s look beyond those sites, to no-Q&A-sites. For example the forum I’m writing this on, Discourse. Again, we have topics, that is, titles, and long posts that are attached to that title. Except that now we have several posts attached to the title, and posts can also have arbitrary other posts as parent.
So in summary, at least from the view of the back-end, all the posts are fundamentally divided into just two types: Long posts, which have all the features of Markdown available, and short posts, which have a much lower maximal length, and have only a subset of markdown features available.
Every post type (question, blog post, forum, chat room) has its own rules which type of post can be attached to which other type of post. Under each title, there’s only one type of hierachy, so it makes sense that the title comes with a type that fixes the rule for posts under this title.
Long messages attached to titles are questions, blog posts or forum messages, depending on the title type. Long messages attached to other long messages are answers or forum replies, depending on the title type.
Short messages attached to titles are chat messages. Short messages attached to long messages or short messages are comments.
So in summary, we get an uniform model that, at least in the back end, gives us everything from a chat room to a full Q&A site.
Of course the front end needs to do different things for each of them, so we don’t get the full range of page types for free. But I think adding a new one should get much easier, if the only thing that has to be written is the front end code, and new database entries laying out the hierarchy rules for the new type of page.