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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:34 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: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:34 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:21 ...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:15 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:09 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:04 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:49 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:15 :D 21:08:22 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:23 (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:10 * 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:56 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:00 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:33 #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:56 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:05 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:54 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:33 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:23 #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:06 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:51 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:40 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:53 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:19 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:14 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:36 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:55 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:40 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:29 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:31 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:51 ideally architecture planning would happen before the fuckup 21:46:57 cscott, right. 21:47:05 #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:36 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:21 #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:55 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:25 #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:32 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:44 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:36 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:45 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:21 #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:23 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:54 * 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:47 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