Depends on what you want.
Create three tables (contestation, replica, treplica)
This allows for the insertion of various contests, replicas and rejoinders for each note (which I believe is not your goal). The control by the system is greater, since there are 3 tables, and if it is the case to bring the records in a single query, can force the system to make use of Unions, which is not good for performance. Great for cases where it is interesting to access only one table of each type at a time.
Create a table with the 3 fields
For the business scope, I believe it is the most appropriate, considering that each note can have only one contestation, a replica and a rejoinder. It is also the simplest to obtain and update, but it does not serve for multiple records of challenges, replicas and rejoinders.
Create a table with the type field
This case is interesting when you want to save in number of queries and minimize the amount of joins used by the system. It is also for the case that your system allows a variable amount of challenges, replicas and rejoinders. You may need to add an index by type, which makes the table larger in the database.
The answer from the colleague is very good. I am not in favor of creating three tables because they would probably have the same related tables. Creating a TYPE field is interesting. Increasing the size of the base nowadays is no problem considering the price of the Storage. I also suggest creating a field (PARENTID type) to relate the original note to its replica and the replica to the rejoinder etc or (if there is recursion problem with it) you could have a relationship tables of notes x notes
– jean