[08:34:09] <wikibugs>	 3MediaWiki extensions / 3MultimediaViewer: Misleading tooltip for "Disable/Enable Media Viewer" - 10https://bugzilla.wikimedia.org/69282 (10Michael M.) 3NEW p:3Unprio s:3normal a:3None When you hover over "Disable Media Viewer" in the footer of MV, a tooltip is shown: "Media Viewer will no longer be...
[10:44:41] <bawolff>	 People are talking about mediaviewer in the session im in and they sound positive!
[11:19:40] <wikibugs>	 3MediaWiki / 3Uploading: SpecialUpload: Use Config instead of globals - 10https://bugzilla.wikimedia.org/69188 (10Andre Klapper) p:5Unprio>3Normal
[13:14:38] <wikibugs>	 3MediaWiki extensions / 3UploadWizard: Wizard refuses to upload images from flickr via http - 10https://bugzilla.wikimedia.org/68981#c6 (10Cometstyles) Its still a problem, when on http (http://commons.wikimedia.org/wiki/Special:UploadWizard), it refuses to upload most images, it goes on a loop, nothing to d...
[13:39:27] <brion>	 my slides: https://upload.wikimedia.org/wikipedia/wikimania2014/9/9d/Video_and_audio_playback_in_a_patented_world.pdf
[14:46:40] <grrrit-wm>	 (03Abandoned) 10Hashar: Jenkins job validation (DO NOT SUBMIT) [extensions/PronunciationRecording] - 10https://gerrit.wikimedia.org/r/152554 (owner: 10Hashar)
[17:17:43] <marktraceur>	 Morning neilk_
[17:18:04] <neilk_>	 marktraceur: ahoy there! :)
[17:18:18] <marktraceur>	 Want to make evil evil plans for UploadWizard?
[17:18:36] <neilk_>	 Yeah ok let's do this
[17:19:41] <marktraceur>	 neilk_: Right. So I think one of my higher goals is to make it so actions taken in the wizard don't need special knowledge of other parts of the code to run - the end goal being to make adding or removing steps, metadata fields, etc. way easier
[17:19:51] <neilk_>	 nod
[17:19:58] <marktraceur>	 Even possible from on-wiki scripts, though I'm not sure we'd want to enable that right away
[17:20:14] <neilk_>	 yeah
[17:20:21] <neilk_>	 so, there are a few things stopping that
[17:20:27] <marktraceur>	 That's at least my goal with the step controller classes (/me listens)
[17:20:29] <neilk_>	 1) configuration is obtained from PHP
[17:21:04] <neilk_>	 2) there's a little bit of separation between model & view but not much
[17:21:11] <neilk_>	 I can't think of anything else
[17:21:18] <marktraceur>	 neilk_: Separation how?
[17:21:18] <neilk_>	 oh wait
[17:21:45] <neilk_>	 well, what I mean is, an "upload" is more than a form field, but less than a real model
[17:21:54] <marktraceur>	 Hm, I guess so
[17:22:18] <neilk_>	 I think you were winding up to say something else though
[17:22:34] <marktraceur>	 I think I would characterize it as being a collection of metadata (like license info, details template calls) as well as an actual file object on the backend
[17:22:47] <marktraceur>	 We spend a very, very brief amount of time with the upload being empty, or in progress
[17:23:03] <marktraceur>	 At least from the code's point of view
[17:23:07] <neilk_>	 ok
[17:24:03] <marktraceur>	 neilk_: I'm not sure why PHP config would be a barrier either :) referencing a global(ish) config object is not terrible, it just means an extra step
[17:24:14] <neilk_>	 marktraceur: it's been a complaint from the community 
[17:24:15] <marktraceur>	 (of adding the PHP variables into the config)
[17:24:30] <marktraceur>	 Yeah, I watched the pd-old-1923 license go in recently...that was pretty weird.
[17:25:00] <marktraceur>	 neilk_: So license configuration could be as easy as adding it to an array of JS objects, probably
[17:25:02] <neilk_>	 I'm not sure what you're referring to, I thought pd-old-1923 was always there 
[17:25:11] <marktraceur>	 Er, no, sorry, it was something else
[17:25:20] <marktraceur>	 pd-old-70-1923
[17:25:25] <marktraceur>	 https://gerrit.wikimedia.org/r/145375
[17:25:26] <neilk_>	 oh right
[17:25:52] <neilk_>	 my thinking was that the people who made the wiki would want to set policies beyond what one could do in a user script :)
[17:26:32] <marktraceur>	 neilk_: How so?
[17:26:42] <marktraceur>	 Like, something more complicated than adding config objects?
[17:27:06] <neilk_>	 marktraceur: well, the people who run the wiki control the Settings.php stuff
[17:27:30] <neilk_>	 marktraceur: I thought that was a natural place to set policies about what sort of content you wanted
[17:27:36] <marktraceur>	 Right
[17:27:54] <neilk_>	 marktraceur: but, it seems there are people who want more control on-wiki
[17:27:58] <neilk_>	 anyway that's a side note
[17:27:59] <marktraceur>	 neilk_: The problem is, right now, that process is unclear and takes some time to accomplish. On-wiki is nearly instantaneous.
[17:28:21] <neilk_>	 yeah it's not really important to design though, as it has to go through JS config anyway.
[17:28:34] <marktraceur>	 True
[17:28:42] <marktraceur>	 Anyway that's a separate discussion
[17:28:44] <neilk_>	 right
[17:29:03] <marktraceur>	 I think at this point I'm out of low-hanging fruit on this road
[17:29:09] <marktraceur>	 I mean, there's still the tutorial step maybe
[17:29:20] <neilk_>	 I'm not sure I have a brilliant plan of attack right now
[17:29:55] <neilk_>	 ok maybe we can talk patterns
[17:30:14] <neilk_>	 like, you were totally right to call out how intertwined the code is. 
[17:30:20] <marktraceur>	 *nod*
[17:30:33] <neilk_>	 and I saw a lot of things which were "feature envy"; at one point Uploads are modifying the Wizard 
[17:30:42] <neilk_>	 I think we can say that is unequivocally bad
[17:30:54] <marktraceur>	 Yeah. There was at least one instance of the UWUI class modifying the Wizard. :)
[17:31:02] <marktraceur>	 I killed it with fire in one of the refactor patches
[17:31:07] <neilk_>	 ok
[17:31:13] <neilk_>	 I think I found something else but maybe that was in yr patch
[17:31:32] <neilk_>	 so, patterns
[17:31:57] <marktraceur>	 neilk_: Maybe I'm not sure what you mean by that
[17:32:26] <neilk_>	 I mean, I reviewed the code and I saw many different ways of communicating between components. I was definitely thrashing around trying to find something sane.
[17:32:49] <neilk_>	 The only thing like events in jQuery circa 2009 was $.trigger, but that requires a DOM element. It's used in a few places.
[17:32:55] <neilk_>	 In other places, callbacks are passed
[17:33:10] <neilk_>	 The GroupProgressBar stuff relies on known properties being polled over and over
[17:33:22] <neilk_>	 all of this seems like it could be cleaner with events
[17:33:27] <marktraceur>	 Yeah.
[17:33:50] <marktraceur>	 neilk_: Do you think those should be OOJS EventEmitter events, or just normal HTML Events?
[17:33:52] <neilk_>	 so what I mean by patterns is, "prefer events to connect components, and maybe callbacks sometimes"
[17:34:17] <marktraceur>	 Hm, I wonder if events are even preferable to promises at some points.
[17:34:31] <neilk_>	 I like the idea of making them EventEmitter events b/c DOM events flow in different ways on different browsers and you need an element for them to work
[17:34:38] <marktraceur>	 Right.
[17:35:32] <neilk_>	 also events are way more testable
[17:35:49] <neilk_>	 EventEmitter style I mean
[17:35:56] <marktraceur>	 Right
[17:36:19] <marktraceur>	 OK, so prefer EventEmitters.
[17:36:30] <neilk_>	 Yeah I was hesitating on adding any tests b/c EE code would be sooo much more testable :)
[17:37:02] <neilk_>	 I haven't played around much with EventEmitter in the browser though
[17:37:19] <marktraceur>	 I'm also trying to make it so there are abstract classes for just about everything I'm making - e.g. the Step controller class has moveTo(), which can be extended, but it means that any Step object will have moveTo and moveFrom and we can more easily add steps that way
[17:38:01] <marktraceur>	 I'll probably do something similar with the models, they'll likely have a getWikitext() function on each
[17:38:15] <neilk_>	 okay - how do we enforce an abstract class in JS?
[17:38:25] <neilk_>	 inherit using OOJS?
[17:38:44] <marktraceur>	 neilk_: Essentially yes
[17:39:11] <neilk_>	 well that just means it inherits from a concrete class that has stubs?
[17:39:23] <neilk_>	 b/c there's no real abstract class in JS as far as I know
[17:39:29] <neilk_>	 not criticizing, just clarifying
[17:39:48] <marktraceur>	 Basically
[17:40:13] <marktraceur>	 neilk_: jsduck has some enforcement for abstract classes, but yeah, there's not really an abstract class.
[17:40:26] <neilk_>	 Yeah, I follow the rule of three - 2nd time copy code, 3rd time make a class. UploadWizard was pushing the boundaries with four :)
[17:41:01] <neilk_>	 ok some other low-hanging fruit
[17:41:22] <neilk_>	 well, not low-hanging fruit, more like "this is obviously wrong"
[17:41:26] <neilk_>	 Firefogg
[17:41:31] <marktraceur>	 Low-hanging fruit for planning.
[17:41:34] <marktraceur>	 Oh, yeah.
[17:41:41] <neilk_>	 I don't know if anyone still uses this. Surprisingly it still works.
[17:41:48] <marktraceur>	 neilk_: I think we wanted to do a few weeks of data gathering to see if anyone uses it
[17:41:58] <marktraceur>	 I might buy some confetti and hook it up to the EventLogging database
[17:42:01] <neilk_>	 We'd need to instrument the code
[17:42:07] <neilk_>	 ...confetti?
[17:42:14] <marktraceur>	 If someone uses it, drop some confetti
[17:42:18] <neilk_>	 ahaha
[17:42:36] <marktraceur>	 neilk_: My point being, I'm pretty sure it's not used anymore :)
[17:42:38] <neilk_>	 like, on-page JS confetti? :)
[17:42:40] <marktraceur>	 We can definitely look.
[17:42:49] <neilk_>	 OUR 100,000th CUSTOMER
[17:42:49] <marktraceur>	 No, like, blanket our corner of the office in confetti
[17:42:52] <neilk_>	 got it
[17:43:03] <neilk_>	 ok next
[17:43:13] <neilk_>	 the whole Flickr thing needs to be killed with fire 
[17:43:26] <marktraceur>	 Agreed, but there's more need for instrumentation there
[17:43:41] <neilk_>	 not much need as it's disabled except for admins
[17:43:46] <marktraceur>	 Well
[17:43:48] <neilk_>	 i think they'd go for a separate flow
[17:43:57] <marktraceur>	 There's a difference between "not much need" and "not technically used right now"
[17:43:58] <neilk_>	 maybe we should ask someone to bring this up an Wikimania
[17:44:08] <marktraceur>	 If we could make it better, maybe non-admins would use it more
[17:44:10] <neilk_>	 OK, well, here's my big problem with UW as designed
[17:44:14] <marktraceur>	 (after enabling it)
[17:44:28] <neilk_>	 the model is "be ready for any kind of upload with any sort of data at any moment and batch it all together"
[17:44:30] <neilk_>	 this is just dumb
[17:44:48] <neilk_>	 it imposes more work on the uploader if (as in the common case) things are related
[17:44:53] <marktraceur>	 s/dumb/too smart/ but same thing :)
[17:45:04] <neilk_>	 yes, it wraps around there :)
[17:45:24] <neilk_>	 so maybe making flows more abstract gets us closer to more specialized flows?
[17:45:54] <marktraceur>	 Sounds right to me
[17:46:27] <marktraceur>	 We can have the normal step controller classes, and subclasses for different types of upload sessions.
[17:46:37] <neilk_>	 okay
[17:47:04] <neilk_>	 there's another thing which I kind of regret - for custom licenses, it parses wikitext and then attempts to find out if there is a real license there
[17:47:16] <neilk_>	 that wasn't really a policy decision I just threw that in one afternoon
[17:47:20] <marktraceur>	 Category:License tags
[17:47:25] <neilk_>	 yeah
[17:47:29] <neilk_>	 that came up the other day with redirects
[17:47:31] <marktraceur>	 I'm familiar, I fixed a bug in it yesterday :)
[17:47:34] <marktraceur>	 Tadaa
[17:47:44] <neilk_>	 maybe it's just a dumb idea
[17:47:53] <marktraceur>	 I dunno...
[17:47:55] <neilk_>	 Erik was against that :)
[17:48:01] <marktraceur>	 It's another gate between the hordes of newbs and the admins
[17:48:36] <neilk_>	 Well, if we make it easier to have newb-flow and expert-flow then maybe that's not so bad. Expert-flow can be limited to certain kinds of accounts
[17:48:41] <marktraceur>	 True
[17:48:48] <marktraceur>	 Autoconfirmed or some such.
[17:49:00] <neilk_>	 the license tag thing can go very wrong as it's recursive without any time limits
[17:49:04] <marktraceur>	 Then we can only load CC-BY-SA-3.0 for others
[17:49:25] <marktraceur>	 Hm, yeah
[17:49:40] <neilk_>	 well I wasn't saying limit newb-flow to CC-BY-SA - it should just not have wikitext licenses
[17:50:07] <neilk_>	 ok this is maybe getting too extensive
[17:50:24] <marktraceur>	 Right
[17:50:29] <marktraceur>	 Extensive how?
[17:50:42] <neilk_>	 I mean, we're contemplating long term plans
[17:50:53] <marktraceur>	 True
[17:50:58] <marktraceur>	 Back to patterns, I suppose.
[17:51:24] <neilk_>	 Ok tell you what I am still at my house - I am going to my coworking spot and I'll start to write something up
[17:51:31] <marktraceur>	 OK!
[17:51:38] <marktraceur>	 I'll be around
[17:51:42] <neilk_>	 we've already talked for an hour but maybe I should have made the agenda clearer
[17:52:00] <neilk_>	 ok ttyl
[17:52:27] <marktraceur>	 Bye!
[19:12:24] <wikibugs>	 3MediaWiki extensions / 3MultimediaViewer: Browser window gets black with out exit when the browser is offline - 10https://bugzilla.wikimedia.org/66599#c5 (10Fomafix) 5REOP>3RESO/WOR Now the MultimediaViewer shows a error message with a close button. RESOLVED and WORKSFORME  Bug 66598 is still not fixed,...
[19:18:24] <wikibugs>	 3MediaWiki / 3Uploading: When $wgAllowCopyUploads and $wgCopyUploadsFromSpecialUpload are true, the filename of the source is no longer copied into the "destination filename" field - 10https://bugzilla.wikimedia.org/59095#c1 (10Umherirrender) Works for me. Can you test if this is still a issue?  Did you see...
[21:04:12] <wikibugs>	 3MediaWiki / 3File management: During swift failure, MW will still move image pages despite not being able to move the file causing inconsistency - 10https://bugzilla.wikimedia.org/69312 (10Bawolff (Brian Wolff)) 3NEW p:3Unprio s:3normal a:3None Same as Bug 69311, but for fixing the underlying bug in...
[21:23:41] <grrrit-wm>	 (03CR) 10Neilk: "What's the rationale here? You seem to be trying to make something that many things can inherit from, so it has few features. But if so wh" [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/121308 (owner: 10MarkTraceur)
[21:24:27] <grrrit-wm>	 (03CR) 10Neilk: "To clarify - I was wondering what uw.model.Model.js is for." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/121308 (owner: 10MarkTraceur)
[21:31:36] <grrrit-wm>	 (03CR) 10MarkTraceur: "There will be more subclasses later - for licenses and uploads in particular, and probably for metadata templates (information, at first)." [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/121308 (owner: 10MarkTraceur)
[21:36:18] <grrrit-wm>	 (03CR) 10Neilk: "I understand but what is it that they have in common that warrants a common base class?" [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/121308 (owner: 10MarkTraceur)
[21:42:23] <marktraceur>	 Hm, maybe you're right.
[21:43:37] <grrrit-wm>	 (03CR) 10MarkTraceur: "getValue will be shared by every metadata model, but I guess that should be the base class, not just Model, because uploads won't have tha" [extensions/UploadWizard] - 10https://gerrit.wikimedia.org/r/121308 (owner: 10MarkTraceur)
[22:04:56] <neilk_>	 marktraceur: yeah, so we don't keep pingponging on the gerrit change - a model for models just seems overly abstract to me. And, even if there is a useful common idea of 'getValue' (IDK, maybe put encoding there?? I don't get it yet) that's not a model per se
[22:06:57] <marktraceur>	 Yeah, that makes sense.
[22:07:01] <marktraceur>	 I can take out the base class