[09:31:30] Does everyone else see it like this on mobile view? https://www.wikifunctions.org/wiki/Wikifunctions:Requests_for_deletions [09:31:50] https://tools-static.wmflabs.org/bridgebot/59c478be/file_73394.jpg [09:38:07] No. But I did raise a ticket for it a while back. You can “Enable limited width mode” in “Skin preferences” (in Appearance), but then you lose interface-language switching (except via Preferences). (re @u99of9: Does everyone else see it like this on mobile view? https://www.wikifunctions.org/wiki/Wikifunctions:Requests_for_deletions) [09:42:54] *T391460* duplicate of *T365631* (re @Al: No. But I did raise a ticket for it a while back. You can “Enable limited width mode” in “Skin preferences” (in Appearance), but...) [10:59:31] That said, now I do (again) 🤷‍♂️ (re @Al: No. But I did raise a ticket for it a while back. You can “Enable limited width mode” in “Skin preferences” (in Appearance), but...) [15:46:45] Hello, all. A bit of an informal poll from the Abstract Wikipedia team. We recently enabled a feature to add qualifiers to Wikidata statements. However, this feature has increased our memory usage and caused service outages. We are debating whether to temporarily disable this feature in order to restore stability. My questions: [15:46:45] 1) Is anyone writing Functions that rely on qualifiers? [15:46:45] 2) Has anyone been heavily affected by the service outages? [15:46:45] 3) Does anyone feel strongly about the decision whether to temporarily disable this feature, removing access to qualifiers but improving service availability. [17:03:45] I’m not. And I haven’t seen a load suddenly appearing. (re @wmtelegram_bot: 1) Is anyone writing Functions that rely on qualifiers?) [17:07:32] I’m not sure what these outages look like. There has been some generalised misbehaviour but the only serious inconvenience I’ve experienced is a complete inability to publish one particular composition yesterday. I had to re-write it as a new implementation and it saved successfully (but whether that’s connected, I cannot say). (re @wmtelegram_bot: 2) Has anyone [17:07:33] bee [17:07:34] n heavily affected by the service outages?) [17:13:51] Not very strongly, but it obviously depends on how long we’re talking about. I think it’s more important to get a particular statement back and see that it has qualifiers, rather than getting all the statements and their qualifiers. But that pre-supposes that we can get back a particular statement’s qualifiers when needed. (re @wmtelegram_bot: 3) Does anyone feel [17:13:52] st [17:13:52] rongly about the decision whether to temporarily disable this feature, removing access to qualifie...) [17:31:39] I see. So, if we were to disable this temporarily, it would still be useful to see an empty list of qualifiers? Or something more informative, e.g. a count of the qualifiers that could be there if we processed them? (@Al: I think it’s more important to get a particular statement back and see that it has qualifiers) [17:33:17] On how long: it depends. Short-term mitigations for the memory usage issue should be on their way in the coming weeks. The "real" fixes are scheduled for the next fiscal quarter, so landing (most likely) sometime in November. [17:33:48] If the short-term mitigations pan out, we'd only go without this feature briefly. If not, then we'd be waiting a few months. [18:17:48] I’d think it was more binary: this is the whole statement or it’s not (as opposed to: we can’t give you the details so we’ll ignore the whole statement.) Some qualifier sets are quite complex, and it has been interesting to see how they look on Wikifunctions. If there were a way to allow a few complete Wikidata items or certain specific property types to be fully populate [18:17:48] [18:17:49] d, I think that would be more useful than a simple count. I’m not sure that the full structure without values would solve the memory issues in the short term, but it is worth considering, as it would allow functions to be developed that would ultimately interpret the structures. (re @wmtelegram_bot: I see. So, if we were to disable this temporarily, it would still [18:17:49] be us [18:17:50] eful to see an empty list of qualifiers? Or somet...) [18:19:47] I fear that it wouldn't solve the memory issues, and it would also create a lot of work for what is ultimately a temporary condition. I'll run it by the team. [18:19:47] But, as I understand it, the service outages haven't been too burdensome, so it's not urgent that we do anything right now. Is that correct? [18:22:44] Yes, that’s my perception. We could also exercise restraint about the items we explore, given appropriate guidance! (re @wmtelegram_bot: But, as I understand it, the service outages haven't been too burdensome, so it's not urgent that we do anything right n...) [18:23:23] Yes, that’s what I thought… (re @wmtelegram_bot: I fear that it wouldn't solve the memory issues, and it would also create a lot of work for what is ultimately a tempora...) [18:27:40] (but I strongly support more targeted retrieval, at the level of individual statements or property types.) (re @wmtelegram_bot: I fear that it wouldn't solve the memory issues, and it would also create a lot of work for what is ultimately a tempora...) [20:25:17] We are looking at that, too, as a separate item of work. Ideally, it will be possible to add some parameters to any request to retrieve Wikidata entities/lexemes/etc., so that the resulting object will contain as little extraneous data as possible. (@Al: but I strongly support more targeted retrieval, at the level of individual statements or property types) [21:30:37] Yes. I just thought it worth mentioning, in passing, that a data-light statement structure wouldn’t be just a temporary size-reduction trick if it provides the ‘questions’ to which specific ‘answers’ (the qualifiers) are available on request. (re @wmtelegram_bot: We are looking at that, too, as a separate item of work. Ideally, it will be possible to add some pa [21:30:37] [21:30:38] rameters to any requ...) [21:53:59] Really good point. If I understand correctly, you're saying that it would be desirable to have a statement structure that is semantically reflective of the data that someone wants to have available? [22:03:43] Yes — more like an index of what is actually available, rather than a projection of what someone might want. In practice, though, each slot knows what request would fill it, so the slot could be identified by the request itself. [22:09:57] Hmm hm. I see what you're saying. I don't know enough about the Wikidata representations to know whether there's a good pre-existing symbolic representation for "unfulfilled" qualifiers on a statement. I also don't know if there's an API exposed that would let us only resolve those things--our API usage so far suggests that this would just be another wholesale REST request with different params. Do these things exist? [22:23:01] I’m afraid I don’t know what’s available from existing Wikidata services. My thought was simply to elide some of the content we currently fetch, inserting placeholder requests for anything left unretrieved. Even parsing the item’s statements could presumably be handled in segments if necessary. [22:45:29] No. I don't think I'd noticed that they are available. I also haven't seen others working on it. (re @wmtelegram_bot: 1) Is anyone writing Functions that rely on qualifiers?) [22:47:28] I've seen a few glitches. It's never clear what caused them. I wouldn't call it strongly affected, but when the system is unstable I do tend to focus on other things until it is resolved. (re @wmtelegram_bot: 2) Has anyone been heavily affected by the service outages?) [22:50:01] My preference would be to temporarily disable all qualifiers. We have plenty of other new stuff to focus on for the moment. (re @wmtelegram_bot: 3) Does anyone feel strongly about the decision whether to temporarily disable this feature, removing access to qualifie...) [23:11:03] Understood. We're still going to try for the memory increase first, but I'll communicate to the team that we should keep the option of temporarily disabling the feature open until we've pushed some fixes. (@u99of9: My preference would be to temporarily disable all qualifiers. We have plenty of other new stuff to focus on for the moment)