Page MenuHomePhabricator

Create a "Watching and notifications" tab in MediaWiki core
Open, Stalled, LowPublic

Description

Looking at mw:Special:Preferences#mw-prefsection-personal, currently "Email options" is under the "User profile" tab of mw:Special:Preferences. I think "Email options" should be moved to a separate "Notifications" tab in MediaWiki core.

This will allow third-party extensions (such as Echo) to more easily add their preferences to a dedicated, sensible section of Special:Preferences.

See Also:

Details

Reference
bz63577

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:17 AM
bzimport set Reference to bz63577.
MZMcBride created this task.Apr 5 2014, 5:32 PM

This sounds like a good idea.

Change 125762 had a related patch set uploaded by 01tonythomas:
Moved "Email options" preference to separate "Notifications" tab.

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

This will increase the clicks of distance from "Add * to my watchlist" options, which are logically connected to enotifwatchlist...

Moreover, that section includes "Email" and the link to Special:ChangeEmail, which should really be in the main pane and at any rate the same pane as "Global account status" (for CentralAuth wikis).

I'd rather:

  1. merge the two "Display options" of Watchlist/RC and move the Expand/Hide* options to RC (so that we finally solve the false dichotomy here and the unexpected interactions between the two);
  2. rename "Watchlist" to "Watching and notifications" or similar ("Following changes" would be a more traditional MediaWiki way to call it: [[m:Help:Tracking_changes]]), move there the email options other than "email" itself.

Krinkle said:

but I do think the tab name is confusing. it uses terminology that sounds
ambiguous, is probably quite hard to translate, and doesn't match terminology
we use elsewhere (sounds a bit foreign to MediaWiki).

but:

(from comment #3)

  1. rename "Watchlist" to "Watching and notifications" or similar ("Following

changes" would be a more traditional MediaWiki way to call it:
[[m:Help:Tracking_changes]]), move there the email options other than
"email" itself.

Any more opinions? An alternative would be a simple "Updates".

Right now "Watchlist" (from MediaWiki) and "Notifications" (from Echo) are separate preference tabs. Neither is particularly small or related to the other. Why should they be merged at all?

(In reply to Krinkle from comment #5)

Right now "Watchlist" (from MediaWiki) and "Notifications" (from Echo) are
separate preference tabs. Neither is particularly small or related to the
other. Why should they be merged at all?

Right, that wasn't the original purpose of the bug.

How about making the Notifications section part of MediaWiki and moving the email notification settings to it. Keeping the settings for the display of the Watchlist page and how things end up on it, separate.

(In reply to Krinkle from comment #6)

How about making the Notifications section part of MediaWiki and moving the
email notification settings to it.

Of course you can't really do this, it will be the opposite: create a section in core for a handful enotif settings and then change Echo to use it. It's still an improvement in clarity, we can start from here.

Keeping the settings for the display of
the Watchlist page and how things end up on it, separate.

Watchlist settings interact heavily with what the enotif settings end up doing, so it's counterintuitive to have them apart, but there's no need to fix all problems at once.

Watchlist settings contain:

  • When and how something is automatically added to your Watchlist.
  • What and how things are displayed on Special:Watchlist.
  • Authentication token for the Watchist data.

None of these affect notifications. And while you may get e-mails from pages changes on your Watchlist, or Echo notifications (if installed), the association seems arbitrary.

Besides, the setting for something being added to your Watchlist doesn't relate other people's edits being made. It relates to the default value of the "Watch this page" checkbox on pages you edit yourself. It still allows the user to opt-out.

There could be any number of preferences that influence default settings of the edit environment in general. And while edits can generate notifications, it'd imho be confusing to store them under notifications.

(In reply to Nemo from comment #7)

(In reply to Krinkle from comment #6)

How about making the Notifications section part of MediaWiki and moving the
email notification settings to it.

Of course you can't really do this, it will be the opposite: create a
section in core for a handful enotif settings and then change Echo to use
it. It's still an improvement in clarity, we can start from here.

Exactly. Right now Echo uses an internal pref section id of 'echo'. So we'd update Echo to extend the built-in notifications section instead of adding a new one for Echo.

Would such a change also obey/unify settings for the prefered mail format (plain vs HTML)? See bug 70245 for a related request.

He7d3r updated the task description. (Show Details)Dec 22 2015, 1:26 PM
He7d3r set Security to None.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 22 2015, 1:26 PM
Qgil removed a subscriber: Qgil.Dec 22 2015, 5:39 PM
Restricted Application added a project: UI-Standardization. · View Herald TranscriptMay 30 2016, 6:40 PM
Restricted Application added a subscriber: TerraCodes. · View Herald Transcript
Jdlrobson changed the task status from Open to Stalled.May 30 2016, 6:41 PM
Jdlrobson added a subscriber: Jdlrobson.

Given this patch stalled it would be good to have the the frontend standards group and collaboration team make a decision.

This has nothing to do with frontend standards, it's a matter of usability. I do not think this report matches the definition of stalled. https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle

Since Front-end-Standards-Group is a "Group" project (as documented on https://www.mediawiki.org/wiki/Phabricator/Project_management#Types_of_Projects), and since @Jdlrobson is a member of that group (as documented on https://www.mediawiki.org/wiki/Front-end_standards_group), I think it is appropriate to trust him when he says that this is something that the front-end standards group is interested in by adding the tag.

Catrope added subscribers: Trizek-WMF, Catrope.

Today's FSG meeting decided this wasn't in scope.

Taking off my FSG member at and putting on my Collaboration team lead hat: I think this makes some amount of sense, except that the tab name "Watchlist and notifications" doesn't make too much sense in a vanilla MW install without Echo. @Trizek-WMF , @Quiddity : thoughts?

I'm slightly concerned about moving the "Email options" section out of the primary "User Profile" section, because this makes it slightly less likely that editors will see this very important element (important for password resets, beyond anything else).

This task also conflicts with T53941: Merge "Recent changes" and "Watchlist" preferences tabs, which seems to me like it might work out better for the increased functionality we're likely (hoping) to have there in the medium-to-long term future.

There are related ideas at https://www.mediawiki.org/wiki/Requests_for_comment/Redesign_user_preferences#Current_structure_and_proposals (I just updated "Proposal 2"; @MZMcBride you might want to update "Proposal 1"; anyone else might want to add further proposals, or discuss on the talkpage.)

Krinkle removed a subscriber: Krinkle.Jul 4 2016, 5:45 PM

If there is still consciousness on the same, I can get the patch rebased.

01tonythomas removed 01tonythomas as the assignee of this task.Jun 10 2017, 3:10 PM
Framawiki moved this task from Backlog to Doing on the good first bug board.Dec 2 2017, 1:38 PM

@Framawiki, if you are working on that task, please claim it. :)
Otherwise, please move it back to Backlog on good first bug.

@Framawiki, if you are working on that task, please claim it. :)
Otherwise, please move it back to Backlog on good first bug.

Hello @Trizek-WMF ! This task has a Patch-For-Review tag, due to https://gerrit.wikimedia.org/r/#/c/125762/ that waits for reviews/merge/abandon. That's the reason for the column shift I did.

Aklapper moved this task from Doing to Backlog on the good first bug board.Dec 4 2017, 10:29 PM

@Framawiki: A 3 year old patch that does not merge and needs manual rebasing does not mean that somebody works on this (plus I don't understand why the good first bug workboard has such a column anyway, if the "Doing" column just blindly duplicates the Patch-For-Review tag. More manual work for zero gain).

Zoranzoki21 moved this task from Backlog to Doing on the good first bug board.Jan 31 2018, 3:57 PM

@Zoranzoki21, can you explain this move on the good first bug board? Do you plan to claim that task?

Aklapper moved this task from Doing to Backlog on the good first bug board.Mar 27 2018, 1:04 PM

No reply by @Zoranzoki21 hence reverting.