Page MenuHomePhabricator

Pruem
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Wednesday

  • Clear sailing ahead.

User Details

User Since
Jan 28 2017, 8:20 AM (142 w, 2 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
Prüm [ Global Accounts ]

Recent Activity

Aug 2 2019

Pruem added a comment to T229644: RelatedArticles showing on all German and Russian Wikipedia due to incorrect configuration settings.

I will now proceed to force-disable the extension by blocking api.php calls and see if this breaks something else.

Aug 2 2019, 5:25 PM · Wikimedia-Site-requests, Readers-Web-Backlog (Readers-Web-Kanbanana-2019-20-Q1), User-notice, Patch-For-Review, RelatedArticles
Pruem removed a project from T229644: RelatedArticles showing on all German and Russian Wikipedia due to incorrect configuration settings: Patch-For-Review.

@Aklapper: Steps to reproduce the problem:

Aug 2 2019, 5:22 PM · Wikimedia-Site-requests, Readers-Web-Backlog (Readers-Web-Kanbanana-2019-20-Q1), User-notice, Patch-For-Review, RelatedArticles
Pruem created T229644: RelatedArticles showing on all German and Russian Wikipedia due to incorrect configuration settings.
Aug 2 2019, 3:47 AM · Wikimedia-Site-requests, Readers-Web-Backlog (Readers-Web-Kanbanana-2019-20-Q1), User-notice, Patch-For-Review, RelatedArticles

Jun 29 2019

Pruem added a subtask for T226684: Update Echo compatibility styles for Wikimedia-deployed skins: T226875: monobook skin "your alerts" click brings "your notices".
Jun 29 2019, 12:29 AM · MW-1.34-notes (1.34.0-wmf.13; 2019-07-09), Technical-Debt, Growth-Team, CologneBlue, Modern, MonoBook, Notifications
Pruem added a parent task for T226875: monobook skin "your alerts" click brings "your notices": T226684: Update Echo compatibility styles for Wikimedia-deployed skins.
Jun 29 2019, 12:29 AM · MW-1.34-notes (1.34.0-wmf.14; 2019-07-16), Growth-Team, MonoBook, Notifications
Pruem merged task T226690: Monobook – the three symbols User-page / your alerts / your notices into T226875: monobook skin "your alerts" click brings "your notices".
Jun 29 2019, 12:27 AM · Growth-Team, Notifications, MonoBook
Pruem merged T226690: Monobook – the three symbols User-page / your alerts / your notices into T226875: monobook skin "your alerts" click brings "your notices".
Jun 29 2019, 12:27 AM · MW-1.34-notes (1.34.0-wmf.14; 2019-07-16), Growth-Team, MonoBook, Notifications

Jun 28 2019

Pruem added a comment to T226690: Monobook – the three symbols User-page / your alerts / your notices.

I apologize for this side comment. It's an inside joke where I live and means as much as snafu.

Jun 28 2019, 2:34 PM · Growth-Team, Notifications, MonoBook
Pruem added a comment to T226690: Monobook – the three symbols User-page / your alerts / your notices.

The direct precursor to this bug seems to be T226503. "Everything fixed, no problem at all."

Jun 28 2019, 12:20 PM · Growth-Team, Notifications, MonoBook
Pruem added a comment to T226048: Sometimes pages load slowly for users routed to the Amsterdam data center (due to some factor outside of Wikimedia cluster).

@Trizek-WMF: It would help if you stated what exactly are you interested in: The problem resolution from a technical perspective or the end user experience. The end user experience is well summed up in Gestumblindi's above comment of Tue, Jun 18, 23:05 (the ''acoustic coupler'' metaphor). At least that is how I experienced it.

Jun 28 2019, 7:23 AM · User-notice, Performance-Team (Radar), Operations, Traffic, Performance Issue

Jun 27 2019

Pruem added a comment to T226594: Wiki pages are very wide in Monobook for logged in users.

It would be (mildly) tragic if that NGO (read multi-million dollar Corporation) was so far removed from its original purpose as to foolishly blunder over some stupid badge icons.

Jun 27 2019, 2:32 PM · MW-1.34-notes (1.34.0-wmf.11; 2019-06-26), Regression, MonoBook
Pruem added a comment to T226594: Wiki pages are very wide in Monobook for logged in users.

It is just that it's a little confusing - a company shipping a piece of software yet not taking any responsbility for it. I would prefer it if there was a clear communication or a timetable for a phaseout so that end users would know when, how and where their own initiative was required. Leaving things to rot is not my idea of what I expect from a service provider.

Jun 27 2019, 1:40 PM · MW-1.34-notes (1.34.0-wmf.11; 2019-06-26), Regression, MonoBook
Pruem added a subtask for T226684: Update Echo compatibility styles for Wikimedia-deployed skins: T226690: Monobook – the three symbols User-page / your alerts / your notices.
Jun 27 2019, 11:17 AM · MW-1.34-notes (1.34.0-wmf.13; 2019-07-09), Technical-Debt, Growth-Team, CologneBlue, Modern, MonoBook, Notifications
Pruem added a parent task for T226690: Monobook – the three symbols User-page / your alerts / your notices: T226684: Update Echo compatibility styles for Wikimedia-deployed skins.
Jun 27 2019, 11:17 AM · Growth-Team, Notifications, MonoBook
Restricted Application added a project to T226690: Monobook – the three symbols User-page / your alerts / your notices: Growth-Team.
Jun 27 2019, 11:15 AM · Growth-Team, Notifications, MonoBook
Pruem added a project to T226690: Monobook – the three symbols User-page / your alerts / your notices: OOUI.
Jun 27 2019, 11:02 AM · Growth-Team, Notifications, MonoBook
Pruem added a comment to T226690: Monobook – the three symbols User-page / your alerts / your notices.

This issue is already discussed in the comments to T226594.

Jun 27 2019, 10:35 AM · Growth-Team, Notifications, MonoBook
Pruem added a comment to T226594: Wiki pages are very wide in Monobook for logged in users.

@Aklapper: Xaosflux has summed it up before me. I was just curious what would be the difference between "no full support" and "no support". Carrying wikipolitics on the backs of Wiki users (and volunteer developers) will not cut it, at least for me.

Jun 27 2019, 9:46 AM · MW-1.34-notes (1.34.0-wmf.11; 2019-06-26), Regression, MonoBook
Pruem added a comment to T226685: HTTP 503 on zh.wikipedia.org.

cp1077 is also producing this right now.

Jun 27 2019, 4:54 AM · Operations
Pruem added a comment to T226594: Wiki pages are very wide in Monobook for logged in users.

This goes to show the importance of testing. The uninformed user can easily construe such hiccups as being intentional trolling on behalf of WMF employees.

Jun 27 2019, 3:34 AM · MW-1.34-notes (1.34.0-wmf.11; 2019-06-26), Regression, MonoBook

Jun 22 2019

Pruem added a comment to T226048: Sometimes pages load slowly for users routed to the Amsterdam data center (due to some factor outside of Wikimedia cluster).

Shall we set this to resolved then? The active discussion on how to prevent this in the future seems to be taking place under another ticket.

Jun 22 2019, 4:32 AM · User-notice, Performance-Team (Radar), Operations, Traffic, Performance Issue

Jun 20 2019

Pruem added a comment to T226048: Sometimes pages load slowly for users routed to the Amsterdam data center (due to some factor outside of Wikimedia cluster).

This correlates to the previous appearance of the problem in early June, see https://grafana.wikimedia.org/d/000000352/varnish-failed-fetches?orgId=1&from=1559692800000&to=1559952000000.

Jun 20 2019, 4:03 AM · User-notice, Performance-Team (Radar), Operations, Traffic, Performance Issue
Pruem renamed T226048: Sometimes pages load slowly for users routed to the Amsterdam data center (due to some factor outside of Wikimedia cluster) from Sometimes some pages load slowly on de.wp in Europe (due to some factor outside of Wikimedia cluster) to Sometimes some pages load slowly for European users (due to some factor outside of Wikimedia cluster).
Jun 20 2019, 3:08 AM · User-notice, Performance-Team (Radar), Operations, Traffic, Performance Issue

Jun 19 2019

ToBeFree awarded T226048: Sometimes pages load slowly for users routed to the Amsterdam data center (due to some factor outside of Wikimedia cluster) a Like token.
Jun 19 2019, 9:11 PM · User-notice, Performance-Team (Radar), Operations, Traffic, Performance Issue
Pruem added a comment to T226048: Sometimes pages load slowly for users routed to the Amsterdam data center (due to some factor outside of Wikimedia cluster).

It would appear that the problem sits somewhere in the Amsterdam cluster. Maybe we should focus on pinpointing which of the various hosts involved could be the cause of the issue.

Jun 19 2019, 8:03 PM · User-notice, Performance-Team (Radar), Operations, Traffic, Performance Issue
Pruem added a comment to T226048: Sometimes pages load slowly for users routed to the Amsterdam data center (due to some factor outside of Wikimedia cluster).

My traceroute didn't reach any Wikimedia servers at all. A ping gives:

Jun 19 2019, 4:34 AM · User-notice, Performance-Team (Radar), Operations, Traffic, Performance Issue

Jun 18 2019

Pruem added a comment to T226048: Sometimes pages load slowly for users routed to the Amsterdam data center (due to some factor outside of Wikimedia cluster).

@Aklapper, I have used the network tab and from there I get the figure of >150 seconds. The status code is a 200, but the page loads in tiny amounts of data at a time, before a timeout sets in.

Jun 18 2019, 9:05 PM · User-notice, Performance-Team (Radar), Operations, Traffic, Performance Issue
Pruem updated the task description for T226048: Sometimes pages load slowly for users routed to the Amsterdam data center (due to some factor outside of Wikimedia cluster).
Jun 18 2019, 9:03 PM · User-notice, Performance-Team (Radar), Operations, Traffic, Performance Issue
Restricted Application added a project to T226048: Sometimes pages load slowly for users routed to the Amsterdam data center (due to some factor outside of Wikimedia cluster): Performance-Team.
Jun 18 2019, 7:58 PM · User-notice, Performance-Team (Radar), Operations, Traffic, Performance Issue

May 31 2019

Pruem added a comment to T212078: Some page categorizations not showing on Watchlist and RC.

It's no longer an issue, at least on dewiki. Let's hope it stays that way.

May 31 2019, 5:58 AM · TestMe, MediaWiki-Recent-changes, Regression, Growth-Team, MediaWiki-Watchlist

Jan 6 2019

Pruem added a comment to T212078: Some page categorizations not showing on Watchlist and RC.

You can test this by adding a page to a category and then immediately opening the recent changes page. The edit on the page is there, but the categorization isn't.

Jan 6 2019, 8:09 AM · TestMe, MediaWiki-Recent-changes, Regression, Growth-Team, MediaWiki-Watchlist

Jan 5 2019

Pruem added a comment to T212078: Some page categorizations not showing on Watchlist and RC.

No cigar, yet. This had apparently been fixed in December, but is now broken again. Confirmed on dewiki.

Jan 5 2019, 5:08 PM · TestMe, MediaWiki-Recent-changes, Regression, Growth-Team, MediaWiki-Watchlist
Pruem renamed T212078: Some page categorizations not showing on Watchlist and RC from Page categorization not showing on Watchlist to Page categorization not showing on Watchlist and RC.
Jan 5 2019, 5:06 PM · TestMe, MediaWiki-Recent-changes, Regression, Growth-Team, MediaWiki-Watchlist

Dec 26 2018

Pruem added a comment to T211849: A particular edit not showing on watchlist.

Page categorisation seems to show on RC and watchlist again, although the Mediawiki version has not changed. A configuration issue, perhaps?

Dec 26 2018, 11:24 PM · MediaWiki-Recent-changes, User-Ladsgroup, Regression, Growth-Team, MediaWiki-Watchlist

Dec 22 2018

Pruem added a project to T211849: A particular edit not showing on watchlist: MediaWiki-Recent-changes.
Dec 22 2018, 1:25 PM · MediaWiki-Recent-changes, User-Ladsgroup, Regression, Growth-Team, MediaWiki-Watchlist
Pruem reopened T211849: A particular edit not showing on watchlist as "Open".

The bug T212078 (which has been marked as duplicate) is definitely not solved in 1.33.0-wmf.9, which is the currently running version on dewiki per https://de.wikipedia.org/wiki/Spezial:Version. Therefore I reopened this task.

Dec 22 2018, 1:19 PM · MediaWiki-Recent-changes, User-Ladsgroup, Regression, Growth-Team, MediaWiki-Watchlist

Dec 19 2018

Pruem added a project to T212078: Some page categorizations not showing on Watchlist and RC: MediaWiki-Recent-changes.
Dec 19 2018, 11:01 PM · TestMe, MediaWiki-Recent-changes, Regression, Growth-Team, MediaWiki-Watchlist
Pruem added a project to T212078: Some page categorizations not showing on Watchlist and RC: Regression.
Dec 19 2018, 10:55 PM · TestMe, MediaWiki-Recent-changes, Regression, Growth-Team, MediaWiki-Watchlist

Dec 1 2018

Pruem added a comment to T165189: "→" link to page section on History page can be hard to click, should be larger somehow.

Thank you. I am still convinced that this issue could have been solved differently than by rendering the whole section title as blue link, which breaks functionality.

Dec 1 2018, 1:02 PM · MediaWiki-Page-History, MW-1.33-notes (1.33.0-wmf.6; 2018-11-27), MediaWiki-Comment-backend, Google-Code-in-2018, MediaWiki-Page-Diffs
Pruem added a comment to T165189: "→" link to page section on History page can be hard to click, should be larger somehow.

Where exactly was this proposed in the https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2017? Can't find it. Alternatively, any other community-based consensus/decision for this change,

Dec 1 2018, 12:53 PM · MediaWiki-Page-History, MW-1.33-notes (1.33.0-wmf.6; 2018-11-27), MediaWiki-Comment-backend, Google-Code-in-2018, MediaWiki-Page-Diffs

Dec 3 2017

Pruem added a comment to T42812: jquery.makeCollapsible: Refactor to use CSS instead of JavaScript to do the expansion/collapse (including initial state).

On my local MediaWiki installation I solved this (for tables) by adding the following to MediaWiki:Common.css:

Dec 3 2017, 9:28 AM · MW-1.32-notes (WMF-deploy-2018-05-08 (1.32.0-wmf.3)), MediaWiki-ResourceLoader, Performance-Team (Radar), Patch-For-Review, Readers-Web-Kanbanana-Board-Old, Vector, Readers-Web-Backlog, CSS, JavaScript, MediaWiki-Interface

Dec 1 2017

Pruem raised the priority of T42812: jquery.makeCollapsible: Refactor to use CSS instead of JavaScript to do the expansion/collapse (including initial state) from Lowest to Normal.
Dec 1 2017, 6:15 AM · MW-1.32-notes (WMF-deploy-2018-05-08 (1.32.0-wmf.3)), MediaWiki-ResourceLoader, Performance-Team (Radar), Patch-For-Review, Readers-Web-Kanbanana-Board-Old, Vector, Readers-Web-Backlog, CSS, JavaScript, MediaWiki-Interface
Pruem added a comment to T42812: jquery.makeCollapsible: Refactor to use CSS instead of JavaScript to do the expansion/collapse (including initial state).

Well, in that case I must ask why this simple, yet really annoying bug has not been addressed for 5 years. Maybe because it is ranked lowest priority and has no assignee? I'm not asking for it to be done by tomorrow, but there have been numerous requests on-wiki for it to be fixed asap.

Dec 1 2017, 5:45 AM · MW-1.32-notes (WMF-deploy-2018-05-08 (1.32.0-wmf.3)), MediaWiki-ResourceLoader, Performance-Team (Radar), Patch-For-Review, Readers-Web-Kanbanana-Board-Old, Vector, Readers-Web-Backlog, CSS, JavaScript, MediaWiki-Interface

Nov 30 2017

Pruem added a comment to T42812: jquery.makeCollapsible: Refactor to use CSS instead of JavaScript to do the expansion/collapse (including initial state).

Shouldn't we rather assume that JS is enabled by default and use the <noscript> tag? Otherwise, the content would still collapse after a page load, which is what we are trying to prevent. There could be a be style element inside the noscript, for example, where the default (script) CSS behaviour could be overridden. Or am I on a wrong path here?

Nov 30 2017, 9:07 PM · MW-1.32-notes (WMF-deploy-2018-05-08 (1.32.0-wmf.3)), MediaWiki-ResourceLoader, Performance-Team (Radar), Patch-For-Review, Readers-Web-Kanbanana-Board-Old, Vector, Readers-Web-Backlog, CSS, JavaScript, MediaWiki-Interface