User Details
- User Since
- Jun 3 2015, 10:26 AM (458 w, 5 d)
- Availability
- Available
- LDAP User
- WMDE-leszek
- MediaWiki User
- Leszek Manicki (WMDE) [ Global Accounts ]
Thu, Mar 7
Fri, Mar 1
apologies @danshick-wmde, thanks for correcting.
Cheers for those pointers @Dzahn, I clearly wasn't aware of those.
Tue, Feb 27
I approve the request on WMDE's behalf.
While the account has been around for a while it seems we have failed to request account holder to sign the NDA with the WMF. Hence this request but also we in particular would like to ensure there is NDA on file. Thanks for your help
Wed, Feb 21
I approve the request on WMDE's behalf.
Feb 13 2024
Agree with 429 for the rate limiting. I find the idea of using 403 for responses to edits that contained a forbidden (spam etc) URL or other content quite intriguing. I haven't thought of it, somehow assuming that response revolves around permissions/rights but this clear is not true, per MDN "re-authenticating makes no difference". I'd agree 403 those cases unless we find a reason to not use it and stick to general 400. Great suggestion!
Feb 6 2024
Feb 1 2024
Jan 31 2024
Jan 29 2024
Jan 26 2024
As an engineering manager at WMDE I endorse this request, and confirm @WMDECyn affiliation with WMDE.
Jan 23 2024
I'm not the most active Mediawiki+extensions contributor so that's only small two cents from me. I'm quite impressed @Paladox kept to hang around for that long after T106359 had happened, which has been quite a disappointing read.
The number of contributions is quite impressive. Those might be small contributions but I think they deserve opportunity to demonstrate the disputed understanding of the codebase in reviews. I think granting +2 rights could be a nice encouragement and motivation to do more of these (that's how I understand to above comments, that there's not been enough of complex mediawiki changes reviewed abd submitted by Paladox)
apologies, I missed phabricator notifications about those pings. The former structure is intentional, as it is in-line with how Wikibase REST API works overall. Basically it goes from the "higher level" item data structure, and more detailed "paths" relate to "traversing" the data tree. Hence when asked for sitelink data for a given site it is expected the API would give the data of it, a value of the "site_id" keyed object in sitelinks list.
Jan 19 2024
Jan 18 2024
could we please have @Deniz_WMDE and @Charlie_WMDE added. They act as board creators in the team currently. Thank you
Jan 16 2024
Jan 9 2024
Jan 8 2024
Regarding "filtering commits" - not sure if you want to keep in this task
yup, as @Muhammad_Yasser_Jazirahly_WMDE said above. If there is no sitelinks, and in particular no sitelink to 'enwiki' sitem the expected responses would be
../sitelinks -> {} (empty "map") 200 HTTP code
../sitelinks/enwiki -> HTTP 404 no sitelink defined for site "enwiki" or something along these lines
Jan 5 2024
Jan 4 2024
I confirm @Dima is WMDE software engineer, and approve this request on WMDE's behalf. Thank you.
Jan 3 2024
Very bad choice of words in the argumentation, my apologies. What I attempted to mean is that I'd encourage to compare both the cost of adding some additional logic to some low level code (and for how long? for a day or long-term?) as well as the "operational" impact of changing cache keys and its duration. (massive load spike and lasting how long) I am not saying it is not sensible thing to add, neither meant, of course, to say performance optimizations should only be restricted to cases when they would prevent complete outage. I attempted to call for more empirical approach to discussing benefits and tradeoffs of potential optimization.