The definition of comment is incorrect, I believe. All initial responses to a topic are indented once. Only the actual topic-starting text is not indented.

To illustrate this, here's some annotated source I copied from Help_talk:Talk_pages.

Technically our data model treats the text of the topic as just the first comment. You can see this with dtdebug=1:

In T284200#7152688, @DLynch wrote:

The definition of comment is incorrect, I believe. All initial responses to a topic are indented once. Only the actual topic-starting text is not indented.

@DLynch before traveling further down the path of revising the definitions I proposed in the task description, can you share how you think about these two questions?

1. What about how the software is currently written would constrain our ability to answer these questions?
   • A) "For all comments and new topics, how much time, on average, elapses between when someone posts on a talk page and another person responds?"
   • B) "For all comments and topics posted after a certain date, what percentage of said "comments" and "topics" receive a response from another person within __hours/days?"
2. What – if any – changes could we make to help us more accurately/complete answer "A)" and "B)" above?

1. What about how the software is currently written would constrain our ability to answer these questions?

For both of these, we're not currently storing data in a way that would be helpful. Technically all this is present in the echo_event table, but relating the initial topic-event to the reply-event would be challenging (there's a comment-id and parent-id stored, but it's in the JSON-blob part of the echo_event row). It could also be extracted by analyzing the wikitext on the page at any given moment.

2. What – if any – changes could we make to help us more accurately/complete answer "A)" and "B)" above?

We should probably implement some logging to a schema. We can do logging at the same time as the echo_event rows are created, just sending the data in a more convenient fashion for us. We could directly store a time-since-parent-comment value, if you don't mind us trusting what the wikitext says about the parent's timestamp. (If not, @MNeisler could presumably look up the logged row for the parent -- assuming that we're doing 100% logging and not sampling.)

On the definitions:

• What you called "direct response", I would call "reply"
• What you called "comment", I would call "top-level comment"

That's how I described the structure in the recent doc page: https://www.mediawiki.org/wiki/Extension:DiscussionTools/How_it_works#Data_structures

Ok, I want to parse out – what I see as – the two open threads we have open in this ticket:

1. Definitions: converging on semantic definitions for each of the unique elements/components of a talk page conversation that make up its structure
2. Implementation: deciding on the approach for storing said "talk page structure"

Note: to avoid confusion and simplify this task, I've revised the task description to describe the behavior being asked for more generically; I've also removed the DEFINITIONS section.

1. Definitions

In T284200#7188117, @matmarex wrote:

On the definitions:

• What you called "direct response", I would call "reply"
• What you called "comment", I would call "top-level comment"

That's how I described the structure in the recent doc page: https://www.mediawiki.org/wiki/Extension:DiscussionTools/How_it_works#Data_structures

This is a big help, @matmarex.

Can you comment what – if anything – is inaccurate and/or incomplete about the two statements below?

• NO changes need to be made the current Data structure to satisfy the task description's ===Requirements.
• In order to expose the number of comments within a conversation, we will likely need to extend the current Data structure to include a third "item", topics. Although, the work to implement this change does NOT need to happen as part of this task. Instead, it can happen as part of T269950.

2. Implementation

In T284200#7160082, @DLynch wrote:

1. What about how the software is currently written would constrain our ability to answer these questions?

For both of these, we're not currently storing data in a way that would be helpful. Technically all this is present in the echo_event table, but relating the initial topic-event to the reply-event would be challenging (there's a comment-id and parent-id stored, but it's in the JSON-blob part of the echo_event row). It could also be extracted by analyzing the wikitext on the page at any given moment.

Understood.

2. What – if any – changes could we make to help us more accurately/complete answer "A)" and "B)" above?

We should probably implement some logging to a schema. We can do logging at the same time as the echo_event rows are created, just sending the data in a more convenient fashion for us. We could directly store a time-since-parent-comment value, if you don't mind us trusting what the wikitext says about the parent's timestamp. (If not, @MNeisler could presumably look up the logged row for the parent -- assuming that we're doing 100% logging and not sampling.)

@DLynch + @MNeisler: regarding actually, "...implement[ing] some logging to a schema..." does the below seem like the right order of operations to y'all?

1. Converge on shared definitions for the components of the conversation we are wanting to track.
2. Agree on/acknowledge any "lossyness" we may need to accept between how we'll have semantically defined the components of the conversation and what we'll be able to codify (read: represent in the software)
3. Design the schema that will store the talk page structure we'll have specified in the preceding steps
4. Implement the schema
5. QA the schema/event logging