Welcome to the Judaism community on Codidact!
Will you help us build our community of learners? Drop into our study hall, ask questions, help others with answers to their questions, share a d'var torah if you're so inclined, invite your friends, and join us in building this community together. Not an ask-the-rabbi service, just people at all levels learning together.
Post History
Comments are meant for requesting more information or clarification, pointing out issues to be addressed in an edit, and other things that lead to improving the post they're attached to. As we've ...
Answer
#1: Initial revision
Comments are *meant* for requesting more information or clarification, pointing out issues to be addressed in an edit, and other things that lead to improving the post they're attached to. As we've seen on pretty much any web site that enables comments, though, what designers *intend* and what users actually *do* can vary. Here is what we wrote in the [functional specification for 1.0](https://github.com/codidact/docs/wiki/Functional-Specification) (which we have not yet reached): > Questions and answers can have comments.[^1] > > Comments are threaded. There is a way to see what a reply is a reply to, and there is a way to reply to an existing comment. > > A maximum of TBD number of comments is shown by default. If there are too many comments to show, priority is given to comments that begin threads (with an indicator that there are more, e.g. "(N replies)" after the comment text). > > Comments support a subset of CommonMark to be specified. (Basic text formatting yes, tables and embedded images no...) > > [Comment use cases](https://github.com/codidact/feature-development/tree/master/scoped/comments) (includes muting notifications on your post/thread and archiving threads) Comments will be flaggable but that's not implemented yet. For now you can flag the post and describe the problem. Sorry, I know that's not ideal. We don't have plans to support voting on comments. If we have upvotes then we also need downvotes, and that leads to a cluttered interface when you think about the sizes of comments compared to the sizes of (votable) posts. On SE, comment voting was meant to help people find key points in a vast sea of comments; we think that collapsing comment threads will address that need. If it doesn't we'll look at it again; (non-)voting on comments isn't carved in stone, but we'd like to see the need before deciding to do it. We don't want comments to become mini-posts of their own. By the way, because we'll have threaded comments we can also *group* comments. I envision all comments attached to close votes to be grouped in one thread for easy review. (In the designs I've been working with, all close reasons can accept comments; you'll get the textbox right there alongside the choice of reasons.) [^1]: This text predated the introduction of articles. They get comments too.