Page MenuHomePhabricator

Enable the Reply tool in the Project namespace (Wikipedia:) and other "wgExtraSignatureNamespaces"
Closed, ResolvedPublic

Description

This task is about enabling the Reply tool in namespaces on our target wikis that have the $wgExtraSignatureNamespaces turned on.

This above should not happen until this ticket is resolved: T250886

Deployment plan

Step 1 (Week of 27-April): make an announcement at each of our partner wikis

Step 2 (4-May): enable the Reply tool in namespaces that have the $wgExtraSignatureNamespaces turned on and monitor pages for good-faith vandalism

Step 3: If we see a proliferation of good-faith vandalism, we will consider the following approaches to make sure the "Reply" links do not appear on pages/in places they should not:

Timing

Assuming no blockers are discovered in T250886, we would like for this to be deployed on Monday, 4-May, via a SWAT window.

Done

Related Objects

Event Timeline

This should be configurable per-wiki.

Rather than introduce a new config option, I think we can use $wgExtraSignatureNamespaces for this. That config option currently controls in which namespaces we show an "Insert signature" button in the wikitext and visual editor. The current configuration for it includes the Project and Help namespaces: InitialiseSettings.php (warning, very large page).

(Related task about enabling on individual pages: T245890)

@Bdijkstra Is there any Help-namespace discussion page? I don’t know about such pages. It doesn’t make sense to enable this feature in a namespace where there are no pages it’s needed on. Even the project namespace is a bit “risky”, as there are many pages (policies, guidelines, essays etc.) where it shouldn’t be on. Maybe it should be enabled on project namespace pages only if __NEWSECTIONLINK__ is present.

On nlwiki there is Help:Helpdesk, which is one of the most used discussion pages on the wiki. We could move it to the project namespace, as it is the only discussion page in the Help namespace.

Not all pages in the Project namespace are discussion pages. I would propose a magic word (like __NOTOC__ and others), which tells the software if it is a discussion type of page.

After I found T245890, I think we could merge these two tickets into one, and keep the T245890 at the end: I like that solution more flexible than enable the tool generally in the Project (and/or in the Help) namespace.

On nlwiki there is Help:Helpdesk, which is one of the most used discussion pages on the wiki. We could move it to the project namespace, as it is the only discussion page in the Help namespace.

The goal of the talk pages project is to enhance the talk pages without disrupting previous workflows to the extent possible. Having to move a popular page is quite disruptive, so if there’s a real-life example, I’d say include the Help namespace as well. (Using $wgExtraSignatureNamespaces would include it.)

What about discussion pages in project space that don't use __NEWSECTIONLINK__, such as subpages of project pages like Wikipedia:Articles for deletion? Would communities be expected to add the magic word to all of those pages (or templates on those pages)?

@Jc86035 The wikitext parser puts some information in the database when it sees that magic word. The DiscussionTools extension uses that information, so subpages and templates are not a problem.

No, that's not what I meant. The magic word is not on the subpages (or on some of their parent pages, for that matter), which means that users will not be able to comment on those pages using the extension unless the magic word is added. At the same time, it may be inappropriate to add the magic word (e.g. because the edit button would create the wrong section header level).

What about discussion pages in project space that don't use __NEWSECTIONLINK__, such as subpages of project pages like Wikipedia:Articles for deletion? Would communities be expected to add the magic word to all of those pages (or templates on those pages)?

@Jc86035, good question.

For pages that fall into the category you describe in the comment above, do you think $wgExtraSignatureNamespaces being enabled would be a good proxy for making DiscussionTools available?

...a quick check of today's deletion log [1] leads me to think it might.

Note: we are investigating the signaling strength of $wgExtraSignatureNamespacesin this task: T249180


  1. https://en.wikipedia.org/w/index.php?title=Wikipedia:Articles_for_deletion/Log/2020_April_2

Per T249180, the extra signatures namespaces are as follows:

Here is the config for where the signature button is enabled (in addition to talk namespaces):

'wgExtraSignatureNamespaces' => [
	// Namespaces not listed in $wgContentNamespaces are not necessary here
	// for core, but reinforcing default config doesn't harm.
	'default' => [ NS_PROJECT, NS_HELP ],
	'+wikimedia' => [ NS_MAIN ],
	'+special' => [ NS_MAIN ],

	'+dewiki' => [ 100 ], // T145619 - Portal
	'+dewikivoyage' => [ 102 ], // T119420
	'+fiwiki' => [ 106 ], // T224215
	'+frwiki' => [ 102 ], // T127688 - Projet
	'+itwiki' => [ 102 ],
	'+nowikimedia' => [ 100 ], // T181625 - Prosjekt
	'+plwiki' => [ NS_USER, 100, 102 ], // T133978; 100 -> Portal, 102 -> Wikiproject
	'+ruwiki' => [ 104, 106 ], // T125509 and T213049
	'+ruwikinews' => [ 102 ], // T132241 - Комментарии
	'+sewikimedia' => [ 100 ], // T175363 - Projekt
	'+trwiki' => [ 102 ], // T166522 - Vikiproje
	'+wikimaniawiki' => [ 128 ], // T221062
]

For the vast majority of wikis it is just "Project" (usually renamed to "Wikipedia") and "Help".

Based on this, and the low risk of false positives (enabling DT when it isn't required), I think we should go ahead and do this.

Esanders renamed this task from Enable the Reply tool in the Project namespace (Wikipedia:) to Enable the Reply tool in the Project namespace (Wikipedia:) and other "wgExtraSignaturesNamespaces".Apr 19 2020, 1:51 PM

Change 590423 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] Enable on all ExtraSignaturesNamespaces

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

With the "Updates" and "Considerations" below in mind, we think it would be worthwhile to test enabling DiscussionTools in namespaces where the signature button is enabled. This way, Reply links could be visible without needing the "New section" to be available as well.

Before doing this, a question for everyone here: Can you think of reasons why it might not be a good idea to enable the Replying tool in namespaces where the signature button is available?

cc @Samat, @Dyolf77_WMF, @Lofhi and @AdHuikeshoven.


Updates:

  1. T249036#6016205 and T249180#6023498 shows that on most wikis, the signature button is enabled in the following places:
    • All talk namespaces
    • The Project namespace
    • The Help namespace
  2. Relying on the presence of __NEWSECTIONLINK__ as the only signal for enabling DiscussionTools outside the talk namespace may create more issues than we initially assumed. [i][ii]

Considerations

  • Unless signatures are present, DiscussionTools will not be visible to people, regardless of what namespaces the page is in or whether the signature button is enabled or not.
  • We do not think DiscussionTools being enabled will affect how quickly a page loads.

i. "There is a high likelihood pages containing __NEWSECTIONLINK__ have discussions on them and for those that do not, we are assuming enabling DT on these pages will have negligible impact on people reading/editing pages of this sort..."
ii. T250540: there are some pages outside the talk namespace where people would like for the Reply link to be available, but not the "New section" tab.

One thing I can think of is a help page/policy/guideline/whatever about signatures, which is in either the project or the help namespace, it contains signatures (as examples), but DT is rather contraproductive on it.

@Tacsipacsi that's a good example, here's a specific page https://nl.wikipedia.org/wiki/Wikipedia:Ondertekening?dtenable=1

While I agree that using the reply button on those pages would certainly not be desired, I think saying:

"Your signature will look like this: ExampleUser (talk) 2020-01-01 10:11:12) Reply"

would actually be helpful, and I think it's clear from the context that the Reply button should not be interacted with.

and I think it's clear from the context that the Reply button should not be interacted with.

OK, I hope so. Maybe such pages should be closely monitored after deploying this change, and it should be reconsidered if there’s a greater amount of good-faith vandalism on them.

For help documentation, we could also exploit the redirect-rejection feature to make the sig non-detectable. For example, redirect https://hu.wikipedia.org/wiki/Szerkeszt%C5%91:Example to your example account, and then link to the redirect in the help page.

and I think it's clear from the context that the Reply button should not be interacted with.

OK, I hope so. Maybe such pages should be closely monitored after deploying this change, and it should be reconsidered if there’s a greater amount of good-faith vandalism on them.

+1 – I think this is a great idea, @Tacsipacsi. I've incorporated it into the approach we are planning to take to roll out this change (see below).

Please let us know if you can think of reasons to modify the below.

Deployment plan

After a conversation with the team today, here is the approach we are planning to take...
Step 1: Next week, make an announcement at each of our partner wikis that contains the following:

  • Our plan to experiment with enabling the Reply tool in namespaces that have the $wgExtraSignaturesNamespaces turned on.
  • The issue this experiment could introduce (e.g. T249036#6074024)
  • A call for people to share links to page we should monitor for good-faith vandalism
  • The ways in which we could fix the above issue should it arise (e.g. those listed in T249293)

Step 2: A few days to a week later: enable the Reply tool in namespaces that have the $wgExtraSignaturesNamespaces turned on and monitor pages for good-faith vandalism

Step 3: If we see a proliferation of good-faith vandalism, we will consider the following approaches to make sure the "Reply" links do not appear on pages/in places they should not:

I just want to say here, for the record, that "good-faith vandalism" is an oxymoron.

Change 590423 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Enable on all ExtraSignaturesNamespaces

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

Deployment timing
Assuming no blockers are discovered in T250886, we would like for this to be deployed on Monday, 4-May, via a SWAT window.

I've updated the task description with this information.

Tgr renamed this task from Enable the Reply tool in the Project namespace (Wikipedia:) and other "wgExtraSignaturesNamespaces" to Enable the Reply tool in the Project namespace (Wikipedia:) and other "wgExtraSignatureNamespaces".Apr 30 2020, 9:36 AM
Tgr updated the task description. (Show Details)

Change 594240 had a related patch set uploaded (by Bartosz Dziewoński; owner: Esanders):
[mediawiki/extensions/DiscussionTools@wmf/1.35.0-wmf.30] Enable on all ExtraSignaturesNamespaces

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

Change 594240 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@wmf/1.35.0-wmf.30] Enable on all ExtraSignaturesNamespaces

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

Mentioned in SAL (#wikimedia-operations) [2020-05-04T18:11:39Z] <urbanecm@deploy1001> Synchronized php-1.35.0-wmf.30/extensions/DiscussionTools/includes/DiscussionToolsHooks.php: SWAT: b85fc16: Enable on all ExtraSignaturesNamespaces (T249036) (duration: 01m 00s)

Excellent.


FYI
@AdHuikeshoven, @Dyolf77_WMF, @Lofhi, @Samat: if all goes to plan, today the Reply tool will become available on all pages with the signature button enabled.

ppelberg added a project: Skipped QA.