Enable $wgWatchlistExpiry by default or remove it completely
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T52039 Proposed changes to default settings (tracking) | |||
| Open | None | T270058 Enable `$wgWatchlistExpiry` by default or remove it completely (TBD) |
Event Timeline
I don't think it should be removed completely as there are many smaller wikis which don't require the feature and so it'd be better to avoid the UI clutter.
Every feature flag in MW is a place where we never test anything and all our breakages happen. We try desperately to avoid them as much as possible.
Hi there,
Can you give some details as to why this is being Declined beyond just that the team agreed to do so? See my comment above.
Although this feature is useful for Wikimedia wikis (where it is already enabled by default), it is not useful for most wikis in the wild.
The choice seems to be between making our own config simpler while adding complexity to third party wikis, or maintaining the status quo which makes adds complexity to a smaller number of wikis and keeps it simpler for the greater number, noting that the amount of complexity / simplicity is fairly small regardless.
I would like to add that I have high confidence in the test suite for this feature. There we use dependency injection to set the feature flag, so we can easily run them for both scenarios (with and without the flag). They are integration tests so it will slow down CI a tiny bit, but nonetheless the coverage exists.
Re-opening, because feature flags are basically tech debt. Can we run this by the MW stakeholders group?
I was not even aware that this feature exists. However, I agree with @Samwilson comment above. It can be set to true or false by default. Third party users will not care as they can set it according to their needs.
But it should be possible to set it to false to make it simpler for users of smaller wikis who probably don't need this feature.
But it should be possible to set it to false to make it simpler for users of smaller wikis who probably don't need this feature.
This is what I have strong reservations about. One of the big problems we have with MediaWiki is the proliferation of feature flags and how much complexity that adds for testing and code maintenance. Unless small wikis really need to be able to turn this off then we should get rid of the flag
The number of places where we have to check $wgWatchlistExpiry has grown since this task was filed. Running this by the MediaWiki Stakeholders' Group sounds fine. The only argument for keeping it is with third party usage. Such users here include myself and presumably Sam, who were also incidentally co-authors of this feature. But the line must drawn somewhere… I see folks asking for even more features with respect to watchlist expiry, so my opinion has since changed. At this point, the maintenance burden is probably outweighing the benefits of offering a simpler experience for smaller wikis.
If there are still strong feelings for keeping the feature flag, perhaps we could rework it to simply control the display of the watchlist expiry dropdowns and preferences? That'd amount to basically a CSS hack. Not great, but still less significantly less maintenance burden than the status quo where we need to check the flag a bunch of places on the backend. Or, we simply instruct third party users to apply their own CSS hacks via Common.css :-P