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)

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.

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.

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.

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.)

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

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

In T65577#3809951, @Trizek-WMF wrote:

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

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.

@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 task 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, can you explain this move on the good first task board? Do you plan to claim that task?

No reply by @Zoranzoki21 hence reverting.