[18:04:29] dr0ptp4kt: can't join the hangout (full) [18:04:52] hit refresh on the calendar invitation and try again? [18:05:10] dbrant: i guess there *are* ten of us, maybe that's the new old limit [18:05:26] dbrant: i'll ask baha if he can leave when he's done so you can join [18:06:18] halfak: Looking at bman's demo of Extension:WikiLabels at CREDIT, it looks like part of "productize ORES training tools" is done already? [18:06:52] dbrant: try now [18:07:03] dr0ptp4kt, Danny's audio is broken. [18:07:07] Extremely soft. [18:07:07] office mic is quiet [18:07:36] for me it's ok but with echo [18:07:47] better [18:07:47] extremely hard for me to hear danny as well [18:07:47] Very very quiet for me [18:07:50] on the youtube stream [18:07:56] its louder on the hangout now [18:07:59] I can hear it now. [18:08:05] better now [18:08:08] Sounds great now! [18:08:11] goo [18:08:12] d [18:08:13] sounds good [18:08:19] sounds good now! [18:08:21] good now [18:08:22] Good [18:08:24] good! [18:11:00] !!! I didn't know that bmansurov was demoing [18:11:05] RoanKattouw, ^ [18:11:23] halfak: https://www.mediawiki.org/wiki/Extension:WikiLabels [18:11:48] RoanKattouw, thanks, i knew he was working on the extension, but I thought that work had stalled [18:11:51] Happy news :) [18:11:58] He did say it was a spare time thing etc [18:12:02] classic demo unicorn [18:12:04] I'll ask him later what its status is [18:12:17] The demo sounded like it was almost prod-ready. [18:12:21] But I like that the theme of my team's current project seems to be "oh $person has already done 80% of $thing" [18:12:28] Is there a recording of CREDIT? [18:12:33] halfak: yes [18:12:52] halfak: the youtube thing can be replayed [18:12:54] got it [18:13:23] * halfak watches [18:13:51] Hey! Do we write these awesome presentations up anywhere? (Aside from the Etherpad?) [18:13:55] * melodykramer thinks [18:14:06] \o/ [18:14:17] Woo for Special:WikiLabels [18:14:18] melodykramer: not really so far. it's been more like x spoke about y on wikitech-l. but could do better with that! [18:14:31] https://en.wikipedia.org/wiki/User:DBrant_(WMF)/sandbox [18:14:41] matt_flaschen, a big project will be moving the backend [18:14:42] I volunteer to help write these projects up for a wider audience, with the help of the speakers. [18:14:43] :) [18:15:02] Deskana: bold! [18:15:03] But this is great to see! [18:15:05] (If there's interest.) [18:15:07] niiiice [18:15:10] Thanks for the demo of Wikilabels bmansurov :) [18:15:21] ;) [18:15:22] Whoops, I accidentally reverted Deskana's edit. [18:15:26] Also, notifications on mobile?! Everyone's doing things with my team's software and nobody tells me anything :P [18:15:43] That's awesome. [18:16:19] Thanked [18:17:12] dbrant, are you wrapping anything on the server, or using the standard Echo API? [18:17:23] that's cool. [18:17:23] dbrant, this is really cool. [18:17:28] I love the idea of a passive reader getting pushed out interesting material / notifications. Nice work dbrant [18:17:29] dbrant: This is awesome! How much of this did you already have when we had a meeting about Collab/Android collaboration on Friday? :D [18:17:34] dbrant: lovely [18:17:34] dbrant that looks awesome, I want that [18:17:43] dbrant: Neat! :-D [18:17:46] thx all! [18:17:52] I'll channel musikanimal for a minute and point out that talk page notifications for mobile editors are important [18:17:56] very nice :) [18:17:58] dbrant: Can I receive notifications as a non-editor / contributor? Or do I have to contribute to receive them? [18:18:13] hehe I was thinking that! [18:18:14] RoanKattouw: I had the beginnings of it ;) [18:18:17] very nice demo :) [18:18:53] melodykramer: notifications can include things like messages that others leave on your Talk page, or when your name is mentioned in other conversations, etc. [18:19:08] melodykramer: you do need to be logged in with your account, however. [18:19:15] ah, gotcha. [18:19:20] coreyfloyd ^ [18:19:21] musikanimal: I may have beaten dbrant over the head with that a bit on Friday :) [18:19:33] melodykramer, right, you don't necessarily have to be an editor, though many of the notifications are only relevant for editors. [18:19:34] dbrant: that demo was really cool - what are your thoughts about feature parity with notifications on desktop, in general? [18:19:42] matt_flaschen: just the standard API [18:19:53] I was thinking more about people who might want to do something like, "Get notified if article X receives a lot of traffic" or "Tell me if musician X's bio is changed." [18:20:06] non editors who still want updates on content [18:20:15] (kind of related to musikanimal's / RoanKattouw's question ;) [18:20:16] dbrant, even better, we were hoping removing links from the notification body would make this kind of thing easier. [18:20:55] dr0ptp4kt: 👍 [18:21:06] melodykramer, first one could potentially be added, second one is watchlist, which is not currently integrated with notifications but potentially could be (this has been discussed a bunch but is not resolved) [18:21:37] HaeB: I would love to have feature parity with desktop notifications. The current "obstacle" that I see with this is that it's not Push notifications. [18:21:43] very cool SMalyshev [18:21:52] milimetric: thank you :) [18:21:53] melodykramer: The jargon for what you're talking about appears to be "reader notifications" [18:22:28] that is super cool too [18:22:29] wow [18:22:43] The second one is also relevant for edits. A lot of people would probably appreciate having a mini-watchlist they got notifications for. Probably blocked on multiple watchlists. [18:22:45] SMalyshev: Nice demo! One cool thing you could look into doing is generate graphs that are copy-pastable into VisualEditor (which is hopefully just a matter of generating the Parsoid HTML for the graph) [18:22:49] also relevant for editors. [18:23:13] yurik hasn't clicked on the states but it shows the state's governor's name if you do [18:23:30] RoanKattouw: I'm not super-familiar with how VE handles such matters but I don't see why not [18:23:31] forgot :( [18:23:48] that particular projection made Alaska huuuuge :) [18:23:51] it's ok, I got your back, it's so cool to get these out [18:24:09] * RoanKattouw did not realize Alaska had an independent governor [18:24:18] bd808: that's the standard projection, it makes north huge [18:24:46] RoanKattouw: yeah I didn't know to, but he left the party and now they have non-partisan governor [18:25:42] * bd808 blames Mercator for weird importance of North America [18:26:32] * marktraceur points at the West Wing episode with the "Cartographers for Social Justice" [18:26:38] bd808: C16 politics. :-) [18:26:38] lol [18:27:32] https://www.jasondavies.com/maps/waterman-butterfly/ [18:27:43] it preserves angles which is nice, but it gives a very skewed sense of area [18:28:30] Preserving angles is great if you're navigating a ship (what it was designed for), but pretty much irrelevant to everyone else. [18:29:01] jgirault: I like neartitle functionality [18:29:01] Also pretty useful for figuring out if you're in the western US or Canada. [18:30:43] marktraceur: You can basically do that with numbers, right? lat < 49 vs lat > 49 [18:30:55] I guess so [18:31:09] Modulo Vancouver Island, Lake of the Woods, etc etc [18:32:34] jgirault: The maps on search results is neat! What's our path to getting that into production? [18:34:05] Making it a beta feature to get some feedback would be nice. [18:37:19] ottomata: Could you increase the size of your windows/font? It's not very readable from here [18:37:28] http://thetruesize.com/ <-- this is if you want to know the true size of countries on the map [18:38:13] RoanKattouw, ottomata : +1, text is unreadable [18:38:43] Just about readable I guess [18:38:51] SMalyshev: nice. that's fun to play with [18:38:52] Oh that's better [18:38:57] better! [18:38:59] RoanKattouw: better? [18:39:08] Yup, go ahead [18:39:14] * RoanKattouw is excited about this demo and doesn't want to miss it [18:39:44] really like the falcon image too. [18:41:31] I really love all of these demos. Do we invite potential dev contributors to watch? [18:42:17] Deskana Kartographer needed to be deployed to Wikipedias. Now that is, the API is available, so.... it's really not that much to make it happen. [18:42:44] melodykramer, definitely. This is public, everyone welcome. [18:42:47] for people who want to try it on their own... https://meta.wikimedia.org/wiki/User:Jgirault/global.js [18:43:01] matt_flaschen: Is there currently any outreach other than listserv notification? [18:43:28] melodykramer, don't know. I thought you meant 'Should we invite'. [18:43:32] melodykramer: come to think of it, i wonder if we could tweet/fb it out in addition to the other mailing lists. i can't recall if we've done that much [18:44:00] +1, a quick post to wikipedia weekly would help for sure [18:44:41] couldn't hurt. But if we identify folks who are likely to contribute more (or might need a project to wrap their heads around) this seems like a really, really good entry point. I would also recommend linking to the Etherpad in YouTube so folks can see notes / where to go next. [18:45:04] The offset thing is extremely cool. [18:46:12] brendan_campbell: ^^ possible to add that? [18:46:24] ja matt_flaschen, consuming like that directly from kafka using a kafka client in prod is available now [18:46:29] just no public socket.io yet [18:46:43] Sorry I missed that, what's the offset thing? [18:46:44] nice! that's helpful for mediawiki [18:46:46] +1 for sub-phrase ebernhardson [18:46:51] ottomata: the longtime dream of searching the entire edit history (cf. "diffsearcher" https://blog.wikimedia.org/2011/11/21/do-it-yourself-analytics-with-wikipedia/ ;) [18:47:01] RoanKattouw, memory, so you can resume later without gaps after the client disconnects. [18:47:17] Oh yeah that's great [18:47:24] dr0ptp4kt: I could add the Etherpad link to the YouTube description, no problem. Should I? [18:47:34] with every message you get the offset that message was at, so you can safe how far you got and resume [18:47:34] I caught the tail end of ottomata saying that he wasn't sure how much history they'd store [18:47:40] RoanKattouw: ^ [18:47:43] Nice [18:47:51] Yeah resume without loss is a very nice feature [18:47:51] brendan_campbell: yeah. please [18:47:58] Yeah, he said both the filters and memory were To Be Determined, but it's very cool even as a prototype, and we'll see. [18:48:07] ebernhardson: I vote for sub-phrase, very cool [18:48:13] yeah, we're not really sure which of the existing kafka clusers would serve this, right now neither really are good fits for exposing to the internet [18:48:39] theoretically if we had a big enough cluster we could store everything [18:48:44] not sure how kafka would scale with that [18:48:56] lots of unknowns here [18:48:57] Thank you all. This was great, and really helped me wrap my head around a few things. [18:49:03] thanks all! [18:49:13] ottomata, probably don't need permanent memory. Is that what you're referring to by 'store everything'? [18:49:17] Even a week should be plenty. [18:49:39] Unless it's supposed to replace dumps [18:49:46] milimetric: the difference is a huge change in resource requirements, for example enwikisource takes 122mb of jvm heap per copy, sub page is ~180mb, and subphrase is ~380mb. Per wiki this doesn't seem so bad, but multiplied by all the wikis we end up talking about a 200GB difference in jvm heap used. [18:50:06] matt_flaschen: naw, it won't replace dumps. we may use this data to replace dumps, but it wouldn't come directly from kafka [18:50:14] What about the GSoC projects? I thought those were being demoed here. [18:50:14] we will import all of this into Hadoop [18:50:19] that will have a permanent memory [18:50:31] milimetric: but yea, i really would like to get subphrase, it certainly has the highest recall improvement [18:50:34] and milimetric and others are working on building a big mediawiki history database that works on hadoop well [18:50:35] ebernhardson: I know man, but the heart wants what the heart wants [18:50:42] Yaron, it's not at https://etherpad.wikimedia.org/p/CREDIT . [18:50:45] that may be augmented by events [18:50:46] Yaron: not sure. Niharika, next CREDIT ? [18:50:55] :) jk, I totally think both sub-page and phrase are great :) [18:51:19] Yaron: they're certainly welcome! (cc Niharika ) [18:51:26] dr0ptp4kt: Yaron: I guess most of the students chickened out. Hopefully at next CREDIT. [18:51:36] Thanks to all the presenters. Really great work. [18:51:40] Also the time doesn't work for some. [18:51:49] Niharika: were there any GSoC projects demoed? [18:51:51] Niharika: maybe these demos will be good encouragement :) yeah, those timezones, that's a tough one [18:52:39] i gotta eat something. ttyl [18:52:56] melodykramer dr0ptp4kt matt_flaschen there is e.g. https://twitter.com/mediawiki where *some* of the past showcases were promoted [18:53:01] laters, thanks dr0ptp4kt! [18:53:04] Yaron: Nope. [18:53:09] Doesn't seem so. [18:53:30] and https://www.facebook.com/MediaWikiProject/ [18:53:30] thanks HaeB [18:53:55] My guess is that no one actually told the GSoC students about this... [18:53:58] ...i'm not the main person operating these but still have access, feel free to ping me if there is something to post [18:54:55] HaeB: who are the persons caring for the MediaWiki twitter account? [18:55:01] Yaron: We did. But it's like you have to really push them to present. [18:55:11] Hopefully next time. [18:56:32] Niharika: ah, okay. Yes, definitely. [18:56:49] Volker_E: the Technical Collaboration team (kind of) owns it [20:59:58] hey all [21:00:10] Hi brion [21:00:48] robla: we decided i'm chairing this one right? /me pokes meetbot :D [21:01:02] brion: yup [21:01:16] * brion cuts-n-pastes the labels :D [21:01:34] #startmeeting Wikimedia Dev Summit plans and ideas | Wikimedia meetings channel | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:01:34] Meeting started Wed Sep 7 21:01:34 2016 UTC and is due to finish in 60 minutes. The chair is brion. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:34] Meeting started Wed Sep 7 21:01:34 2016 UTC and is due to finish in 60 minutes. The chair is brion. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:01:34] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:35] The meeting name has been set to 'wikimedia_dev_summit_plans_and_ideas___wikimedia_meetings_channel___please_note__channel_is_logged_and_publicly_posted__do_not_remove_this_note____logs__http___bots_wmflabs_org__wm_bot_logs__23wikimedia_office_' [21:01:35] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:01:35] The meeting name has been set to 'wikimedia_dev_summit_plans_and_ideas___wikimedia_meetings_channel___please_note__channel_is_logged_and_publicly_posted__do_not_remove_this_note____logs__http___bots_wmflabs_org__wm_bot_logs__23wikimedia_office_' [21:01:44] i'm always sure i do that one wrong :D [21:01:47] o/ [21:02:00] ok so while people are filtering in... [21:02:22] ...we had some discussion on wikitech-l list recently about Wikimedia Dev Summit [21:02:25] T141938 [21:02:25] T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938 [21:02:29] thx [21:02:41] #info phab ref T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938 [21:02:42] T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938 [21:03:04] qgil: thanks for showing up on such short notice! [21:03:16] It'd be great to get some more thoughts on best directions to go with the meeting and how we plan it! [21:03:33] qgil is main organizer [21:03:45] I'm very happy that you found time for it also on such a short notice. [21:03:45] qgil: would you like to start us off with some background or thoughts? [21:04:10] Should I assume that the audience of this meeting has followed the wikitech-l thread or not? [21:04:26] I said we'd briefly touch on shadow namespaces, but I think we can consider it touched on :-) [21:04:39] anybody need a refresher on the recent thread? [21:04:47] o/ [21:04:53] ok [21:05:04] #info reminder we are not talking about shadow namespaces this time around as previously scheduled [21:05:10] okay :P [21:05:18] brion started an interesting thread last week about "opening up" the Summit [21:05:38] an interesting discussion followed [21:06:05] the I contributed the current point of view of rfarrand as Summit organizer and myself as budget owner [21:06:11] The key ideas being [21:07:00] 1. We need to define some key topics that will help us figure out who to invite beyond the usual Summit participants [21:07:23] ... and these key topcs should be defined from a product / feature / user perspective [21:07:34] there seem to be two rather diffrent needs for a summit: 1) a venue for developers to work on solutions (figure out *how* to do things) and 2) a venue for developers and users to meet and figure out what is wanted (figure out *what* to do) [21:07:44] (Hi All!) [21:07:50] hey everyone! [21:07:52] and then be discussed considering all the technical implications (software / architecture / infrastructure) [21:08:11] * DanielK_WMDE waves to rfarrand [21:08:16] :D [21:08:23] This would be a change compared to previous years, where architecture was put upfront (simplifying things a lot) [21:08:34] #info per qgil & rfarrand, if need wider invites, would need clearer def of key topic to help us tell who to invite and to what end [21:08:53] 2. Once the key topics have been defined, we can let the rest of "unconference" to the initiatives people want to bring, just like before. [21:09:12] DanielK_WMDE: that's a good obversation [21:09:24] (I think this is a fair short summary of the topic to be discussed here?) [21:09:38] #info "unconference" style can open participation once we know who to bring based on what to accomplish [21:09:47] #info add'l point: there seem to be two rather diffrent needs for a summit: 1) a venue for developers to work on solutions (figure out *how* to do things) and 2) a venue for developers and users to meet and figure out what is wanted (figure out *what* to do) [21:09:56] qgil: thanks! [21:10:08] here's how I'd like to summarize the position I've taken on wikitech-l: [21:10:13] so it seems to me time year we tried to do (1), and this time we are going for (2)? [21:10:19] meeple27 had a great way of putting this: “In-person, annual version of wikitech-l” [21:10:35] #info meeple27 had a great way of putting this: “In-person, annual version of wikitech-l” [21:10:39] (he was paraphrasing what I was fumbling to describe) [21:10:54] to me, wikimania always seemed to be the best place for (2), tbh [21:11:13] indeed, wikimania was brought up a few times in thread [21:11:34] and may be an easier place to reach a wider array of "users"/editors [21:11:39] I think there's what wikitech-l currently is, and what we want our "newspaper of record" to be [21:11:46] sadly WMF engineering is not always "active" at wikimania [21:11:50] robla: would you say a "live version of wikitech-l" would be more about discussing the "how", or more about discussing the "what"? [21:11:56] whereas WMDS grew out of the staff tech days and tends to be staff-heavy and tech-heavy already [21:12:06] DanielK_WMDE: I think "how" [21:12:06] I think it is important that we don't lose the architecture part of the summit. Most of our day-to-day work/priorities are dictated by the products (in the user-facing sense) that we work on, and the summit is the one of the few places we get to work on the actual architecture/tech-debt (something something no mw core team) [21:12:36] bd808: perhaps that could be improved, then... [21:12:36] I don't understand why you see "product" as kind of opposed to "architecture" [21:12:37] #info some questioning of whether wikimania is a better place to reach users and whether/how we can improve WMF engineering's attention there as well [21:12:42] one thing to be mindful of is that focusing on end users will prevent certain topics from being effectively discussed [21:12:51] MediaWiki is a complex software with several levels of abstraction on top of each other [21:12:58] it is unrealistic to expect a single event to span all those levels [21:13:09] so focusing on the levels available to end users means the other end of the scale will suffer [21:13:11] * robla agrees with tgr [21:13:12] #info good point -- I think it is important that we don't lose the architecture part of the summit. Most of our day-to-day work/priorities are dictated by the products (in the user-facing sense) that we work on, and the summit is the one of the few places we get to work on the actual architecture/tech-debt (something something no mw core team) [21:13:17] which is a fine tradeoff in general, but we already have other events for that [21:13:20] qgil: the product drives the need for the architecture, but discussing the architecture isn't the same as discussing the product [21:13:22] qgil: because they're different? I mean, the architecture of MediaWikiServices has nothing to do with a product, in any sense. [21:13:42] in any user-facing sense* [21:13:44] the architecture exists because there are product needs [21:13:57] does product always mean user-facing UI? [21:14:10] i feel like internal-facing things ought to be productizable as well in how we think about them [21:14:17] with internal "consumers"/users [21:14:26] * brion puts mod hat back on [21:14:35] qgil: I disagree. Unless the need here is "a functional software platform to build on top of" [21:15:01] My point is: we could discuss about 1001 topics, but some topics are actually more important / urgent than others. [21:15:11] ori had a really really good article he made me aware of: http://www.daedtech.com/human-cost-tech-debt/ [21:15:15] brion: yes, i like that. the API is a product, the users are the devs that write UI code. Ultimately, it's all driven by the end-user's needs, of corse. [21:15:26] *cause [21:15:38] In previous years a common frustration has been the disconnect between Summit topics and what happened after in our actual plans, work, allocation of resources, goals.... [21:15:39] (this is an ArchCom - Architecture Committee meeting - defining here further relationship with wiki products could make sense too) [21:16:21] qgil, i think legoktm's observation is that given a set of user needs, there are lots of ways of implementing / architecting it ... and that we need a venue to discuss what are good ways to architect solutions .. and address tech-debt, etc. [21:16:29] qgil: I think it'll be important to make this a really valuable learning event for WMF's future CTO [21:16:30] qgil: yes, i see that disconnect. [21:16:34] #info [even if we resolve topic priority, what about followthrough?] In previous years a common frustration has been the disconnect between Summit topics and what happened after in our actual plans, work, allocation of resources, goals.... [21:16:38] (Is there a "ProdCom" meeting to parallel this, by any chance, or similar?) [21:16:41] qgil: to me that is largely a problem of "Product" (i.e. WMF managers) not listening to the engineers. [21:16:53] qgil: I think many people would see it the other way around, that the priorities were decided later were disconnected ;) [21:16:57] subbu, this is exactly what I am talking about [21:17:04] I think we are getting lost in the use of words [21:17:15] qgil: has there been a tally of how many discussion resulted in a decision/plan/whatever and how many of those were implemented? it would be interesting to see the numbers [21:17:17] Let me put an example [21:17:25] But in any case, yes, we do need to prioritize. All I'm saying is that it is important to also prioritize architecture related discussions, not just "products" and user-facing features. [21:17:40] * robla eagerly awaits qgil's example [21:17:41] We should discuss a set of both IMO. [21:17:58] The 2016 WMF strategy says somewhere "Improving mobile (web and app) experiences." [21:18:00] #info yes, we do need to prioritize. All I'm saying is that it is important to also prioritize architecture related discussions, not just "products" and user-facing features. [21:18:01] btw, "platform as a product" is pretty obvious, i think. apache is a product. varnish is a product. we are their users, we use them to build our own products. it's the same with the mediawiki. it's a platform and a product, which can be used to build other products, like wikipedia. [21:18:06] Let's pick that just for the sake of having something [21:18:38] qgil: should we pick something that you pick arbitrarily for the sake of having something? [21:18:55] I'm very interested in this "product" vs "architecture and tech debt" disconnect. it may say something about what kind of projects are seeing prioritization fade vs which are getting the resources they need to complete. [21:18:56] Oh no, robla you can provide an example if you prefer. [21:19:05] DanielK_WMDE: not so obvious in some discussions I've had with past Wikimedia Foundation board members ;) [21:19:25] perhaps more important than the low-level "who do we invite to which event" thoughts I started with :) [21:19:34] bd808: yea, i can relate to that.... [21:19:45] qgil: what I feel like has worked in past years is using WikiDev deadlines as a means of reviving wikitech-l conversations about big changes we need to make [21:20:24] #info [on conferences and getting things moving] what I feel like has worked in past years is using WikiDev deadlines as a means of reviving wikitech-l conversations about big changes we need to make [21:20:49] So I wonder, we have a WMF strategy, we have WMF Annual Plans, we invest millions of $ on the work driven by these plans. Shouldn't the Summit be an event supporting that? [21:21:07] So we spend that money better in the projects and tech that will get the work done? [21:21:07] qgil: :) [21:21:30] qgil: is it an event to support implementing the plan, or an event to support making the plan? [21:21:40] qgil: how would you answer the same question about Wikimania and the Wikimedia Hackathon? [21:22:02] brion, both, but still having an impact on current and future plans should be the driver. [21:22:06] and is it about the WMF's plans or the plans of the MediaWiki developer community? [21:22:48] We are mixing many conversations... [21:23:07] IMO conference events are not off-sites [21:23:07] Can we stick with the one about "product driven", at least to a point where I feel you understand what I mean? [21:23:07] Having a good architecture is what enables developers to implement the rest of the strategy / annual plans. Does that need to be explicitly stated? [21:23:20] #info [ah now things get interesting] is it an event to support implementing the plan, or an event to support making the plan? both, but still having an impact on current and future plans should be the driver. and is it about the WMF's plans or the plans of the MediaWiki developer community? [21:23:29] for razor focus on WMF annual plans, we have the rest of the year [21:23:39] legoktm: i think it does :) [21:23:52] legoktm, yes. i think so. [21:24:06] #info Having a good architecture is what enables developers to implement the rest of the strategy / annual plans. [21:24:12] +1 [21:24:34] "a good architecture" for what? User needs still guide the architecture. [21:24:54] qgil: yes, ideally we have some kind of data flow... [21:25:06] ... from user needs to dev ideas to basic prioritization/triage ... [21:25:16] ... to planning how best to design/implement (architecture) ... [21:25:21] ... to actually doing the work. [21:25:26] qgil, but, aren't user needs already part of the annual plan, quarter goals, community wishlist survey processes? [21:25:29] that sounds very "waterfall"y though :D [21:25:41] qgil: So here's my attempt to restate what I think you are saying. The DevSummit should attempt to solve technical problems that are related to the WMF annual plan and various scheduled Product vertical roadmaps. [21:25:50] no [21:25:54] Perhaps the question is: should future plans be driven only by the *direct* needs of the end-user, or should they also be driven by the needs of the devs who try to cater to the end user's needs? [21:25:56] Should future plans include investments into architecture improvements that allow for easier implementations of some class of feature in general, instead of adding hacks that cater to a specific use case? [21:25:56] what I am saying is [21:26:23] DanielK_WMDE: +1 [21:26:46] MediaWiki is cutting edge as a wiki software but very much not cutting edge as a development environment [21:26:48] the Summit should pick a few user needs that are challenging and require the participation of developers and more to move forward. [21:26:49] DanielK_WMDE: ideally, our analysis of user needs will include future-facing needs for which "pay down tech debt" is part of the plan. perhaps we are not succeeding at this though [21:27:10] yea... [21:27:44] i think this is always a problem in quarterly planning .. tech debt / maintenance doesn't figure .. although it is beginning to be factored in (at least speaking for editing). [21:27:50] (should apache development be driven by end user needs, or to dev needs?) [21:27:57] Do you agree with the idea of picking a few topics and macking sure that everybody involved is invited? [21:28:02] qgil: as in, we alrady have some input, now let's make best use of together time for the developers to hash out the 'hard parts'? -> i think this ideally leads to concentrating on those architectural decisions yes, we hope [21:28:19] qgil: and is the change about then about narrowing compared to past efforts? [21:28:20] qgil: sure, for appropriate values of "topics" [21:28:44] As we expand beyond WMF in invites, I would like to expand our developer community [21:28:50] qgil: Would "fix page editing" aka T120414 be an acceptable "user need"? Seems like all users need to edit pages. [21:28:50] T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces - https://phabricator.wikimedia.org/T120414 [21:28:51] #info [re tech debt & WMF planning getting better] i think this is always a problem in quarterly planning .. tech debt / maintenance doesn't figure .. although it is beginning to be factored in (at least speaking for editing). [21:29:00] Narrowing beforehand in order to have time to invite people beyond the devs that anyway will attend is one change, yes. [21:29:14] And EditPage.php is easily our best (or worst) example of terrible tech debt. [21:29:43] legoktm: yea, we'll definitly needs this for MCR [21:29:55] we should figure out who we *wish* was on wikitech-l, to invite to help us pay off our technical debt [21:29:57] #info [on purpose for inviting] As we expand beyond WMF in invites, I would like to expand our developer community [21:30:21] legoktm, I am not in the business of picking topics. As organizer, I am just saying that picking a few topics beforehand is the only way we have to assure that those who have to be there are there. [21:30:28] we did pick some topics in 2016: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Discussion_areas [21:30:52] presumably we are having this conversation because we do not all agree that worked well [21:30:53] qgil: But the actual point I'm trying to make (and I think you might be too?) is that the architecture is in service of what users do. But that needs to come from *developers*, not users. [21:30:54] qgil: where do we stand on topic picking so far, and what would you like from us in terms of decision-making over the next few weeks? [21:30:55] "Software engineering" is an area, not a topic. [21:31:11] what would be an example of a topic? [21:31:28] eg if we want to concentrate on a tech debt issue, what do we need to do to make that happen [21:31:29] qgil: :) [21:31:52] or on some specific user-facing issue, or whatever :) [21:31:57] content format, content access, UI seem topics to me [21:32:24] An example of a topic would be, let me try again, now at https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results [21:32:32] #3 Central Global Repository for Templates, Lua modules, and Gadgets [21:32:41] so, i guess the discussion is focusing on what the topics ought to be .. and i guess it goes back to what DanielK_WMDE said earlier on about "how" vs "what". [21:33:01] That is a topic reflecting "user needs", that has many ramifications all the way to architecture and infrastructure. [21:33:25] tech debt and maintenance and refactoring as well. [21:33:50] ramifications all the way up to user needs .. looking up. [21:33:50] #info An example of a topic would be, let me try again, now at https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Results #3 Central Global Repository for Templates, Lua modules, and Gadgets -> That is a topic reflecting "user needs", that has many ramifications all the way to architecture and infrastructure. [21:34:06] If we agree that selecting a few topics beforehand (while leaving freedom for anyone to push their own topics in unconference mode)... [21:34:20] qgil: you seem to be saying that there cannot exist any useful discussion which does not touch on user-visible features [21:34:25] Then my next (and basically last) proposal is that such topics are formulated from a "user need" perspective. [21:34:27] i think the trick is making sure we pick apart those ramifications and then follow up on them :) [21:34:54] what tgr said. [21:35:31] tgr, my point is the inverse: if a topic has absolutely no impact in the user experience, how urgent/important is it to be selected as one of the few prioritized topics? [21:35:32] as an off-topic example, take to controversy around the previous ED [21:36:02] well, a "user need" may be something like "site isn't slow" or "pages are editable by a person who doesn't have deep template knowledge" [21:36:03] would it have been a useful contribution to ask every step of that debate, "what user needs is an ED change going to fulfill"? [21:36:28] qgil: extremely important, if it allows developrs to implement new features more quickly in the future. we want to build better tools. we need to talk about it. [21:36:34] interesting example tgr :) [21:36:36] some concerns simply cannot be directly mapped to user needs; that does not mean they don't affect them [21:36:50] all topics have some impact on user experience, but some are difficult to measure (e.g. mean time to code review) [21:36:53] DanielK_WMDE, "implement new features quickly" has a clear impact in the user experience. [21:36:56] if MediaWiki was written in assemply, we would have a major problem [21:36:59] #info some concerns simply cannot be directly mapped to user needs; that does not mean they don't affect them [21:37:10] #info "implement new features quickly" has a clear impact in the user experience. [21:37:18] asking for it to be discussed in terms of specific user-visible features would not be helpful at all [21:37:21] etc [21:37:26] qgil: sure, but the "topic" will not be anything that you can relate to a *specific* end user need. [21:37:34] So definitely there are some open questions in how to select and prioritize the topics [21:38:03] #info some possible disagreement on how much user-visibility topics need [21:38:04] DanielK_WMDE, going back to my aborted example "Improving mobile (web and app) experiences." [21:38:21] i'd suggest that there's some middle ground -- i had some talks with folks at wikimania/mexico about "productizing" some of the architecture work they wanted to do [21:38:47] ie, find the user-facing thing that your architecture improvement will enable, then pitch that [21:38:53] If the main problem is that MobileFrontend is very difficult to push forward and we need to maintain three totally different codebases to change a pixel in our mobile experience, then there you have a topic for discussion. [21:39:20] my opinion is that work needs a "product face" if it wants to get prioritized and resourced at wmf today :) which may or may not be ideal [21:39:27] wmde pushed back strongly, saying they shouldn't need to justify (say) integrating wikidata with commons, it was obviously the right thing to do from the developer perspective and they couldn't understand why were weren't supporting it [21:39:35] the main problem there is that we are all scared to change the UI [21:39:48] Can you provide examples of topics that you think should be high priority at the Summit 2017, please? [21:39:49] and i tried to explain (at the time) that quarterly goals were set by product teams, and you'd have better luck if you made your architecture change part of a product [21:39:56] seems like we're having that sort of discussion again here [21:39:58] I want to run the "user need" check with each of them. [21:40:08] Because I believe that we actuallky agreemore than disagree. [21:40:30] It is just that apparently mentioning "product" is counterproductive in certain contexts like this one. ;) [21:40:50] #info [on prioritizing within wmf] and i tried to explain (at the time) that quarterly goals were set by product teams, and you'd have better luck if you made your architecture change part of a product [21:40:52] qgil: it seems to me you are advocating to restrict the possible topics to the subset which can be easily evaluated in terms of the annual plan (which is fine) but instead of arguing for it you just pretend everything outside is not a topic [21:40:57] ArchCom-RFCs should be driven by user need. If they aren't, that's a problem larger than WikiDev17 planning [21:41:06] tgr, propose a topic, please. A real one. [21:41:21] the wmde/wikidata issue was, IIRC, reworking the category system in commons to draw from wikidata. which is a big architecture change, because it makes categories mutlilingual [21:41:22] last year we had a pretty successful discussion about problems with code review, for example [21:41:37] qgil: I would like to (again) leave it open to RFCs that get proposed by an early-ish deadline [21:41:40] there is no way to meaningfully discuss that in terms of mobile or whatever [21:41:47] but i think they also wanted simpler stuff, like just pushing the image metadata into the wikidata db. [21:42:00] so you could have a wikidata fact corresponding to the license of the commons item, eg. [21:42:13] which would have approximately zero user-facing impact. but still a big architectural change. [21:42:15] qgil: "improve CI infrastructure so we can run browser tests on every commit" is one topic. "MediaWiki should provide a pluggable registry for editor interfaces" is another that was brought up earlier. [21:42:33] tgr, the code review discussion is actually a very good example of an exciting Summit topic that then receives no remarkable changes after the event... [21:42:37] there was another successful session on dependency injection (which has been followed up with code changes, largely thanks to DanielK_WMDE) [21:42:43] so, "store commons metadata in wikidata" is another possible topic. [21:42:52] again, not meaningfully debatable in terms of specific products [21:42:56] tgr: \o/ [21:43:06] if i may, i think the dissonance here is that good architecture has utility in and of itself without having to be justified in terms of a specific user feature, i.e. architecture is a cross-cutting concern .. while architectural work can be justified in terms of user needs, a lot of the time, the connections are very indirect ... but i suppose, if necessary, they can be pitched as such? [21:43:18] DanielK_WMDE: you probably remember that commons/wikidata discussion in wikimania/mexico better than i do? [21:43:20] DanielK_WMDE, do you think these are candidates for the, say, top 5 topics of the Summit and we should invite everyone involved to solve them? [21:43:36] #info if i may, i think the dissonance here is that good architecture has utility in and of itself without having to be justified in terms of a specific user feature, i.e. architecture is a cross-cutting concern .. while architectural work can be justified in terms of user needs, a lot of the time, the connections are very indirect ... but i suppose, [21:43:36] if necessary, they can be pitched as such? [21:43:39] qgil: yes, actually [21:44:03] i'm not sure i'm remembering the details on the wikidata side correctly, i'm just remembering their frustration that WMF didn't seem "interested" in it, since it didn't have an associated product. [21:44:41] cscott: i think this notion is essentially why i've sometimes pushed for returning to having some kind of 'mw core team', to give a place to put 'products' like technical debt :) [21:45:00] maybe less about the _team_ than about having a place on the board to hang things [21:45:20] the WMF is interested in Commonsdata, just not interested enough to actually put resources to it :/ [21:45:30] brion: sure. or we can actively try to find "products" to adopt each part of the architecture work -- maybe the "commons product" owns the first part of the wikidata integration, for example. [21:45:49] DanielK_WMDE, good, then can you get the Architecture committee or the WMF Technology department to bless them as 2 of the main topics of the Summit? Then we organizers can start mobilizing outreach and travel sponsorship. [21:46:15] brion: part of the question is: should we be forced to associated products with architecture? or should we live in an engineering utopia where good architecture and technical debt reduction are so self-obvious that they don't need to be justified [21:46:22] :D [21:46:32] but Commons metadata is an example of a higher architectural concern which has been successfully sold to product people, and that took a lot of time and mostly succeeded in the aftermath of a monumental fuckup [21:46:35] i'd like to think a little of both, personally [21:46:52] ideally architecture planning would happen before the fuckup [21:46:57] cscott, right. [21:47:06] #info part of the question is: should we be forced to associated products with architecture? or should we live in an engineering utopia where good architecture and technical debt reduction are so self-obvious that they don't need to be justified [21:47:15] #info i'd like to think a little of both, personally [21:47:32] ok so I think that's a major outstanding question we can't resolve today [21:47:34] that is, i think it should be entirely engineering's job to justify the product side; i think part of management's role in enabling engineers and good engineering will be to do some of the legwork to find product-based subgoals in a larger architectural project (like wikidata) [21:47:37] but finding the question is good! [21:47:54] Ultimately, the problem I would like to see solved in the Summit 2016 is: productive discussions that lead to actual plans, resources, releases, deployments [21:47:56] tgr but rarely does though ... i mean despite all good intentions bad arch / decisions happen or they outlive their utility in a new tech climate .. so, tech debt is probably independent of arch decisions to some degree? [21:48:06] qgil: the question is - do such topics pass your "user needs" test? they do in my mind, but what about yours, or the board's? [21:48:09] #info that is, i think it should be entirely engineering's job to justify the product side; i think part of management's role in enabling engineers and good engineering will be to do some of the legwork to find product-based subgoals in a larger architectural project (like wikidata) [21:48:22] #info Ultimately, the problem I would like to see solved in the Summit 2016 is: productive discussions that lead to actual plans, resources, releases, deployments [21:48:36] qgil: cscott: i think we have some agreement in the essence [21:48:44] which is that we gotta know how to Get Stuff Done [21:48:51] which is dependent in part on picking the right topics [21:48:56] DanielK_WMDE, they do, because many user needs are stuck or progress very slowly because those problems aren't solved [21:48:59] and in part on knowing how to follow up on them [21:49:00] I think I've gotta come back to http://www.daedtech.com/human-cost-tech-debt/ [21:49:03] we can support good architecture on its own merits while *also* trying to find concrete ways that it can be sold as product. this also helps find good user-visible incremental milestones in a large project, instead of just saying "oh, everything will be better once we " [21:49:09] subbu: there will always be tech debt, sure. The amount of it very much depends on architectural decisions and how much consensus (and resources) we can put behind them [21:49:13] cscott: i'm all for providing a good rationale, down to the end-user. but the benefits for the end-user will sometime be long-term and not very specific. like "less bugs". [21:49:13] cscott, qgil, i think you might be right though that there is more agreement here than the discussions indicate. [21:49:26] #info [reminder: tech debt rules all] I think I've gotta come back to http://www.daedtech.com/human-cost-tech-debt/ [21:49:28] tgr, agreed. [21:49:39] qgil: i agree on the "productive discussions that lead to actual plans, resources, releases, deployments" [21:49:52] +1 [21:50:04] +1 as well. [21:50:11] qgil: part of the function of the summit may be to bring together product and engineering, so we can propose architectural goals and then *work with* product teams in order to get a plan->resource->release->deployment [21:50:12] +many :D [21:50:31] #info much agreement on "productive discussions that lead to actual plans, resources, releases, deployments" being key! [21:50:33] instead of everyone just agreeing that the architectural change *should* be done w/o any concrete plan for doing it [21:50:52] yassssss [21:50:53] I keep using IETF meetings as a model, which take don't have top down agendas, but have done a lot over several decades [21:51:07] #link http://www.daedtech.com/human-cost-tech-debt/ [21:51:20] Defining a few important topics beforehand allows us to assure that there will be more and more diverse people at the Summit ready to discuss them. [21:51:23] or s/product teams/management/ or whatever else is needed to actually allocate resources and create plans and goals, depending on your model of our foundation's organization and management structure. [21:51:45] robla: i think those are great models when the right topics are already selected and in context of getting resourced. selecting and supporting them seems to be our hard problem [21:52:16] cscott: there certainly was some disconnect last year between what areas the summit focused on and where the WMF spent its resources [21:52:25] Letting the decision of these main topics to the end means that these topics will be discussed basically by the usual participants of the Summit only (core-ish devs), which means that the chances of repeating the siautation of previous years is higher [21:52:27] qgil: is "structured content handling" too unspecific as a topic? [21:52:37] I would hope we are slowly moving towards resolving that disconnect in the opposite direction [21:52:37] brion: yeah, I think WMF needs to use the Dev Summit as a tool for listening to our dev community, not for setting their agenda [21:52:46] tgr: there were also c-level/management/engineering disconnects, so that's not 100% surprising. [21:52:56] robla: hear hear [21:53:00] and not by not even talking about those issues [21:53:22] #info brion: yeah, I think WMF needs to use the Dev Summit as a tool for listening to our dev community, not for setting their agenda [21:53:22] tgr: one of the question is: is management/c-level "fixed" now, so we don't have to worry about this -- or is doing the summit "properly" an important part in "fixing" our org. [21:53:24] cscott: and theoretically we are slowly moving to resolve those as well [21:53:26] #info Defining a few important topics beforehand allows us to assure that there will be more and more diverse people at the Summit ready to discuss them. Letting the decision of these main topics to the end means that these topics will be discussed basically by the usual participants of the Summit only (core-ish devs), which means that the chances of [21:53:26] repeating the siautation of previous years is higher [21:53:30] * robla has to be careful about pronouns like "we" and "they" because he is part of many "we" groups [21:53:32] most prominently with the CTO hire [21:53:51] qgil: good point, let's make sure we keep talking these next few weeks and hammer out some ideas :) [21:54:12] robla: "I think WMF needs to use the Dev Summit as a tool for listening to our dev community, not for setting their agenda" -- perhaps this is where product does a lot of listening, in order to turn the dev communities goals into product/actionable plans? [21:54:44] cscott: agreed! [21:54:45] do we have a CTO hire? [21:54:48] DanielK_WMDE, how does "structured content handling" affect our ability to make users happier? [21:54:52] i like this idea [21:54:55] * cscott gets out of the loop easily [21:55:08] in theory, the january timeline gives us a good chance to lead into annual planning with bottom-up dev input [21:55:16] we just need to implement :) [21:55:17] qgil: that would be an excellent discussion to have at the summit ;) [21:55:19] qgil: you keep mentioning "repeating last year" [21:55:21] ok folks! we have 5 minutes left [21:55:27] qgil: better search, easier re-user, automatic localization, better support for workflows... [21:55:32] do we have any evaluation of how successful last year was? [21:55:32] so let's stay on topic and wrap up soon :) [21:55:49] #info do we have any evaluation of how successful last year was? [21:55:57] DanielK_WMDE, there you go. :) [21:55:57] I don't necessarily disagree but I'm wary of groupthink where everyone just assumes it is so [21:56:13] I think we should probably take the remainder of the conversation to #wikimedia-tech, wikitech-l@, and the Phab task [21:56:17] qgil: but the point is that the discussions will not be about the specific use cases, but about the handling of structureddata internally. because we need a venue to discuss that. [21:56:20] tgr, I replied to this point in wikitech-l earlier today. [21:56:37] i recall talk of the satisfaction numbers being relatively high :) [21:56:40] tgr, my summary: the summit itself, very well; before and after requires lots of improvements [21:56:48] but we have less of a clear picture of did it have strong outcomes or not [21:56:59] *nod* [21:57:07] qgil: so people interrested in discussing the concrete features may be discappointed. which isn't to say we shouldn't talk to them. we should do that a lot more. we just can't talk to everyone at once. [21:57:29] robla: yep! good discussions here and i think we've got a few key points to concentrate on now [21:57:35] qgil: all I can find is you saying "My evaluation is based on the number of non-WMF developers specializing on [21:57:38] tools, templates, bots, mobile apps, MediaWiki, and other users of our [21:57:40] APIs, and what they got from the event. It is also based on how much [21:57:41] Summit participants are very satisfied when asked right at the end of the event. If we would ask them (you) four months later about the outcome f the Summit, probably the satisfaction would be lower. [21:57:43] outreach effort we managed to put into assuring that the participation from [21:57:44] #info I think we should probably take the remainder of the conversation to #wikimedia-tech, wikitech-l@, and the Phab task [21:57:46] these sectors was rich and diverse." which seems to be a different issue altogether [21:58:29] tgr, https://lists.wikimedia.org/pipermail/wikitech-l/2016-September/086469.html [21:58:40] #info key issues raised include: how to select topics (user focus? tech debt? both?) / how to get product teams to priotize tech debt-archy issues / and how to ensure good followup [21:58:43] program note: next week's IRC conv is cancelled because of WMF planning session happening in SF [21:59:00] #info program note: next week's IRC conv is cancelled because of WMF planning session happening in SF [21:59:01] #info program note: next week's IRC conv is cancelled because of WMF planning session happening in SF [21:59:04] heh [21:59:07] (Thanks for this ever so generative and focused conversation!) [21:59:10] hee :-) [21:59:12] ok thanks everybody! [21:59:15] #endmeeting [21:59:16] Meeting ended Wed Sep 7 21:59:15 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [21:59:16] Meeting ended Wed Sep 7 21:59:15 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [21:59:16] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.html [21:59:16] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.txt [21:59:16] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.wiki [21:59:16] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.html [21:59:16] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.txt [21:59:16] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.wiki [21:59:16] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.log.html [21:59:16] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.log.html [21:59:30] this was a really good discussion [21:59:39] qgil: yes, I was quoting from that [21:59:51] let's all concentrate on what we can plan and what we can make happen [22:00:46] tgr, see my comments in the first paragraphs about satisfaction scores during, before, after. In a previous post I had mentioned https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/Lessons_Learned [22:01:08] ok i gotta run. see y'all on list! [22:03:25] qgil: thanks. I still feel we ought to evaluate how many of those discussions brought tangible results over time before making claims like "the Summit discussions that brought high levels of satisfaction get [22:03:28] frequently colder and stalled" [22:03:41] (goes both ways of course) [22:05:12] tgr, sure, but I think the disconnect is clear. And well, this discussion about the Summit is makming me see how big and deep that disconnect might be beyond the Summit. :/ [22:07:07] qgil: the quote that tgr pointed to is admittedly what has gotten under my skin [22:10:55] * DanielK_WMDE contemplates a "no features" year, which we use to get our shit together. [22:11:09] DanielK_WMDE: ha! [22:11:26] robla, which quote? [22:12:35] "no features" might be an internal management stress-test -- see how well we can allocate resources to such work and communicate the results up and down the management structure (including to the board) [22:12:55] similarly communicate to the community [22:13:03] i'd so love to see that [22:13:41] it could become a new form of strike ;) [22:13:53] qgil: "the Summit discussions that brought high levels of satisfaction get frequently colder and stalled" [22:14:29] DanielK_WMDE: +1 [22:14:54] it would require work, but that would be work which is generally worth doing [22:15:33] I don't our tech debt is so dire that we need to make a "no features" year, but we clearly can't make it an "all features" year, either [22:16:20] maybe "no features this year?!" should be a topic at the summit :) [22:17:12] brion: my hesitancy for going back to having a "MediaWiki Core" team is the implicit assumption that that team is responsible for all the tech debt [22:17:19] * You can only deploy an extension if you undeploy one first [22:17:19] robla, I have the impression that "management won't hear" or "either you convince Product or you're stuck" seem to be common themes, also in today's discussion. [22:18:16] robla: not a nice job. ask who'd volunteer! [22:18:40] qgil: that's why I've been so big on making this a WMF CTO onboarding meeting. [22:19:09] robla, that is an expensive way to onboard one person... :) [22:19:41] qgil: well, yes, but it'd be even more expensive if the future CTO considered this a waste of time, wouldn't it? [22:21:15] robla: heh [22:21:57] Since the future CTO is unknown today, I'd rather focus in making the Summit not a good investment of time for the other 199 participants, and the rest of the movement. [22:22:12] er./.. delete the "not" [22:23:01] qgil: what would be an example of something that would be bad for a future CTO, but more interesting to the other 199 participants? [22:23:38] robla, I cannot think of any example if that CTO is a good CTO, and this is why I am not concerned about this person today. [22:23:58] the theoretical "future CTO" is a good user persona for WikiDev17 [22:25:34] the JD: https://boards.greenhouse.io/wikimedia/jobs/161834?t=30xl7i#.V9CTy99yukA [22:26:33] qgil: so basically you are arguing that if architecture is underresourced (due to lack of C-level representation and whatnot) it should be underresourced in event planning as well? [22:27:00] I can see the point in that but for a productive discussion that should be stated more clearly [22:27:43] probably many people think, like cscott said above, that the summit is a venue for correcting that underrepresentation [22:28:01] It might be because I don't work in WMF Product or WMF Technology, but I don't have this polarized view that "more product" means "less tech" or viceversa. [22:29:05] indeed; most people who are worried about tech debt would probably say that it leads to less product and less tech on the long term [22:30:13] but there are obvious trade-offs, given that the number of engineers is mostly constant [22:32:29] in our existing two large events, only one side of those trade-offs is represented: the hackathons focus on small user-visible features which can be presented before an audience after three days of coding, and Wikimania (inasmuch as it focuses on things at all) tends to focus on the common intersection of features wanted by editors and features wanted by the WMF [22:32:56] it's not just a place to correct any underrepresentation; it's also a means of collaborating with our dev community on the tech debt that hurts non-WMF engineers more than WMF engineers [22:33:02] which, for various reasons, tends to be not so long term as well [22:33:32] Hey, all I am saying is pick 5 topics beforehand so we can invite the right people. :) [22:33:45] (exceptions certainly exist; there are architecture concerns which map very well to product plans, they are just a subset of all concerns) [23:10:01] wikimania increasingly has been disconnected from WMF, so it's more accurate to say wikimania focuses on features wanted by the community, in a vague not-tied-to-implementation-details-or-ongoing-maintenance-burden way. [23:10:30] attempts to tether wikimania closer to WMF concerns like roadmaps and maintainability have gotten pushback [23:10:58] which is fine, really, it's good to have a user-focused event. but it means that the unrepresented gap is widening