Sun, Jan 26
Hi @Zoranzoki21, thanks for all your work on MediaWiki!
Sat, Jan 25
One of the annoying things about the Riot web client is that it loads quite slowly (as in, the initial downloading of all JS is slow). Someone has packaged it now as a browser extension (Firefox, Chrome, Github); that's probably worth calling out in the documentation.
Fri, Jan 24
Cool, that sounds a lot less effort to maintain than per-topic weights. If defining a custom function is easy, maybe we could use the max of the sigmoids instead of the sum? I think that's closer to how topic search is intended to work (if I check that I'm interested in art and physics, I would want articles that are about art or physics, not necessarily both).
Changing the copy + removing the arrow is minimal effort if we are OK with that.
Honestly, I don't think anyone will care about it. Search result counts are often a bit strange since counting large sets are hard and search engines tend to cheat in various ways (try paging search results in Google or Gmail for example and watch how the counts fluctuate).
Right, not sure why I assumed this is about living people...
This is fixed right now, but will become an issue again when we undo the separate-search-query-for-every-topic hack.
Probably not easy enough to do it in real-time though, right? So where would we store it? AIUI storing and accessing structured data is a bit inconvenient now for Commons files, and entirely impossible for non-Commons files. (Although in theory images of living people should all be in Commons, if the wiki follows the non-free content guidelines...)
Probably something to coordinate with the Structured Data team.
Yeah, that's what I meant with "keep having 200 cards". We'd probably want to change the copy for the no more results card though (maybe even add a different variant for the "there are more results but we won't show them" case) because the current one seems confusing.
Should the affected accounts be logged out? Phab sessions are long-lived so a login change might not have much immediate effect otherwise.
Thu, Jan 23
Kosta pointed out on the patch that there's still a tiny difference (the left arrow is 2px farther).
Started happening during the Phab upgrade today. Affects the generic search but not Maniphest search.
@MMiller_WMF one relevant question is, will we end up with the same topic list we use currently? If we do, we can just reuse the same on-wiki configuration pages and add the ORES config as another field next to the morelike config. If it's going to be a different set of topics, we'll probably want to use a new configuration page, and then we'll need some changes to the configuration loading logic too.
With AMC enabled, the user menu is just before the close icon. @RHo any recommendations? Should we move the close icon to the left-hand site? The arrow does not have to be clickable so in theory we could just overlay the X icon on it, but it looks terrible.
Wed, Jan 22
Probably caused by rEGRE7c36ad586104: Allow modules to export arbitrary module data, not just overlays. Not too serious as it only affects users with no mentor, but it's a production error so let's get it fixed soon.
- the current behavior of the counter does not follow the spec in T242418
abouttopic: would be a decent search keyword, too.
Needs RTL versions of the arrows.
To avoid maintaining an extra configuration setting, I'll use the filter dialog order for precedence (ie. we choose copyedit over link, link over update and so on). It's easy to change, if maintaining a different precedence order is preferred.
For topics it will be similar: topics that come first in the JSON file and the filter dialog are preferred when a task is in two topics. (Having to deduplicate topics should be a temporary issue in any case.)
Tue, Jan 21
@MMiller_WMF how do we prioritize this? Given the advanced state of T240556: Load ORES drafttopic data into ElasticSearch via the weekly bulk update, this probably won't be needed to have ORES search, but without it scores only update weekly (so recently created articles won't be returned); with it updates would be real-time.
ORES names are the drafttopic keywords returned by ORES (which are basically wikiproject names) - those could be one-to-one or there could be multiple ORES categories for a keyword.
Growth-Team will work on this; adding other affected teams for visibility.
To clarify, for Growth this is a nice-to-have since if all goes well soon we'll be using ORES for topic search. But it seems to me like a sensible thing in general (of course often a sensible thing for the user is feature creep for the maintainer).
Also we might need the equivalent functionality for ORES search.
This seems to me like a duplicate of T243036 but maybe I am misunderstanding the issue. Is there anything here that would be left after T243036 is done, of that could be done without resolving T243036?
Yeah, when all the text does not fit on a single line, it's handled by moving the difficulty label to a separate line. We can handle it differently if that's preferred (e.g. do the same but align it left; keep the label multi-line but expand the background to match it; keep the difficulty label on one line, even if that means the task name becames narrow and might turn into a weird "tower"); I don't see an obviously correct solution here that would stand out from the rest.
Mon, Jan 20
The custom welcome snippet is served from https://people.wikimedia.org/~tgr/matrix/welcome.html for the time being (and can be tracked via https://github.com/tgr/wikimedia-matrix-customizations ). If that gets annoying it can be moved to a more collaborative location, but I doubt it will need to be changed often (probably just once when T230532: Write documentation about the Matrix trial itself is done).
Sun, Jan 19
Thanks all for the offers to help! I think the immediate most useful thing would be to create a new user with Riot (the web, old/new iOS, old/new Android, desktop clients are all interesting targets; or if you feel strongly about using one of the alternative clients, that might be useful too), look at the basic things that can be done, take screenshots and write some documentation, as per T226631. (We have m:Matrix.org but that's very focused on using it as an IRC client, as opposed to chat client in general.) Then do the same with the internal matrix instance at wikimedia.riot.im, to the extent there are any differences (registration/login and privacy options, I guess).
The module uses more random results (roughly identical to using the API with gglimit=250 instead of 10, ie. top 250 results instead of top 10), to avoid all users who select the same topics getting the same tasks.
Sat, Jan 18
Is the goal here to animate the icon while the search is running in the background, or to animate it for a short time once the results have been updated, to draw attention to the new number? In the former case, should we also replace the old number with something indicating that we don't have the number yet?
Fri, Jan 17
Yeah, that data is needed for a lot of actions so it was easier to add it to everything.
The patch for logging topic / match score is not in production yet, it was merged on Wednesday. I'll look into the other one.
T203712: Formalize getQueryInfo() usage tried to ease migration by implementing ArrayAccess.
Can't reproduce the weird part - selecting Zdraví + Společenské vědy gives me 4 hits. Other than that, this is just due to (not) double-counting as you say. Which is currently somewhat incorrect as the tasks do get duplicated (the patch makes sure that we always report the number of task cards, not the number of matching articles, when the two differ), but once T243036: Newcomer tasks: rules for duplicate results is fixed this will be the correct behavior.
This is the same as T242814: Newcomer tasks: Discrepancy in article counter on "Select your interests" : we display the real result count (how many matching articles are there on the server), not the task card count.
Requests from the mobile domain to the canonical domain (e.g. cs.m.wikipedia.beta.wmflabs.org -> cs.wikipedia.beta.wmflabs.org) are also faux-blocked. This would affect EventLogging, probably a number of other things too.
Thu, Jan 16
The current behavior is:
- If you click on some link that's part of the survey, like the "skip" button, since we control the URL, we put a tag in it, and on pages with that tag in the URL, we show the notice.
- If you use normal browser navigation (that is, click on a link in the hamburger menu, or in notifications or search results) then Special:WelcomeSurvey will be in the referrer, and again we detect that and display the notice.
Wed, Jan 15
Do we really care about the difficulty and topic dialogs being the same size, or is it just that the topic dialog should be tall enough to not change when the user clicks "show more"? That seems a lot easier.
FWIW, the number of tasks we fetch from the API (which has performance implications), the number of cards we allow the user to page through, and the number we cap the result counter at, don't necessarily have to be the same. Detaching the first would take some engineering effort (making API continuation work), detaching the last would be trivial; so if we want to keep having 200 cards but show result counts up to, say, 1000, that would be easy to do.
Tue, Jan 14
Schema diff for the last patch.
Yeah, I figured it's easy to get that via negative conditions so we can as well as spare the storage space / bandwith (while sparing even more by only storing the cut position within the topic array, or something like that, would be annoying when doing analytics).
Yeah, the CirrusSearch API we use internally returns the total number of available results, no matter how many results we ask for.