[00:19:37] CindyCicaleseWMF: why have you not applied for a wikimedia vhost yet?! [17:19:40] legoktm, say your ping from yesterday. It's not really the JSON I'm worried about. it's cramming the abstraction into page/revision form that is difficult. [17:20:19] But I don't think it'll be *that* difficult. We'll just have to drop a thing that I thought would be cool from a UX perspective or do *really strange* things with pages and revisions. [17:41:28] halfak: Sounds interesting. Could you elaborate? [17:42:09] OK so, for JADE, a judgement is submitted for a wiki thing (e.g. a revision, a user, a page, etc.) [17:43:03] Under one formalization of this, many judgements can be submitted for a single thing and users can endorse judgements as they see fit (ala a straw poll) [17:43:18] Consensus would be represented by flagging a judgement as "the best one" [17:43:51] Under the page/revision formalization, judgements have versions and the most recently applied judgement for a thing represent consensus. [17:44:22] In the first formalization (endorsements), a revert war is represented by flipping a pointer from one judgement to another. [17:44:49] In the second formalization, a revert war is represented by submitting a totally new judgement that matches some historical version of the judgement. [17:45:20] The first formalization is nice because it represents the real data better IMO. Unlike pages, judgements don't //build on top of each other// -- they merely differ. [17:45:38] Revisions generally build on their parent revision. [17:45:54] In the end, I think it's OK to drop this from the abstraction. [17:46:16] And cram it into page/revision form. I'll be making a proposal to that extent. [17:58:22] Krinkle, ^ [19:10:01] halfak: the fundamental question is, what part of the data you want pagelike behavior for? (search, versioning, oversight, revert etc) [19:10:44] e.g. in FlagRev the page content is pagelike (obviously) but the quality data (reviews) is not [19:11:00] there is nothing inherently wrong with that, it's a design decision [19:11:50] so you could choose to put judgements into page content and judgements on judgements not [20:38:46] tgr, I don't follow. [20:39:08] I don't want page-like behavior but I do want mediawiki integration so I am seriously considering cramming the abstraction into pagelike behavior. [20:39:26] What's FlagRev [20:39:51] And what do you mean by "judgements on judgements not"? [20:46:53] halfak: so, you have a set of jusgements? and all judgements for a single wiki-thing would share a page? and the "best one" would have a marker, which can be changed by editing that page? [20:47:31] DanielK_WMDE_, that's sort of a hybrid between both proposals. [20:48:13] halfak: the judgements themselves also get updated, right? [20:48:21] DanielK_WMDE_, no. never [20:48:39] The updates would happen to endorsements or preference. [20:48:52] so, a user will never get re-evaulated? [20:49:00] They might change their endorsement. [20:49:21] Well, evaluating a user doesn't make sense unless it has a point in time. [20:49:33] Try not to think of users. Think of revisions instead. [20:49:51] well, you seid that users and pages get evaluated, not just revisions. but pages change, and so do users, i i'd expect that evaluation (judgement) to also change [20:49:58] the formalization of a user/page is very complicated and has little to do with this problem. [20:50:30] DanielK_WMDE_, right, that's why I'm asking you to not worry about that aspect because that would be an example of a "thing" changing. [20:50:56] A "thing" should always be static in time. So a user might get an evaluation at a point in time. The user at that point in time never changes. [20:51:03] it just seems strange to me *not* to think of that :) [20:51:05] So revisions are a nice easy thing to work with for now. [20:51:10] But I have to run to a meeting anyway [20:51:10] *sigh* [20:51:14] It's a separate problem. [20:51:20] See I have been explaining how we will work with that [20:51:29] But I'd really like to discuss MW integration instead. [20:51:39] maybe it shouldn't be. I'm asking to avoid the good old x/y problem [20:51:52] x/y problem? [20:51:56] but let'S chat about this when there is more time :) [20:52:08] halfak: http://xyproblem.info/ [20:52:45] DanielK_WMDE_, maybe you want to ask about all of the other design bits too :P [20:53:16] halfak: "mediawiki integration" doesn't really make it clearer what you want [20:53:35] tgr, oh if you read the scrollback, I'm talking about risker's checklist. [20:53:50] Isn't that what you were talking to me about? [20:53:52] the usual advice is that if you put data into MediaWiki that is in some sense "content", you should give it "pagelike" behavior [20:54:05] https://en.wikipedia.org/wiki/User:Risker/Risker's_checklist_for_content-creation_extensions [20:54:07] (use the Content/ContentHandler classes) [20:54:24] it's up to you to decide whether that applies to your case [20:54:31] I'm talking about that, yes [20:54:51] Yes. Curation and suppression do apply to us. [20:54:59] Yes. Page-like behavior is limiting. [20:55:17] But that's fine. It's a potential tradeoff we'll need to make. [20:55:24] it doesn't sound like your "judgement on judgement" data (votes on which is the consensus judgement) is really "content" [20:55:27] And yes I've already been directed to ContentHandler. Thank you. [20:55:33] but again that's up to you to decide [20:55:48] tgr, I don't know what you are talking about with Judgement on Judgement. [20:56:30] you will have two layers, judgements and people "voting" on what the right judgement is, right? [20:56:36] or an admin selecting it or whatever [20:56:38] Not voting. But yes people. [20:57:23] tgr, think of it like a strawpoll. That's a bit more like voting, but the result of a consensus discussion happens the same way. [20:57:33] so you can make the judgements themselves Content and the pointer to the currently accepted judgement not Content (just a plain DB column) if yu want [20:57:57] and then you don't get the problem with reverts that you mentioned [20:57:59] E.g. I think we should "foo" ... '''support''': Foo is good!, '''oppose''': foo is bad :( [20:58:29] basically what I'm trying to say make everything a page and make nothing a page are not your only options [20:58:36] tgr, would changing that pointer then get nice integration into mediawiki's curation mechanisms? [20:58:53] tgr, fair point. [20:59:02] Not sure I see the value in the hybrid approach. [20:59:05] no, but do you really need it? [20:59:12] But it's good to note that there is a hybrid approach [20:59:15] Yes tgr. [20:59:20] See Risker's checklist. [20:59:21] again, reviews in flagged revisions are not comment, and no one complains about that [20:59:33] E.g. I could vandalize by changing all of the preferred judgements to "damaging" [20:59:35] they go into the log and that's all [20:59:52] tgr, I don't know how reviews in flaggedrevs works. [21:00:01] Is it just the "patrolled" flag? [21:00:14] no, but similar to that [21:00:23] It seems that this right is limited to a small subset of trusted users. [21:00:29] halfak: The first question I have here is what exactly is a "judgement"? [21:00:32] just more complex, with multiple levels and a comment and whatnot [21:00:39] anomie, edit 235726342 is damaging [21:00:54] Or edit 235726342 is not damaging [21:00:59] granted flaggedrevs limits reviews to trusted users so vandalism is not a problem there [21:01:01] You might group together schemas too. [21:01:01] halfak: So basically a boolean damaging/not damaging? [21:01:07] Not always a boolean [21:01:15] Arbitrary schema [21:01:35] so yeah if you want to expose it to all users then Risker's advice is probably valid [21:01:52] "Arbitrary schema" doesn't tell me anything. What can it be if it's not a boolean? [21:02:00] Even trusted users can dox -- especially if their account is compromised. [21:02:06] anomie, how about a list of strings? [21:02:25] That's what we have for draft topic prediction. [21:02:37] halfak: User-supplied strings, or predefined strings like "damaging"? [21:03:01] Predefined strings. [21:03:10] like "stem.mathematics" [21:03:38] So no way for a malicious user to put in "halfak eats kittens". Good. [21:04:09] Oh yes there is, anomie. [21:04:15] Put it in the comment. [21:04:28] Where does the comment show up? [21:04:36] Depends on how we implement the system. [21:04:45] But let's say, "to users" [21:05:13] Right now, I'd like it to show up anywhere recentchanges show up. [21:05:27] because I want to enable curation/suppression. [21:05:35] Which is why I showed up in this channel :) [21:06:34] halfak: IMO the rule of thumb re: doxing is: anything that includes freeform text should either be a page or a log entry (which also has all the patrol/suppression mechanisms) [21:07:08] tgr, yes. See risker's list I linked to earlier. [21:07:11] flaggedrevs puts review comments in the log IIRC and shows the last one for a given revision in its custom interfaces and the page history [21:07:12] Here it is again: https://en.wikipedia.org/wiki/User:Risker/Risker's_checklist_for_content-creation_extensions [21:07:41] halfak: My impression is that these judgements aren't very different from change tags, you apply some of a predefined list of things to a revision. For that part of it, proper integration would be to log each judgement into Special:Log. The comments you're talking about, if they're not just comments on the log entry in Special:Log, make it more problematic. I haven't asked you about "endorsements" yet. [21:08:23] anomie, inlike change tags they are not limited to changes. they have more structure. They are applied by humans arbitrarily. [21:08:48] "more structure" as in these comments you're talking about? [21:08:56] No. not the comments. the judgements. [21:09:14] Oh they'd also be applied historically. [21:09:32] If you're not clear on what JADE is, I'd suggest starting with [[:mw:JADE]] [21:12:45] FWIW, I'm just about to propose dropping endorsements because it will make MW integration easier and it's hardly at the top of our need-to-have list. [21:13:12] I'm working on a post now about how I see integration with MediaWiki via Content Handler taking place. [21:17:50] That helped. So yeah, your judgements are content and would need to be page-like. [21:18:00] ha. [21:18:35] halfak: Does each user really need to make their own judgement, or should judgements be collaborative content? [21:18:52] anomie, under no proposer were they not collaborative content. [21:18:57] *proposal [21:19:33] The "A user may only supply one judgement per artifact" makes it sound like judgements belong to a user. [21:19:39] on https://www.mediawiki.org/wiki/JADE/Schema [21:20:32] halfak: I see. Interesting. I suppose then that that would be in a namespace that ORES ignores. Otherwise you get recursion :P [21:20:52] But I want to judge your judgement! [21:22:37] Krinkle, someone can vandalize in judgement space! [21:22:45] Not a recursive problem [21:23:10] Maybe, but do you want infinite recursion? Or NS_Judgement and NS_META_Judgement? [21:23:16] anomie, the way that would work out in practice would be via endorsements. but that's an old proposal now. [21:23:17] :D [21:23:30] Krinkle, there would be finite recursion. [21:23:47] Because if you judge an edit poorly, then I judge you judgement poorly, that's only two. [21:23:49] But I want to judge your meta-meta-meta-judgement! [21:23:55] You might judge my judgement of your judgement poorly. [21:24:06] But then that would be three. [21:24:20] And they'd all exist side by side. [21:24:23] It sounds like each judgement would address a revision, not a page, so I guess the main key for this namespace would be a revision ID instead of a page title. E.g. Judgement:1234 instead of Judgement:Main_Page, right? [21:24:37] Ah, I see. [21:24:44] Krinkle, would be more like JADE:Revision/1234 [21:24:45] They'd be stored within there. [21:24:50] Yeah [21:24:57] But for damaging/not-damaging it would be JADE:Diff/1234 [21:25:09] because JADE:Revision/1234 would refer to a single version of the page. [21:25:15] Judgements of revisions are things like article quality. [21:25:33] Judgements of diffs include "damaging", "goodfaith", "edittype", etc. [21:26:02] I'm starting to talk myself into re-considering wikibase for this. [21:26:15] But that's a big ol' ontological hammer. [22:28:48] Ooooh that sounds interesting [22:29:00] Having structured data for revisions would definitely be interesting [22:33:55] halfak: Also I disagree that article quality is entirely a page property. I think it should be tracked on a per-revision basis [22:34:24] Although conceptually it is a property of the content of the page after the revision has happened, whereas damaging/goodfaith is a property of the changes that hte revision makes (the diff between it and the previous revision) [22:42:09] RoanKattouw: (Re: article quality per-revision) I think that's what halfak said as well. We'd store it as data in Revision/1234 instead of Diff/1234, but either way not as Page/1234. [22:42:23] Aha I see [22:42:25] Sorry I misread [22:42:31] np :) [22:42:32] +1 :) [22:42:34] You're right that that's exactly what he said [22:43:25] RoanKattouw, would be interested in what you think about the best way to track this. [22:43:45] Before worrying too much about curation, I wanted a tight, specialized services with MW integrations. [22:44:02] So I think the way Flow integrates with RC, history etc is not something you should emulate [22:44:05] Now after thinking about curation, I think cramming the abstractions into pages make sense. [22:44:06] Because of how fragile it is [22:44:14] You should try to store things in as close to a page/revision model as possible [22:44:21] Roger that. [22:44:31] Now we're debating whether or not to try to work with wikibase. [22:44:31] Ideally using ContentHandler and actual pages/revisions, because then you get all the history/moderation infra for free [22:44:40] Or just do JSON + ContentHandler [22:44:45] The number of successful suppression implementations is like 15 [22:44:45] *1.5 [22:44:50] Where MW core is 1 and Flow is 0.5 [22:44:55] Hmm good question [22:45:05] I don't know enough about Wikibase to make an intelligent recommendation there [22:45:27] Yeah, also remember there is still a lot of flexibility within pages/revisions. The only assumption is addressability by title from UI. The page rendering itself can be different. Just think about File and Category pages (or don't, becuase those aren't pretty examples). Newsletter is a better example. [22:46:12] Rendering, edit and diff interface can be anything you want. The main benefit is that all the page-things (including the ones you don't think about) will have a sensible default that works with everyone's workflows. [22:47:07] what would be the benefit of using wikibase? [22:47:35] tgr, rendering and editing is provided. Ontology construction is built in. [22:47:44] I don't want a full ontology [22:47:59] But it would be nice to be able to have a little flexibility. Feels like overkill but it's on the table. [22:48:27] Oh one other advantage of Wikibase is federation and client notification. [22:48:45] do you really want a community-editable ontology? [22:48:48] that would allow us to make JADE a separate instance while still allowing all the nice curation bits [22:48:53] tgr, kinda not. [22:49:17] that's really great for ontologies which try to describe the real world, as that stuff is too hard to get right to leave it to developers [22:49:19] * halfak imagines "damaging: spaceship" [22:49:40] for ontologies describing your software schema, it doesn't make as much sense [22:49:46] tgr, I agree. The way we have envisioned jade is that schema changes (or new schemas) would go through code review. [22:50:42] Another advantage to Wikibase is federation and client notification. We could have a central "wiki" that stores judgements and send notifications out to all the relevant client wikis. That notification system is designed with curation in mind. [22:50:53] I'm not sure I want a JADE namespace in every Wikimedia Wiki [22:51:00] T182475 is somewhat relevant [22:51:00] T182475: Handling of structured data input in MediaWiki APIs - https://phabricator.wikimedia.org/T182475 [22:51:23] that's the thing you really want IMO, the ability to generate edit interfaces based on some data schema [22:52:07] wikibase happens to have a (very limited) version of that, specific to their own schema, but instead of reusing that, it should just be done more genericly [22:52:38] this is something that will come up with multi-content revisions giving extensions easy access to per-page structured data, I'm sure [22:52:38] tgr, that sounds interesting to me. [22:52:46] so JADE is not the only one that will need it [22:54:38] for notification, maybe https://www.mediawiki.org/wiki/User:Daniel_Kinzler_(WMDE)/DependencyEngine is generic enough that this will fit into it [22:55:18] I have no idea how that's implemented in wikibase so maybe I'm just not understanding the complexity though [22:55:25] Notice: Undefined variable: text in /srv/mediawiki/php-1.31.0-wmf.12/includes/parser/Parser.php on line 5774 [22:55:29] OK this is interesting. [22:55:33] tgr: it'S not implemented. it [22:55:38] ...it's a pipe dream. [22:55:49] it's something i want, not something we have [22:55:54] * halfak needs to not get stuck on pipe dreams. [22:55:59] Damn free text fields! [22:56:00] DanielK_WMDE_: I mean how federation is implemented [22:56:11] If we didn't have those we wouldn't have such an issue with curation. [22:56:18] or whatever the thing is that makes the other wikis update when Wikidata is edited [22:56:38] you mean change propagation? we use "federation" for repo-repo functionality, not for repo-client functionality. [22:56:53] yeah, my bad, I meant that [22:58:14] tgr: https://phabricator.wikimedia.org/diffusion/EWBA/browse/master/docs/change-propagation.wiki [22:58:22] yay, documentation :) [23:12:10] Notice: Undefined index: time in /srv/mediawiki/php-1.31.0-wmf.12/extensions/Flow/includes/Formatter/AbstractFormatter.php on line 70 [23:12:58] Notice: Exception doing lazy updates: exception 'Exception' with message 'Thread::splitIncrementFromSubject: thread subject has no increment: '