Moving to upcoming work for a next sprint. Good questions in here for @kostajh, @Catrope, and @SBisson to think over and post comments.

and perhaps we can obscure page_id and page_title.

Can we just redact it? If you need the same type of obfuscation logic we use for EditorJourney, then this could become complicated.

@kostajh -- I think it would be fine to redact instead of obfuscate. I don't imagine that we will care to know whether a newcomer is repeatedly opening the help panel on the same page. We would also be letting go of knowing on which help pages the newcomers open the help panel -- but we can use EditorJourney to know that for the first 24 hours. @nettrom_WMF, what do you think?

@MMiller_WMF : We should document the questions we have around this variation, similarly as we did for search. I think at this point, my main interest is behaviour across namespaces, in other words: how do users who see the help panel in the Help & Wikipedia namespaces differ in behaviour from those who see it when editing? We'll be able to answer that because we track the page namespace. While it might be interesting to know if certain pages are more likely to lead to questions being asked, I suspect we might also learn about that from the questions that are asked? It could also be something we consider looking into if we start seeing questions flow in.

Aside from that, we're already able to determine if someone opens the help panel multiple times on a page because all interactions will have the same help_panel_session_id, that is set on page load.

Thanks, @nettrom_WMF. So it sounds like you are okay with not capturing the page_id and page_title for the Help and Wikipedia namespaces in reading mode. We'll talk this week about updating our experiment plans.

@kostajh -- what should we do with the editor_interface field?

what should we do with the editor_interface field?

Storing reading there seems OK but not great. We could consider a new property on the schema like impression_mode and set that to "edit" or "view". @nettrom_WMF do you have a preference?

In T215664#4955259, @kostajh wrote:

Storing reading there seems OK but not great. We could consider a new property on the schema like impression_mode and set that to "edit" or "view". @nettrom_WMF do you have a preference?

We have the action_data property, which I think does not contain anything when action=impression. Could that be used to store this type of information? That way we don't need to add a property, but with the drawback that it is not stored for all events. I'm unsure if we'd prefer to store the interaction mode (view/edit) with every event or not. Storing it everywhere makes it easier for me to analyze, but it also means we'll likely add a property.

FWIW I think something like editor=reading is not bad since all the values (ve, wikitext, reading, etc) would be mutually exclusive.

A new field like impression_mode=edit|view would still need a new editor option (N/A) which would be 100% redundant with impression_mode=view.

Change 491864 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Help Panel: Show in reading context on selected namespaces

https://gerrit.wikimedia.org/r/491864

Let's go with editor_interface: reading for view mode, sounds OK?

I think that decision belongs to @nettrom_WMF. Let us know!

@nettrom_WMF here's an example event:

{
  "action": "impression",
  "action_data": "",
  "user_id": 1,
  "user_editcount": 127,
  "editor_interface": "reading",
  "is_mobile": false,
  "page_id": 0,
  "page_title": "",
  "page_ns": 12,
  "user_can_edit": true,
  "page_protection": "",
  "session_token": "ac0bc60ed5b559989816",
  "help_panel_session_id": "97487760b5c4b4519e76"
}

Note that page ID has to be an integer, not omitted entirely, so I've set it to 0. Let me know if that should be something else. For page title, I set it to an empty string, but I could make it some other value if you prefer.

@MMiller_WMF should we include the talk namespaces for Wikipedia and Help as well?

@kostajh -- yes, the talk namespaces should be included.

In T215664#4973639, @kostajh wrote:

@nettrom_WMF here's an example event:

{
  "action": "impression",
  "action_data": "",
  "user_id": 1,
  "user_editcount": 127,
  "editor_interface": "reading",
  "is_mobile": false,
  "page_id": 0,
  "page_title": "",
  "page_ns": 12,
  "user_can_edit": true,
  "page_protection": "",
  "session_token": "ac0bc60ed5b559989816",
  "help_panel_session_id": "97487760b5c4b4519e76"
}

Note that page ID has to be an integer, not omitted entirely, so I've set it to 0. Let me know if that should be something else. For page title, I set it to an empty string, but I could make it some other value if you prefer.

This all looks good to me. Having editor_interface: reading makes it easy to identify those. For page_id and page_title the values are perfectly fine. They should both be values that I can use to filter on if necessary, and they're not meaningful values (i.e. there is no page with page ID 0).

@MMiller_WMF I'm ready to merge Kosta's patch for this. If I do so, it will roll into production with the train next Thursday. Are we ok with that?

(i.e. there is no page with page ID 0).

@nettrom_WMF just noting that, when the help panel is loaded in the context of creating a new article, page ID will be 0. Of course you can filter these out by looking at page_id=0 AND editor_interface='reading' but just wanted to note it. For reading context, I could set page ID to -2 or some numeric value you'll know means it was redacted, just let me know.

In T215664#4974525, @kostajh wrote:

@nettrom_WMF just noting that, when the help panel is loaded in the context of creating a new article, page ID will be 0. Of course you can filter these out by looking at page_id=0 AND editor_interface='reading' but just wanted to note it. For reading context, I could set page ID to -2 or some numeric value you'll know means it was redacted, just let me know.

Thanks for catching that! I'm happy to keep what we have now, no need for additional work on your end.

Change 491864 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Help Panel: Allow help panel to show in reading mode

https://gerrit.wikimedia.org/r/491864

Checked in betalabs - the Help panel is displayed in Help and Wikipedia namespace. All Help functionality is in place.

I tested this in Test Wiki and things work as expected.

But something just occurred to me -- we are going to show this feature in the Help and Wikipedia namespaces because we know that newcomers spend time there, and that if they're there, they are probably trying to figure out how to edit. By that logic, maybe we should also be exposing it in the User and User Talk namespace, which we also know are places newcomers spend time (especially in their Sandbox). Let's think about that for a minute.

We talked about this with the team briefly -- we want to also add the User and User Talk namespaces. Moving this back into "In Progress".

Just adding a comment to document that since we're also planning to soon add User & User talk, I'll regard the timestamp of that going live as the start of experimentation with additional contexts.

@MMiller_WMF should we also enable it for Talk namespace on articles? If someone's looking at a talk page, they may also be interested in editing.

Change 493615 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[operations/mediawiki-config@master] GrowthExperiments: Enable help panel for user and user talk NS

https://gerrit.wikimedia.org/r/493615

Change 493616 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[operations/mediawiki-config@master] GrowthExperiments: Enable help panel for user and user talk NS

https://gerrit.wikimedia.org/r/493616

Change 493615 merged by jenkins-bot:
[operations/mediawiki-config@master] (Betalabs) GrowthExperiments: Enable help for user / user talk NS

https://gerrit.wikimedia.org/r/493615

Change 493632 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Help Panel: Exclude from main page

https://gerrit.wikimedia.org/r/493632

We will not be enabling the panel in the article talk namespace. So to sum up, in this task, we are extending the help panel to be available in the reading contexts in these namespaces:

• Help
• Help talk
• Wikipedia
• Wikipedia talk
• User
• User talk

I will change the description to reflect this.

Change 493632 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Help Panel: Exclude from main page

https://gerrit.wikimedia.org/r/493632

Change 493616 merged by jenkins-bot:
[operations/mediawiki-config@master] GrowthExperiments: Enable help panel for user and user talk NS

https://gerrit.wikimedia.org/r/493616

Change 494297 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@wmf/1.33.0-wmf.19] Help Panel: Exclude from main page

https://gerrit.wikimedia.org/r/494297

Checked in testwiki - works as expected.

@MMiller_WMF Should we also add Help panel to the pages that mobile redirects when people clicked on 'Discussion', 'Talk, or 'Add discussion' ? See the examples below:
Mobile web has a different arrangement for Discussion places/pages(?). For example, https://test.m.wikipedia.org/wiki/Wikipedia_talk:Administrators will have Help panel, but clicking on 'Add discussion' will redirect to https://test.m.wikipedia.org/wiki/Wikipedia_talk:Administrators#/talk/new which won't have Help panel.

https://test.m.wikipedia.org/wiki/Wikipedia:Administrators clicking on 'Discussion' will take to https://test.m.wikipedia.org/wiki/Wikipedia:Administrators#/talk - the Help panel won't be there.

User pages will have prominently display 'Talk' link which takes to e.g. https://test.m.wikipedia.org/wiki/User:Zilant17#/talk and the Help panel won't be displayed there.

Change 494297 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.33.0-wmf.19] Help Panel: Exclude from main page

https://gerrit.wikimedia.org/r/494297

Mentioned in SAL (#wikimedia-operations) [2019-03-05T00:17:31Z] <catrope@deploy1001> Synchronized php-1.33.0-wmf.19/extensions/GrowthExperiments/includes/HelpPanel.php: Exclude help panel from main page (T215664) (duration: 00m 48s)

Checked [mediawiki/extensions/GrowthExperiments@wmf/1.33.0-wmf.19] Help Panel: Exclude from main page -- works as expected.

I couldn't find any reading-related events in the Data Lake, nor was I able to see any flow in when I monitored the events in Kafka. Instead, I find that my browser throws the following error to the JavaScript console:

[HelpPanel] Value "reading" for property "editor_interface" is not one of ["visualeditor","wikitext-2017","wikitext","other"]

Change 494526 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Use schema version where reading is a valid editor_interface

https://gerrit.wikimedia.org/r/494526

Change 494526 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Use schema version where reading is a valid editor_interface

https://gerrit.wikimedia.org/r/494526

Change 494529 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@wmf/1.33.0-wmf.19] Use schema version where reading is a valid editor_interface

https://gerrit.wikimedia.org/r/494529

Change 494531 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@wmf/1.33.0-wmf.20] Use schema version where reading is a valid editor_interface

https://gerrit.wikimedia.org/r/494531

Change 494529 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.33.0-wmf.19] Use schema version where reading is a valid editor_interface

https://gerrit.wikimedia.org/r/494529

Change 494531 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.33.0-wmf.20] Use schema version where reading is a valid editor_interface

https://gerrit.wikimedia.org/r/494531

We monitored the SWAT deployment of the patch yesterday and confirmed through Kafka that reading events were flowing in. I've now also confirmed that reading events are present in the Data Lake.

Analysis by @MMiller_WMF and some digging by me indicates that events are not recorded correctly if the Visual Editor is used. Those events are instead recorded as reading events.