In T209982#4807163, @Catrope wrote:

• Being able to track that the user clicked on the cog would be useful. I'm not sure what the current plan for that is? As Roan mentions, if the user goes through and changes their preference we will be able to identify that through the PrefUpdate schema.

We can either make that a separate type of action. I think that would be preferable over abusing the link-click action.

On reflection, it functions exactly like a link (opens a URL in a new tab), so I think we should just track it as a link-click action with a specific ID.

In T209982#4804985, @nettrom_WMF wrote:

I don't think we need oversampling of EditAttemptStep in addition to what is already done in relation to EditorJourney. While working on putting the specifications together, I haven't seen a question that requires data from EditAttemptStep.

OK, good to know.

In T209982#4797770, @kostajh wrote:

Count of when the question is the *first edit* made by a user?
Can we track if a user edits their question on the Help desk after it is posted?

I think @nettrom_WMF can pull this out of the Mediawiki database pretty easily if we do T211118: Help panel: provide tag for help panel related edits.

Yes. Adding the edit count as I mentioned above is also pretty easy though.

In T209982#4797539, @RHo wrote:

• Namespace in which the help panel is triggered (if we decide to add help panel to Main, Talk, User pages, etc)

Yes

As far as I can tell, it's not true that the __NOINDEX__ magic word and the {{NOINDEX}} template do not work on pages older than 90 days (which is what the documentation on enwiki claims). The __NOINDEX__ magic word does not expire, it's effective forever. But it's also disabled in the main namespace, so the only thing noindexing pages in the main namespace should be PageTriage.

First stab at a draft schema: https://meta.wikimedia.org/wiki/User:Roan_Kattouw_(WMF)/Draft_help_panel_schema.json

I think we want to track events when the user:

• Sees the panel (panel is displayed)
• Opens the panel
• Closes the panel
• Advances to the question review panel
• Goes back to the home panel
• Clicks a link in the panel
• Types something into the text box (i.e. text box changed from empty to non-empty)
• Submits a question
• Submission succeeds
• Submission fails

The schema is a bit confusing. init_type, init_mechanism, etc are only set when action='init', ready_timing is only set when action='ready', etc.

In T206717#4787433, @MMiller_WMF wrote:

• RTL: does our implementation support RTL languages out of the box? Such as putting the call to action on the lefthand side? I could see this feature being deployed to Arabic or Persian Wikipedias within the fiscal year.

Yes. The below looks a bit weird because all of the text is in English, but it's correctly RTL-ed:

@kostajh I found two bugs / weird things in the current patch.

Screenshots of @kostajh 's current work-in-progress implementation:

In T209318#4788400, @Catrope wrote:

Also, if the help desk is a Flow page, that would mean adding an edit tag to the creation of a Flow post, and while that should be possible in theory, I don't think anyone's ever tried that before.

I now see T209318#4773442 where @Trizek-WMF says that posting to Flow pages isn't required yet. Kosta's already got an implementation that I believe will work for Flow pages, but we could still ignore the Flow tagging issue for now.

In T209318#4787687, @MMiller_WMF wrote:

• The requirements say "Tag the post as coming from the help panel so that other users may monitor the content". Does this mean adding an explicit "edit tag" that can be queried in the database? That sounds useful.

Yes. However, since we're using MessagePoster that might require a little more work than I thought (because we have to propagate the tag we want to add through the generic MessagePoster infrastructure). Also, if the help desk is a Flow page, that would mean adding an edit tag to the creation of a Flow post, and while that should be possible in theory, I don't think anyone's ever tried that before.

In the current version of the patch, the checkbox sometimes doesn't immediately go away when an option is unselected.

@Banyek That sounds right to me. The migration script already exists and was used successfully in beta. That was in 2016, so hopefully it still works, but at least we won't have to write it first.

An alternative proposal (and also something that I think is worth doing regardless, if we keep these notifications), is for these notifications to be based on the global edit count rather than the local edit count. That would remove a major source of annoyance for experienced users who get 1st and 10th edit notifications from wikis that they edit infrequently.

In T177281#3664306, @Trizek-WMF wrote:

There is a proposal to have MediaWiki tagging redirects: T73236: Automatically tag edits that make a redirect, or convert a redirected page to a normal page, or move a page across namespaces, etc.

I'm not really excited about the Growth team being put on the hook to maintain yet another unloved extension. Of all the patches merged into FlaggedRevs in the past 18 months, only 2 were by a Growth team member (both by me). It's also not very related to our team's mission. @Tgr 's comment identifies two parts, and the first part (reviewing) is related to the old Collaboration team's mission, but the second part (displaying old revisions and doing black magic in the parser) isn't at all. Perhaps this would have a better home in the Reading Infrastructure team, or another team that more regularly works on the reading UI and the parser.

There are a bunch of tasks related to link notification spam, including T46787

Basically what I did is allow for package files to be either JS or JSON, and allow for virtual files of either type. Virtual files can be based on a callback or on a set of config vars.

It so happens I'm already working on this as part of T133462: Provide standard-compatible way to load multi-file packages (not plain concatenation).

In T207990#4758871, @sbassett wrote:

I'll start on this. @Catrope - just to confirm, everything there is for this extension is already at: https://github.com/wikimedia/mediawiki-extensions-TheWikipediaLibrary (aside from Flow, which it integrates with)? No pending or near-future commits atm? Thanks.

I've updated the patch and I think it's ready for review now.

Also even if we did fix the number, we still wouldn't fix the list of wikis, or the correct plural conjugation in the message with the number of wikis.

This is too hard. I spent several hours trying to get the "View 3 notifications" label to update itself with the correct cross-wiki count, tried 2 different approaches, and they both don't work. I'm sure this can be done if we put more work into it, but I've already spent too much time on a minor cosmetic change. It's not worth it.

In T206716#4753770, @Trizek-WMF wrote:

autopatrolled (over 500 edits/30 days)

Those kinds of autopromotion thresholds vary by wiki (and not all of them exist on all wikis). I think it's also important that a highly experienced user with a high global edit count but a low local edit count on e.g. cswiki doesn't get the help pane when they visit that wiki. So maybe it'd be better to set a threshold based on the user's global edit count and/or global account age.

I think the edit adding the question should be attributed to the user, not a bot account. The user authored the actual content of the question, the software only facilitated putting it in the right place and generated (part of or all of) the header. There's more creativity / meaningful authorship in a help question like this than there is in most Twinkle actions for example, and we attribute those to users too :)

In T207717#4735347, @SBisson wrote:

@Catrope, @Krinkle: Do you know if there is a reliable way to detect that a user supports JS from the server side?

I don't believe so.

Once this change is deployed (most likely in late November), $1 will be the URL of the login page with the right parameters set, and $2 will be the URL of the signup page.

Another reason why NULL is used here: the timestamp is only updated the first time the page is edited. For subsequent edits, it is not updated. This way we know which edits the user has and hasn't seen, and we can offer them things like a link to the diff of all the changes they haven't seen, and markers on the history page for all new edits.

Moving this to 'Triaged but future' because many Page Curation tasks are currently part of the 2019 Wishlist Survey

Moving this to 'Triaged but future' because many Page Curation tasks are currently part of the 2019 Wishlist Survey

Moving this to 'Triaged but future' because many Page Curation tasks are currently part of the 2019 Wishlist Survey

Moving this to 'Triaged but future' because many Page Curation tasks are currently part of the 2019 Wishlist Survey

Moving this to 'Triaged but future' because many Page Curation tasks are currently part of the 2019 Wishlist Survey

@ssastry To aid in our prioritization/triage: roughly when would you like this to be done?

We decided that we want to fix this eventually, but we think this is a low-impact issue, because there aren't common use cases for sharing links to these pages.

Looks like this was directly caused by the previous fix for this bug, which changed rfd to rdf-NPF in ext.pageTriage.defaultDeletionTagsOptions.js without also updating specialDeletionTagging in ext.pageTriage.delete.js.

That's not what I see. Instead, specialDeletionTagging is defined, but tagObj.tag is set to 'rfd-NPF', and there's no such key in specialDeletionTagging.

We'll need better logging to figure out what's causing this. The stack trace comes from MediaWiki::preOutputCommit so we have no idea which API module this came from or what kind of query it tried to issue.