[18:02:59] Is there a saved search / tag for good first mediawiki contributions. I'm looking for PHP tasks with minimal dependencies. e.g. https://phabricator.wikimedia.org/T227237 . [18:04:32] Tonymetz: #good-first-task is maybe what you are looking for -- https://phabricator.wikimedia.org/project/view/169/ [18:08:00] thanks! also, how does prioritization work? are there upvotes or some way to see which tasks are high impact? T227237 is good scope but 4 years old so it's hard to know if it will help [18:08:00] T227237: Create PasswordCannotMatchEmail password policy - https://phabricator.wikimedia.org/T227237 [18:13:31] there is a system for awarding tokens to tasks, but most of those tasks are either completed (and people are celebrating) or complex https://phabricator.wikimedia.org/token/leaders/ [18:17:01] https://www.mediawiki.org/wiki/Good_first_bugs also has some ideas [18:39:38] thanks that page is helpful i'll go through that content. any opinions on T227237 -- it seems like good utility. it's hard to know the incidence /impact of the issue though. do devs have any access to telemetry ? [18:39:38] T227237: Create PasswordCannotMatchEmail password policy - https://phabricator.wikimedia.org/T227237 [19:51:48] Tonymetz: What sort of telemetry? [19:51:58] It's the sort of thing that can be added, but easily enabled/disabled [20:13:21] for T227237 -- telemetry to understand the incidence of poor passwords among the audience. i.e. ways to understand the impact of improving password policies [20:13:22] T227237: Create PasswordCannotMatchEmail password policy - https://phabricator.wikimedia.org/T227237 [20:23:57] Tonymetz: the answer to your prioritization question is more complex than seems reasonable at first glance. Individual teams employed by Wikimedia Foundation or other entities generally make their own roadmaps that establish annual and quarterly goals. Within those roadmaps they will quite likely establish priorities. These are not often shared widely however and typically are not seen as motivating for technical volunteers. [20:24:49] that's helpful. any other good tips on picking an impactful task that will be readily merged and put to use? [20:25:22] https://www.mediawiki.org/wiki/Bug_management/Development_prioritization [20:26:18] (which may or may not be related) [20:29:15] Tonymetz: well... putting out fires is always something that is likely to get merged and deployed. By that I mean fixing new or long standing bugs that have active impact on a project or workflow. But, and wow is this frustrating to write, it also needs to be in a code area where a core committer who can approve the change for merging is paying attention to volunteer contributions and has time to evaluate the change. [20:30:26] Tonymetz: My general advice would be to try and find something your interested in personally. In my experience that's the most important bit and the extra interest will carry you through any of the additional challenges. [20:30:36] Even insiders like me (I work for the WMF) can struggle to fid reviewers for many things. [20:31:24] yeah, bawolff's advice is what we generally give. The "scratch your own itch" part of the larger FOSS ethos is a good place to start if you can. [20:31:49] Looking for things that people really want can sometimes backfire, because often (not always) there is some hidden reason that they are still open and not already fixed. [20:34:02] For finding an itch to scratch if you aren't deeply into using MediaWiki yourself yet you can look for structural things that interest you like telemetry (I saw mentions in backscroll), or code complexity, or some pattern that you like using, or things like that. [20:35:40] re https://phabricator.wikimedia.org/T227237 - that's probably a reasonable first bug. Keep in mind you can do implementing it as an option separately from actually enabling it, as the actual enabling might involve things like figuring out what the impact is, which might be more challenging, but doing just the implementation would be straight forward [20:45:43] that's good guidance on the rollout plan [20:46:21] andre_ thanks for the wiki [20:46:34] yw [20:47:20] Imagine the bazaar, and learn to embrace it. It's not the cathedral structure here. :P [21:36:06] Bumping this question again: After an upgrade from 1.35 -> 1.39, it seems that the recentchanges table isn't being populated unless I manually run the maintenance/rebuildrecentchanges.php script. There aren't any stuck jobs -- the count is always zero -- so that's not the problem. Any clues where I should look next? [21:42:37] hlieberman: Recent changes entries and jobs are saved at the very end of the request, when the entire HTML has been sent to the browser, to make saves faster. However, if an error occurs at this stage, there's also no error presented to the user, and that's what's likely happening to you installation [21:43:08] Interesting. Would that show up in the regular error log, or would that be something that you'd only see in some debug setting since it's already 200'ed out to the user? [21:43:25] If you set error logging, it should appear there [21:43:31] !debug [21:43:31] For information on debugging (including viewing errors), see https://mediawiki.org/wiki/Manual:How_to_debug . A list of related configuration variables is at https://mediawiki.org/wiki/Manual:Configuration_settings#Debug.2Flogging Also see https://mediawiki.org/wiki/Manual:Errors_and_symptoms [21:43:48] Let me take a peek at that then. Thanks, Vulpix. :) [21:43:48] The problem probably comes from an incompatible and/or outdated extension [21:44:30] That wouldn't surprise me, considering the version bump. I had to change the way a couple of them were loaded already. [21:54:54] OK, I created the debug log and then made a change. I found where it saved the new object into `text`, where it changed the slots and the content tables, where it updated the page... then it looks like it does some caching stuff in DeferredUpdates to clear the cache for that page. Aaand, bam. There we go. "Error: Class "IP" not found", from CheckUserHooks::updateCheckUserData(). [21:54:57] Exactly right, Vulpix. :) [22:04:38] Good. Interesting, CheckUser is bundled on the tarball, it should work [22:14:38] It's not bundled in 1.39 :) [22:15:33] "CheckUserHooks" sounds like an old version of the extension [22:16:02] https://github.com/wikimedia/mediawiki-extensions-CheckUser/blob/REL1_35/includes/CheckUserHooks.php [22:16:18] You should update it to the REL1_39 version (as with all skins and extensions) [22:21:51] Yup, that's what I did, and it fixed it right away. [22:22:20] My own damn fault for not doing things the right way and packaging the extension for Debian when I installed it. :) [22:26:12] heh