Hi @KStoller-WMF @Trizek-WMF, do you have any concerns with removing the cited section from Special:DisplayNotificationsConfiguration? Personally speaking, I wasn't even aware of that page (let alone one of its sections), and because conditional defaults make it significantly more challenging to create a future-proof interface (if possible at all), removing makes sense to me, but I'd like to hear what you think before doing it.

@Trizek-WMF If we are to proceed with this as-suggested, do you have any ideas what should be linked as the documentation in that page? https://www.mediawiki.org/wiki/Notifications#Features (after updating) sounds like a possible target to me, or perhaps https://www.mediawiki.org/wiki/Extension:Echo?

The page was created to allow communities to see the defaults, and, possibly, to allow them to edit it.
This page is not really used AFACT, I use it sometimes to check if a config wasn't changed locally. While it is good to remove unused or replaced features, if we remove anything here, we have to document it.

What I don't get is what changes. We won't be able to set preferences for user types, like beginners? But instead, it would be by date of release?

Hello @Trizek-WMF,

The page was created to allow communities to see the defaults, and, possibly, to allow them to edit it.

Gotcha, thanks for the context.

This page is not really used AFACT, I use it sometimes to check if a config wasn't changed locally.

Which kind of configuration? I don't plan to change anything but the "Enabled by default" section. FWIW, settings listed in that section used to be impossible to change per-wiki (frwiki at one point wanted to enable reverted notification for everyone in T273787, which wasn't possible; now, such a change is possible).  

While it is good to remove unused or replaced features, if we remove anything here, we have to document it.

Of course :). The issue is that I'm not sure where to document this sort of change. I was imagining replacing this section of the special page with a link to a documentation page (which explains what the defaults are at least), but I'm not sure where I should be linking to. Alternatively, I can remove it completely if we're okay with it, and leave it to updating MW.org documentation only. Let me know if you have a preference :).

What I don't get is what changes. We won't be able to set preferences for user types, like beginners? But instead, it would be by date of release?

As far as the preference-setting capabilities are concerned, nothing user-visible changes. Both before the changes and after, we can have different defaults for user properties based on the user registration date. In other words, if someone registered prior to the release, the preference is unchecked; if they registered afterwards, it is checked (or vice-versa). This part doesn't change, we're only doing the same thing more efficiently. 

Prior to the conditional defaults project I was working on, each extension that wanted to have different behavior for new users and old users needed to use a hack. Usually, the hack was basically pretending the first thing every new user does is going to Special:Preferences and customizing their preferences. By pretending each new user goes to preferences and checks something, we were able to introduce different behavior for new users. This approach hurts our databases, and the DBAs requested a change, so we introduced conditional defaults. This approach also meant that per-wiki overrides are impossible, as you and me figured in T273787 some years ago, when frwiki requested a change that used to be impossible.

Most importantly, conditional defaults allow extensions to declare "the default for this preference is ABC, but when the user registered after <DATE>, the default is XYZ instead". This allows Echo (and other extensions) to remove its hack, and instead use conditional defaults, being nicer to the databases in the end. Conditional defaults also fully support per-wiki overrides, meaning requests such as T273787 now can be fulfilled without (major) issues.

However, conditional defaults don't necessarily have to be based on the registration date – they can be based on a totally different condition as well. For example, it is now perfectly possible for an extension to say "administrators will have a different default for this preference than non-admins''. Extensions can also have different defaults for users based on having a confirmed e-mail address, having enough edits or something similar. As of now, the only extension that uses conditional defaults is Echo, and Echo continues to use registration date as the condition. That being said, this is now only a matter of configuration, and as such, it can easily change in the future.

The other conditions (other than user registration date) are the problem here. The Special:DisplayNotificationsConfiguration page currently differentiates between "Existing users" and "New users". It works by having a hardcoded list of notification types that behave differently for new users (originally, this came from the hack I mentioned above). In other words, the special page currently does not really read the configuration – instead, the "New users" subsection of the "Enabled by default" section is built statically, having the behaviour from the hack hardcoded inside of it.

We can relatively easily map a registration date threshold to the "Existing users" vs "New users" setup. While I find it questionable whether labelling post-2013 people as "new" makes sense, such a debate is beyond the point, as conceptually, such a distinction makes sense. However, conditions that are not registration-date-based are much harder to display in the current version of Special:DisplayNotificationsConfiguration. For example, we wouldn't be able to display a wiki having different notification preferences using the "New users" and "Existing users" table, since the admin group is not based on whether the user is new.

This problem has a couple of solutions we can choose from. I identified the following options:

1. Leave Special:DisplayNotificationsConfiguration unchanged: We can decide not to care that Special:DisplayNotificationsConfiguration is broken, and simply avoid making any changes. As of now, the table is reasonably accurate (except the "post-2013 equals new" thing), but as wikis decide to make changes to how their notification works, it would gradually cease to be accurate (since the table is hardcoded into Echo, any per-wiki changes would not be reflected in it).
2. Completely delete the Enabled by default section and replace it with documentation: This equals to fully dropping the tables, possibly replacing them with a link to an appropriate MediaWiki.org documentation page. This solution is easy, but it removes a functionality.
3. Assume conditional defaults are only used to change behaviour for new users: We can assume whenever conditional defaults are used to change the notification defaults for a group of users, it is done to change the experience for new users. That way, we can automatically update the table based on whether the notification is conditionally enabled or disabled. This is a bit of work (compared to deleting it), but it is not terribly difficult. However, as soon as someone conditionally changes the defaults to customize behaviour for experienced user instead (such as, by introducing different notification defaults for admins), it will no longer be accurate.
4. Create a new version of Special:DisplayNotificationsConfiguration, taking conditional defaults into account: This basically means sitting down and designing a new version of Special:DisplayNotificationsConfiguration, which would work well with conditional defaults. It equals to a lot of work (for everyone on the team), but it is the only way to make this functionality unchanged.

Based on the anticipated low usage of Special:DisplayNotificationsConfiguration and on a technical discussion with @Tgr, I recommend going with the second solution (dropping the feature), and I filled this task to approve & implement said decision, but of course the final decision is up to @KStoller-WMF and you. Hopefully, this comment serves to explain the context and the various options we have.

FWIW, we were never able to set a different preference for beginners specifically. It was all based on "registered after/before" the release. This means that even now, Special:DisplayNotificationsConfiguration is factually inaccurate ("Existing users" means users who registered before April 2013, and "New users" means everyone else). Conditional defaults "just" make this already existing inconsistency worse (see above).

Okay, it makes sense. I agree with you: solution 2 is the best choice. It requires a little bit of design, but as most listed elements are defined with a pivot date, we can have a state for before and a state for after.

What about adding this page to Community configuration? You mentioned the request from French Wikipedia (T273787), who can now be performed. This should be done by the community.

Thanks for the thorough explanation. I'm in agreement that solution 2 seems like the option we should pursue.

In T357219#9541164, @Urbanecm_WMF wrote:
I was imagining replacing this section of the special page with a link to a documentation page (which explains what the defaults are at least), but I'm not sure where I should be linking to. Alternatively, I can remove it completely if we're okay with it, and leave it to updating MW.org documentation only. Let me know if you have a preference :).

@Trizek-WMF do you have thoughts on the above? Should we add a section or subpage to https://www.mediawiki.org/wiki/Help:Notifications?

Long term it might be interesting to explore Community Configuration for "Enabled by default" Notification preferences, but I imagine that could be a big project and not something we should commit to at this point.

My understanding:

• This page was created to show the local configuration of notifications and to allow users to edit it (the latter was never built).
• two levels of personalization were set: newcomers and experienced editors
• we now have the possibility to enable local configuration of notifications but only based on a start date: "before" users would have a different state than "after" users.
• the special page would become useless, as it won't reflect the date state
• upgrading this special page takes time and is not scoped.

The reasonable option is to drop that page, as there is no point keeping useless things on wikis. And the usage of this page remains unknown.

The question then is: how do we show the configuration applied at a given wiki?

Our options to compensate the demise of there special page are:

1. we don't show the configuration -- easy move, but it means that the information is difficult to find
2. we link to the config page -- minimal, provides information but it requires knowing how to read it
3. we create a page at Mediawikiwiki where the different configs are documented -- very easy to read, but time-consuming and not necessarily up to date
4. we upgrade the special page -- too much time-consuming and we have CC
5. put the info on CC -- no resources for now

I'd say we could go with #2, from https://www.mediawiki.org/wiki/Help:Notifications/Types, if we have mid-term plans to add the configuration to Community Configuration. If we don't have any plan, then we should have a special page to show the configuration for each wiki publicly.