[10:39:20] * hashar invokes addshore [10:39:37] addshore: there is some other fancy issue with composer and declaring a vcs repo [10:39:55] the composer merge plugin apparently does not quite handle it. That sounds similar to the issue we had last friday with phpstorm :( [10:40:06] Aleksey_WMDE poked me about it via https://gerrit.wikimedia.org/r/#/c/333961/ [10:40:45] It is not a problem with vcs repo, it is problem with composer merge plugin setup and jenkins task setup [10:44:46] trying to reproduce on my local machine [10:44:58] to figure out what is going on and eventually find a fix :D [10:49:29] same issue locally [10:51:05] Composer merge plugin merges composer.json of each extension but ignores all "-dev" keys because of the setting in code composer.json:96 `"merge-dev": false` [10:51:05] In Wikibase extension was introdused new dependency for testing in "require-dev" so simple `composer update` in root directory doesn't/willnot work. [10:51:05] The fix is either to replace `false` with `true` composer.json:96, or run `composer update` in Wikibase extension directory (Wikibase's code will include file "Wikibase/vendor/autoload.php" if it is there) [10:51:53] Changing core's composer.json is not an optin, I'm afraid, because it might break a lot of stuff [10:52:17] So the solution is to run `composer update` in Wikibase repository [10:57:58] ahhh [10:58:04] merge-dev is false in mediawiki/core yeah [10:58:07] sorry missed that part [10:58:46] one sure thing, we can use merge-dev [10:59:03] since extensions definitely have conflicting version requirements [10:59:33] Sorry, "can" or "cannot"? [10:59:41] yeah we can not [10:59:44] sorry :( [11:00:01] we had that plugin and have been using composer for quite a while now [11:00:14] I am surprised that is the first time we are hit with a missing dev requirement [11:00:45] that hamcrest-html-matches is part of getting rid of PHPUnit deprecateed assertTag isn't it ? [11:00:53] Yeah [11:00:59] so [11:01:07] I dont have a solution to get the require-dev included [11:01:08] but [11:01:32] since MediaWiki core has at least a use of assertTag, I guess we can add the requiremeent directly in mediawiki/core [11:01:43] which should solve the problem for you [11:02:01] and make the dep available to all other extensions so we can eventually phase out assertTag entirely [11:02:05] can't we run `composer update` in Wikibase directory in Jenkins [11:02:18] Because that's what we do on our local machines [11:02:32] maybe? :] [11:02:38] Sorry, former was a question [11:02:54] but really the grant idea of the composer merge plugin is to simulate a composer update from each of the extensions [11:03:02] though the require-dev are not listed in bah [11:03:16] let me grab a coffee an dthink about it for a few minutes. [11:03:48] one sure thing is that I have been watching the task "Create Hamcrest based replacement for PHPUnit's assertTag" https://phabricator.wikimedia.org/T69122 [11:04:11] because mediawiki/core has a few use of assertTag which I would like to drop. So most probably that specific lib will end up in mediawiki/core require-dev [11:04:19] and that would workaround/solve the problem [11:10:04] Aleksey_WMDE: so in the end the summary is: [11:10:21] mediawiki/core and mediawiki/extensions/Wikibase each have a job that runs "composer update && composer test" [11:10:52] that runs among others php codesniffer, and we want mediawiki/core and extensions to be able to use different versions [11:11:17] then when running tests, you depend on that hamcrest thing. And you are right it should not land in production [11:11:30] but we dont merge devs (because of the different codesniffer versions) [11:19:42] hashar: ooooh [11:21:02] fun isnt it ? [11:27:30] the composer-merge-plugin supports deep merges of extra sections [11:27:39] but always excludes "merge-plugins" subsections bah [11:31:54] well, the codesniffer versions shouldnt be required in such a strict way IMo anyway! ;) [11:31:57] Lydia_WMDE: around? [11:46:03] Aleksey_WMDE: so yeah. I think you should add the two deps in mediawiki/core directly. That is the easiest to unlock your case :( [11:46:20] wrote a summary on the gerrit change https://gerrit.wikimedia.org/r/#/c/333961/ [11:54:59] Read it. You wrote "`composer update` in each extension directories". Currently we don't need in each, but only in Wikibase. Why not to do that? [12:49:25] hashar: Here is the proposal https://gerrit.wikimedia.org/r/#/c/335215/ [12:53:43] addshore: now i am [12:53:44] wasup? [15:23:57] sjoerddebruin: https://developers.facebook.com/tools/debug/sharing/?q=https%3A%2F%2Fwikidata.beta.wmflabs.org%2Fwiki%2FQ81561 [15:24:09] Amir1: Pictures <3 [15:24:20] It's merged and deployed in beta, it'll be there for Wikidata in one week [15:24:26] (deploy train and stuff) [15:25:21] Good. [15:26:50] \o/ [17:18:49] o/ DanielK_WMDE [17:18:56] I heard you had some thoughts re. Item quality. [17:21:38] halfak: i do? [17:22:05] i was just talking to Glorian and Thiemo about this topic, yea... [17:22:25] but just idle brain storming. ad hoc heuristics [17:23:10] DanielK_WMDE, would love to hear your thoughts. [17:23:52] halfak: one thin we discussed was the number of descriptions. interrestingly, it'S probably a better indicator than the number of labels. [17:24:00] though the number of distinct labels may also be a good indicator [17:25:37] other than that, i'd guess the same correlatiosn hold that were found for wikipedia pages: quality is correlated with age, number of distinct edtors, total size, pragraph length, incoming links, outgoing links... you probably know much more about these than i do :) [17:25:38] number of descriptions gets a bit distorted by bots [17:26:38] Yeah, eg. disambiguation pages or templates have a tone [17:26:41] * ton [17:26:43] DanielK_WMDE, thinking about correlations needs to happen *after* we have a good outcome measure. [17:27:03] Let's talk about what quality *is* and then figure out what correlates with it. [17:27:42] halfak: o/ [17:28:22] E.g. I've been talking Glorian_WMDE about recommended properties. Rather than worry about *how* we'll get "recommended properties" let's just ask a labeler to say whether or not an item has all the properties that it should. [17:28:31] And we'll figure out how to measure that later. [17:28:57] 1. Horses, 2. Cart [17:29:08] halfak: well, you have two kinds of completeness, for one thing: all the relevant properties should be there, and each statements should have all relevant values. [17:29:19] DanielK_WMDE, sounds great. [17:29:25] that's awesome criteria :D [17:29:29] Let's put that in the description [17:29:32] then of course, all these values should be correct. [17:29:38] At what level do you see "property completeness"? [17:29:54] and if we can't check that, at least consistent, and conforming to the constraints defined for the respective properties [17:30:16] DanielK_WMDE, getting into implementation details again [17:30:35] more into the details of what "correct" means [17:30:44] We could just say "values are good" [17:30:56] And let the user work out what that means. [17:30:57] we could also just say "item is good" ;) [17:31:06] DanielK_WMDE, wouldn't allow us to set a scale [17:31:15] Want a classifier or good/not-good? [17:31:18] We can do that [17:31:37] If you feel like people can judge good/not-good consistently and the good/not-good classifier would be useful. [17:31:50] not sure you can easily scale based on good/bad answers for properties. some are more relevant than others. [17:32:00] wat [17:32:11] If a property has a bad answer, you'd remove it, right/ [17:32:14] ? [17:32:24] Also, what do you mean "scale"? [17:32:59] the item is not 0.5 good if half the property values are good. if half the propery values are not good, the item it probaly 0.01 good :) [17:33:33] This smells like an implementation detail. [17:33:38] halfak: anyway, I'm not an expert at this, and i'm not an active community member. i'm making stuff up as i go along here. [17:33:50] OK. Gotcha. Who should we talk to? [17:33:54] anyway. property completeness. [17:34:22] for some classes of things, we could define a set of desired properties. e.g. for people, we'd have place and date of birth, occupation, nationality, etc. [17:34:39] for a city, it would be location and country (or something like that) [17:35:59] halfak: you want to talk to bepole who have a good intuitive understanding what a good item or a good statement is? [17:36:06] and that can explain their criteria to you? [17:36:08] that would be nice (@ desired properties) [17:36:15] another thing about counting labels/descriptions, some languages have a much bigger audience than others... is 10 labels in not-widely-spoken languages really better quality than an item with 1 label in a widely spoken language? if counting languages is about working out how many people can access information about the item, I would say no :) [17:36:27] DanielK_WMDE, yeah... Sorry I didn't make that clear. [17:36:53] halfak: i'd probablytalk to wikidata admins [17:37:02] I don't expect someone to be able to lay out a whole quality scale, but rather to talk about what "good" means. [17:37:11] and eventually we can make a scale. [17:37:31] sounds like a good approach. [17:37:40] nikki, what do you think of working from a set of examples? [17:37:51] i'd go to the people who make these judgements all the time - that is, they patrol edits on wikidata [17:37:55] If the situation you describe rarely happens, no sense in building criteria around it. [17:38:06] DanielK_WMDE, how would you contact them? [17:38:35] having desired properties for instances of a given class would be a very good first step - they would be sorts of "soft constraints" [17:39:08] halfak: i'd probably just look at the people with the most edits, and then check how many of these are reverts or talk page edits... [17:39:16] (we should have that in OSM too, btw) [17:39:25] or you could ask Lydia_WMDE if she has a better idea :) [17:43:06] halfak: using real examples sounds good. I was just thinking about *why* lots of labels/descriptions should make something good quality [17:45:12] and it seems like it's really "the labels/descriptions are accessible to a large number of people" [17:46:06] nikki, sounds good. I wonder if we could put together a report on the critical languages to cover the majority of humanity. [17:46:18] (again, besides the point, but maybe that helps us think about it) [17:46:39] DanielK_WMDE, is there a forum that would be most appropriate to start this discussion? [17:46:46] Lydia_WMDE, ^ [17:48:11] the UN languages are probably a good and fairly neutral starting point (arabic, chinese, english, french, russian, spanish) [17:48:15] project chat [17:48:40] linky? [17:49:03] https://www.wikidata.org/wiki/Wikidata:Project_chat [17:49:40] Oh wow! There's already a lot of discussion there. [17:52:05] lol @ Gerard's "Thanks, but no thanks" [17:53:05] There's a lot of skepticism here. [17:53:15] halfak: well, it's wikidata's village pump. so yea. [17:54:48] the mediawiki fallback chains (https://commons.wikimedia.org/wiki/File:MediaWiki_fallback_chains.svg) would also be a useful thing to consider, since wikidata is already using that to fall back to other languages when displaying labels/descriptions [17:59:38] Lydia_WMDE: the last link in the wikibase section on https://www.wikidata.org/wiki/Special:SpecialPages seems to be missing a proper label... dunno if that's known or not [18:00:25] huh. frisian doesn't fall back to dutch? I would've expected fy -> nl -> en rather than just fy -> en [18:00:41] nikki: looking [18:01:31] nikki: thanks. it should be solved with the next deployment which should be tonight [18:01:51] oh, good :) [18:01:56] Wikidata is getting the code tomorrow only [18:02:00] only test is today [18:03:28] thx hoo [18:16:38] OK some cleanup posted here: https://www.wikidata.org/wiki/Wikidata:Project_chat#Quality_Criteria_for_Building_a_Tool_to_Evaluate_Item_Quality [18:19:02] halfak: All the feedback is well-intentioned, you know ;) [18:19:06] I really like the idea [18:19:25] abian, of course. [18:19:33] :) [18:19:39] halfak: thanks halfak [18:19:59] abian, thanks for your ping here. I'd really like to make progress on this project and it seems like you'd have some good ideas to contribute. [18:20:16] For the time being, let's forget that we're trying to model this stuff and just make a really good quality scale. [18:20:47] The initial models may only look at completeness, but future models can solve constraints or even use external APIs to check values. [18:20:59] So let's not be afraid of making a statement about that. :) [18:22:18] hmm.. completeness is one part of quality.. and someone has developed the gadget to evaluate the item completeness [18:22:39] halfak: Great :D [18:23:19] Glorian_WMDE & abian, we might want to evaluate an item on multiple dimensions. I don't think that's a problem. [18:27:07] halfak: shall we talk about the dimensions that we want to measure then? [18:27:15] Well, that would be harder (even subjective) [18:27:47] abian, I agree. [18:27:53] subjective is totally OK [18:27:59] I think we even want to aim for it. [18:28:15] So long as labels are consistent. [18:28:39] E.g. if one Wikipedian says Item Q### is "D" class, most others would agree. [18:31:51] Then, we could, for example, create metaproperties of weights of gravity (>0, <1) for different deficiencies and reach an agreement on what weight has every property [18:32:46] abian, maybe, but I'd rather we don't put numbers or constraints on anything. [18:33:22] E.g. the "B" class in Wikipedia is summarized by "The article is mostly complete and without major problems, but requires some further work to reach good article standards." [18:33:27] halfak: agree. I guess we should maintain some vagueness [18:36:19] Okay, I was thinking at a very low level [18:38:45] Question, vandalism over these metaproperties would be a problem (it seems so)? [18:39:34] Because... [spam, off-topic] https://www.wikidata.org/wiki/Wikidata:Project_chat#Semiprotecting_properties_by_default [18:40:54] halfak: so the quality grade will be obtained based on measuring multiple dimensions right? [18:42:06] say, we have dimensions like accuracy, completeness, objectivity. The score of these dimensions will be calculated in order to get the grand quality score [18:42:26] Objectivity? [18:42:35] This seems like an implementation detail [18:42:55] okay let's not talk about that now [18:45:31] Glorian_WMDE shared this past proposal with me https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Data_quality_framework_for_Wikidata [18:45:44] Looks like we might adapt some of the concepts here toward a scale. [18:47:44] Lydia_WMDE, do you know what happened with ^ ? [18:51:51] Or, for consistency, a boolean answer could be useful (with inconsistencies/consistent) [19:00:19] abian, we'll be gathering material on this and restarting the conversation on Wikidata:Item_quality. Is it OK if we ping you again to re-engage? [19:06:20] Sure, halfak, and I'm always by IRC, you can ping me when you want :) [19:09:40] Hi all, I have next to no idea how wikidata works but thought you might want to know about https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bureaucrat/83.31.150.132 :) [19:12:24] wtf [19:17:13] Blocked, poor IP :( [20:31:58] an ip-address from Poland. [20:57:14] I just created a new item about a 'new article'. Anyone willing to help add relevant statements? https://www.wikidata.org/wiki/Q28585439 I can't figure out which statements can be added... [20:58:43] sjoerddebruin: You are usually great at finding relevant statements [20:58:54] Aww thank you for mentioning me <3 [20:59:12] ooh, Plaintiff is a property [20:59:18] Sure thing ;) [21:00:21] and defendant, apparently [21:00:30] there’s a query idea, most common defendants [21:01:12] All legal cases involving Donald Trump or his organizations [21:01:23] not enough data, only 51 defendant statements overall [21:01:26] :/ [21:01:36] only a single item twice, Secretary for Justice [21:02:49] There is no way we can add the number "No. 1:17-cv-00458" somehow... :/ [21:02:59] That would be useful.... [21:03:38] catalog code, perhaps? it’s a stretch… [21:03:54] haha, yeah...a bit... [21:04:45] Should https://commons.wikimedia.org/wiki/File:CITIZENS_FOR_RESPONSIBILITY_AND_ETHICS_IN_WASHINGTON_v._DONALD_J._TRUMP.pdf be added as P996? [21:05:49] or as P18? [21:05:56] And what could we use for "United States District Court for the Southern District of New York" [21:06:32] jurisdiction?? [21:06:44] qualifier of P31 and with property 'in' or 'jurisdiction'...? [21:07:27] and P1346? [21:08:01] well...it is still pending... [21:08:09] I know ;-) [21:08:20] the alternative facts will probably win [21:28:05] work for someone: https://ceb.wikipedia.org/wiki/Espesyal:UnconnectedPages [21:37:42] I thought lsjbot had stopped [21:38:43] nikki: I think that him leaving was the classic rage quit [21:39:33] halfak: Maybe we should do a limit scope test for the quality thing? [21:40:36] I have about 200.000 ?item wdt:P31 wd:Q3305213 that could be rated :-) [21:42:09] looks like he left only svwiki [21:45:06] Stryn: Took my bot quite some time to reduce https://www.wikidata.org/wiki/Wikidata:Database_reports/without_claims_by_site/svwiki [21:45:12] And it's still filled with bot crap [21:47:15] nice, I wonder how many of those items are duplicates [21:47:50] ah many of them are connected to ceb link [21:48:18] By same bot ;-) [21:48:56] could you create a https://www.wikidata.org/wiki/Wikidata:Database_reports/without_claims_by_site/fiwiki ? I'm interested to work with them [21:49:44] Stryn: I don't create these reports. Ask Pasleim . [21:49:49] ah [21:49:56] I just process them to reduce them [21:50:06] I got it, good :) [21:50:15] https://petscan.wmflabs.org/?psid=706126 is the Malawi mountains from svwiki in case you're interested [21:50:35] https://www.wikidata.org/wiki/User:NoclaimsBot is one of my bots [21:51:44] lovely name [21:53:49] Stryn: You can find some info about fiwiki at https://www.wikidata.org/wiki/Wikidata:Database_reports/without_claims_by_site [21:55:44] yes I just saw the page [21:56:34] 12104 isn't too bad!