[09:26:16] 31001, so close to being a nice round number [09:26:28] Delete one file 🧹 [13:07:55] I'm trying to deprecate a function in an extension's javascript. In addition to @deprecated in the function's documentation, should I also add some `mw.log.warn()` stuff? [13:10:11] unhelpfully... https://www.mediawiki.org/wiki/Stable_interface_policy#Deprecation_process only really seems to talk about PHP [13:14:13] well, https://www.mediawiki.org/wiki/User:Jdlrobson/Stable_interface_policy/frontend is still a draft [13:27:58] ah, there's `mw.log.deprecate()`, but it's not really documented. i'll give it a shot [14:30:41] This is the way. Will also cause it to show up in the logstash dashboards. (re @jhsoby: ah, there's mw.log.deprecate(), but it's not really documented. i'll give it a shot) [14:31:43] https://tools-static.wmflabs.org/bridgebot/3ecfdedc/mando_way_mandalorian.mp4 [16:23:22] (I'm not sure if this is the right venue for discussing this, but there seems to be a good overlap with PAWS users and the users here.) [16:23:23] [16:23:24] Recently disk quotas were imposed on PAWS. This resulted in a number of my data files being abruptly zeroed out, with a pointer to the related Phabricator ticket in the 97 bytes that were left behind instead. (Fortunately, none of these files were crucial, and were stored on Github in some fashion.) However, I was surprised a lot of the usual suspects who are involved with PAWS w [16:23:26] ere not in the discussion about 1) the quota and 2) the nature of how we use PAWS in the movement. So I thought I would surface that here for more comment. Ping @chicocvenancio [16:23:27] [16:23:29] https://phabricator.wikimedia.org/T327936 [16:23:30] [16:23:32] One related comment about PAWS resourcees stuck out to me, from rook: "PAWS is constrained to 1 cpu and 2G of ram. Such that when one starts exceeding those limits one should move to toolforge for a more complete experience." [16:23:33] [16:23:35] A few things - is 1 CPU and 2G or RAM the right model going forward? As compute resources and disk space have gotten cheaper over the years, does it make sense to adjust the resources accordingly? For example, this may be an imperfect comparison, but the resources described above are roughly the same as a $35 Raspberry Pi. It seems reasonable to ask whether we might support users [16:23:36] on PAWS with more than that, given PAWS is an important "on ramp" to development within the movement. (And this does not even cover the role of OpenRefine which is now within the PAWS environment. Ping @trnstlntk) [16:23:38] [16:23:39] Secondly, a Jupyter notebook system like PAWS which is incredibly user friendly is vastly different than a new VM or K8 tool that needs too be spun up and managed by the user on Toolforge. Therefore, I'm surprised that "move to toolforge" is being put forth as the next logical step once a user exceeds the arbitrarily drawn resource limit for PAWS. [16:23:41] [16:23:42] So I thought I'd put this out there for anyone who is interested in discussing this. I suppose it would make more sense to post this to the PAWS talk page. I'm actually surprised that the PAWS quotas, that has effectively deleted files of users without prior notice, was not even announced on the talk page. Thanks. [16:23:44] [16:23:45] https://wikitech.wikimedia.org/wiki/Talk:PAWS [16:34:53] Oooh, is this why my OpenRefine projects on PAWS are broken? [16:35:14] I wasn't aware (but then, I'm not following relevant channels where this would be announced) [16:35:33] Oh my, possibly?! (re @trnstlntk: Oooh, is this why my OpenRefine projects on PAWS are broken?) [16:36:40] To be clear: I have never had the expectation or wish that OpenRefine on PAWS would be a large volume service. I totally understand that there are constraints and that it may not stay up. I've appreciated every minute it's been there. [16:36:47] I only noticed because a lot of my files were zeroed out. I think we need to re-calibrate or re-specify what we use PAWS for. It might have been that in the early days, PAWS was simply a playground for pywikibot processes to do gnomish editing or tutorials. But today, we are doing some serious data science and/or big data operations. That means more files, longer runtimes, bigger [16:36:48] dumps, bigger files, etc. (re @trnstlntk: I wasn't aware (but then, I'm not following relevant channels where this would be announced)) [16:37:23] I would still totally understand if it would be capped. Just good to know if it is. [16:38:45] Yes, I'm grateful too. But I think it's also reasonable that we can help steer the narrative of how we are using these services. Just as with the mismatched expectations of SDC/WCQS and the search team, we may need a coming together to discuss how PAWS use has evolved in the last few years, and what are reasonable expectations. (re @trnstlntk: To be clear: I have never had the ex [16:38:45] pectation or wish that OpenRefine on PAWS would be a large volume service. I totally underst...) [16:40:25] Agreed, and I have always found the PAWS folks extremely nice and helpful. [16:40:48] Maybe this can continue on the PAWS talk page. Or should this be on Phabricator? [16:41:22] https://wikitech.wikimedia.org/wiki/Talk:PAWS [16:41:57] From the discussion on Phabricator, it doesn't seem like the cloud services folks may notice that we are doing some massive GLAM wiki-related big data edits over time. So while I can imagine in an old-school way, one would think that if you only had 1 CPU and 2 Gbytes of RAM around, one woud not need gigabytes of disk space, in the big data era that's actually quite common. So we [16:41:57] might have a Python script iterate over gigabytes of an open data CSV file, and doing reconciliation with Wikidata, or using pywikibot to add Wikibase statements, and have that running for hours and hours. [16:43:17] Yeah that previous Phab ticket is marked as closed, so I didn't want to kick up the conversation there (re @trnstlntk: Maybe this can continue on the PAWS talk page. Or should this be on Phabricator?) [16:51:05] I stand corrected - I am opening various projects in PAWS/OpenRefine now, and only found one 'corrupted' one so far. Quite a few of my larger projects load well. I continue testing. [16:52:28] Yes, only two corrupted projects found. I'm not sure if it merits a Phab ticket [16:53:04] I would have absolutely no idea why it's those two exact projects [16:56:29] Can you look into those directories in PAWS and see? The folders/directories are named something like 2302653098751.project as far as I can tell (re @trnstlntk: I would have absolutely no idea why it's those two exact projects) [17:40:56] And in Toolforge we're hitting the limits too, see https://phabricator.wikimedia.org/T340844 (re @fuzheado: (I'm not sure if this is the right venue for discussing this, but there seems to be a good overlap with PAWS users and the users...) [17:44:32] The people running Toolforge / WIkimedia Cloud seem to be a bit disconnected from the actual users. (re @fuzheado: From the discussion on Phabricator, it doesn't seem like the cloud services folks may notice that we are doing some massive GLAM...) [17:45:34] Throwing away user data without even informing the users is a good way to get yourself fired in a normal company [17:45:40] Interesting. My intuition is that our movement/community does a suboptimal job of adapting to the computing landscape and needs of users. What can be considered "restrictions on both CPUs and RAM" from 5 years ago is a nothingburger today. Yet, the restrictions still stay in place. And we don't seem to have a good way to adjust these limits as a collaborative endeavor between the [17:45:41] community and staffer... other than the occasional breakout of Phab debates. (re @MaartenDammers: And in Toolforge we're hitting the limits too, see https://phabricator.wikimedia.org/T340844) [17:46:07] Indeed, I was really shocked. Fortunately, it was just a big CSV that was stored elsewhere. But really. Wow. (re @MaartenDammers: Throwing away user data without even informing the users is a good way to get yourself fired in a normal company) [17:46:32] We used to have more dialogue about these kind of things. [17:47:14] Can we jump in a time machine and put this on the agenda for the 2023 Hackathon in Athens? :-P (re @MaartenDammers: We used to have more dialogue about these kind of things.) [17:49:35] Wikimania Hackathon in August is coming up, though I'm not sure whether that is a useful forum for surfacing this [17:55:35] For the record, this was the text that was left behind after the file was zeroed out: "This file has been removed to manage user storage size https://phabricator.wikimedia.org/T327936" (re @MaartenDammers: Throwing away user data without even informing the users is a good way to get yourself fired in a normal company) [17:55:51] Maybe approach it from the strategic side? Why do we have Toolforge and Wikimedia Cloud? Why does it exist, what's it purpose? [17:55:51] The goal of these actions is of course the most effective usage of limited resources. With a strategy you can point out that the current implementation of that goal collides with another strategic goal (something like good user experience and communication). [18:18:17] Regarding https://www.mediawiki.org/wiki/User:Jdlrobson/Stable_interface_policy/frontend I'm hoping to push within the next 3 months. I'm just waiting on feedback from a few people. Please let me know if there's anything in the existing document which in existing format you would veto as I'm hoping to send a mailing list to the email shortly to get this ratified by the masses :) [19:06:42] Recently, I had a major data loss incident on Cloud VPS which also involved a lack of communication (even though there was a shared ticket). Without going into details, this caused a lot of unnecessary work for all parties that could have easily been averted by staying in touch between staff and volunteer developers. Is the value of everyone's time missing from some equations so [19:06:42] to speak? (re @MaartenDammers: Maybe approach it from the strategic side? Why do we have Toolforge and Wikimedia Cloud? Why does it exist, what's it purpose? [19:06:44] T...) [19:17:34] So sorry to hear that, as I have felt similar pain. As the saying goes: "Something happening once is chance. Twice is coincidence. Three times is a pattern." [19:17:35] [19:17:36] To use more specific language – we've hit on a systemic problem that we've never done well with, but I fear has gotten worse. As to what @MaartenDammers mentioned, we do have "Coordinate Across Stakeholders" as a specific Strategy 2030 recommendation, and even a Technology Council "to establish processes for introducing new functionalities onto Wikimedia platforms and tools. Th [19:17:38] e aim is to improve communication between staff developers and other technical contributors to better network, coordinate innovation, provide and obtain support, and foster input on decisions and resource allocations that impact communities." [19:17:39] [19:17:41] https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Coordinate_Across_Stakeholders [19:17:42] [19:17:44] I have a feeling @gtisza has better insights into this. (re @tuukkahastrup: Recently, I had a major data loss incident on Cloud VPS which also involved a lack of communication (even though there was a sha...) [19:56:49] The IRC topic needs updating. [19:57:15] Would someone with +t please set it to: Wikimedia Hackathons channel | Next: 16–19 August 2023, Singapore and Online - https://w.wiki/6uxv | This channel is publicly logged | Follow the CoC & FSP | synced with messages to https://t.me/wmhack on Telegram