The comment schema defines a record of discussion events (e.g. "User A added a comment at line B").
The schema as it currently stands can encode two types of events:
A user adding a new comment
A user responding to an existing comment
We might want to also provide a way to represent an edit event; where a user modifies an existing comment.
I do not think that support for updating a comment needs to be added to the command-line surface, as I imagine that user experience would be rather clunky. However, supporting it in the schema (and making the CLI display such comments properly) would make it easier to support comment editing in user experiences that can support it well (such as GUIs).
The simplest approach I can think of is to add an original field to the schema that would be similar to the parent field. That would specify that the comment is an update to the specified, prior comment.
We could also use this event to represent removing a comment, by having all of the fields other than original being empty.
When building the CommentThread objects, we would include all of the versions of a comment, but only display the last one. That would allow the user to still see all versions of a comment by displaying the JSON format of the review.
This would be very similar to the current support for updating a review request.
The comment schema defines a record of discussion events (e.g. "User A added a comment at line B").
The schema as it currently stands can encode two types of events:
We might want to also provide a way to represent an
editevent; where a user modifies an existing comment.I do not think that support for updating a comment needs to be added to the command-line surface, as I imagine that user experience would be rather clunky. However, supporting it in the schema (and making the CLI display such comments properly) would make it easier to support comment editing in user experiences that can support it well (such as GUIs).
The simplest approach I can think of is to add an
originalfield to the schema that would be similar to theparentfield. That would specify that the comment is an update to the specified, prior comment.We could also use this event to represent removing a comment, by having all of the fields other than
originalbeing empty.When building the CommentThread objects, we would include all of the versions of a comment, but only display the last one. That would allow the user to still see all versions of a comment by displaying the JSON format of the review.
This would be very similar to the current support for updating a review request.