Page MenuHomePhabricator
Paste P3996

ArchCom-RFC-2016W36-irc-E269.txt
ActivePublic

Authored by RobLa-WMF on Sep 7 2016, 10:02 PM.
Tags
None
Referenced Files
F4441126: ArchCom-RFC-2016W36-irc-E269.txt
Sep 7 2016, 10:02 PM
Subscribers
None
21:01:34 <brion> #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 <wm-labs-meetbot_> 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 <wm-labs-meetbot_> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:34 <wm-labs-meetbot_> 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 <wm-labs-meetbot> 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 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:34 <wm-labs-meetbot> 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 <brion> i'm always sure i do that one wrong :D
21:01:47 <robla> o/
21:02:00 <brion> ok so while people are filtering in...
21:02:21 <brion> ...we had some discussion on wikitech-l list recently about Wikimedia Dev Summit
21:02:25 <robla> T141938
21:02:25 <stashbot> T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938
21:02:29 <brion> thx
21:02:41 <brion> #info phab ref T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938
21:02:42 <stashbot> T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938
21:03:04 <robla> qgil: thanks for showing up on such short notice!
21:03:15 <brion> 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 <brion> qgil is main organizer
21:03:45 <qgil> I'm very happy that you found time for it also on such a short notice.
21:03:45 <brion> qgil: would you like to start us off with some background or thoughts?
21:04:09 <qgil> Should I assume that the audience of this meeting has followed the wikitech-l thread or not?
21:04:26 <robla> I said we'd briefly touch on shadow namespaces, but I think we can consider it touched on :-)
21:04:39 <brion> anybody need a refresher on the recent thread?
21:04:47 <legoktm> o/
21:04:53 <qgil> ok
21:05:04 <brion> #info reminder we are not talking about shadow namespaces this time around as previously scheduled
21:05:10 <legoktm> okay :P
21:05:18 <qgil> brion started an interesting thread last week about "opening up" the Summit
21:05:38 <qgil> an interesting discussion followed
21:06:04 <qgil> the I contributed the current point of view of rfarrand as Summit organizer and myself as budget owner
21:06:11 <qgil> The key ideas being
21:07:00 <qgil> 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 <qgil> ... and these key topcs should be defined from a product / feature / user perspective
21:07:34 <DanielK_WMDE> 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 <Scott_WUaS> (Hi All!)
21:07:49 <rfarrand> hey everyone!
21:07:52 <qgil> and then be discussed considering all the technical implications (software / architecture / infrastructure)
21:08:11 * DanielK_WMDE waves to rfarrand
21:08:15 <rfarrand> :D
21:08:22 <qgil> This would be a change compared to previous years, where architecture was put upfront (simplifying things a lot)
21:08:34 <brion> #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 <qgil> 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 <brion> DanielK_WMDE: that's a good obversation
21:09:23 <qgil> (I think this is a fair short summary of the topic to be discussed here?)
21:09:38 <brion> #info "unconference" style can open participation once we know who to bring based on what to accomplish
21:09:47 <brion> #info add'l point: <DanielK_WMDE> 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 <brion> qgil: thanks!
21:10:08 <robla> here's how I'd like to summarize the position I've taken on wikitech-l:
21:10:13 <DanielK_WMDE> so it seems to me time year we tried to do (1), and this time we are going for (2)?
21:10:19 <robla> meeple27 had a great way of putting this: “In-person, annual version of wikitech-l”
21:10:35 <brion> #info <robla> meeple27 had a great way of putting this: “In-person, annual version of wikitech-l”
21:10:39 <robla> (he was paraphrasing what I was fumbling to describe)
21:10:54 <DanielK_WMDE> to me, wikimania always seemed to be the best place for (2), tbh
21:11:13 <brion> indeed, wikimania was brought up a few times in thread
21:11:34 <brion> and may be an easier place to reach a wider array of "users"/editors
21:11:39 <robla> I think there's what wikitech-l currently is, and what we want our "newspaper of record" to be
21:11:46 <bd808> sadly WMF engineering is not always "active" at wikimania
21:11:50 <DanielK_WMDE> 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 <brion> whereas WMDS grew out of the staff tech days and tends to be staff-heavy and tech-heavy already
21:12:06 <robla> DanielK_WMDE: I think "how"
21:12:06 <legoktm> 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 <DanielK_WMDE> bd808: perhaps that could be improved, then...
21:12:36 <qgil> I don't understand why you see "product" as kind of opposed to "architecture"
21:12:37 <brion> #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 <tgr> one thing to be mindful of is that focusing on end users will prevent certain topics from being effectively discussed
21:12:51 <tgr> MediaWiki is a complex software with several levels of abstraction on top of each other
21:12:58 <tgr> it is unrealistic to expect a single event to span all those levels
21:13:09 <tgr> 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 <brion> #info good point -- <legoktm> 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 <tgr> which is a fine tradeoff in general, but we already have other events for that
21:13:20 <DanielK_WMDE> qgil: the product drives the need for the architecture, but discussing the architecture isn't the same as discussing the product
21:13:22 <legoktm> qgil: because they're different? I mean, the architecture of MediaWikiServices has nothing to do with a product, in any sense.
21:13:42 <legoktm> in any user-facing sense*
21:13:44 <qgil> the architecture exists because there are product needs
21:13:56 <brion> does product always mean user-facing UI?
21:14:10 <brion> i feel like internal-facing things ought to be productizable as well in how we think about them
21:14:17 <brion> with internal "consumers"/users
21:14:26 * brion puts mod hat back on
21:14:35 <legoktm> qgil: I disagree. Unless the need here is "a functional software platform to build on top of"
21:15:00 <qgil> My point is: we could discuss about 1001 topics, but some topics are actually more important / urgent than others.
21:15:11 <robla> ori had a really really good article he made me aware of: http://www.daedtech.com/human-cost-tech-debt/
21:15:15 <DanielK_WMDE> 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 <DanielK_WMDE> *cause
21:15:38 <qgil> 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 <Scott_WUaS> (this is an ArchCom - Architecture Committee meeting - defining here further relationship with wiki products could make sense too)
21:16:21 <subbu> 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 <robla> qgil: I think it'll be important to make this a really valuable learning event for WMF's future CTO
21:16:30 <DanielK_WMDE> qgil: yes, i see that disconnect.
21:16:33 <brion> #info [even if we resolve topic priority, what about followthrough?] <qgil> 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 <Scott_WUaS> (Is there a "ProdCom" meeting to parallel this, by any chance, or similar?)
21:16:41 <bd808> qgil: to me that is largely a problem of "Product" (i.e. WMF managers) not listening to the engineers.
21:16:53 <legoktm> qgil: I think many people would see it the other way around, that the priorities were decided later were disconnected ;)
21:16:56 <qgil> subbu, this is exactly what I am talking about
21:17:04 <qgil> I think we are getting lost in the use of words
21:17:15 <tgr> 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 <qgil> Let me put an example
21:17:25 <legoktm> 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 <legoktm> We should discuss a set of both IMO.
21:17:58 <qgil> The 2016 WMF strategy says somewhere "Improving mobile (web and app) experiences."
21:18:00 <brion> #info <legoktm> 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 <DanielK_WMDE> 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 <qgil> Let's pick that just for the sake of having something
21:18:38 <robla> qgil: should we pick something that you pick arbitrarily for the sake of having something?
21:18:54 <brion> 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 <qgil> Oh no, robla you can provide an example if you prefer.
21:19:05 <bd808> DanielK_WMDE: not so obvious in some discussions I've had with past Wikimedia Foundation board members ;)
21:19:25 <brion> perhaps more important than the low-level "who do we invite to which event" thoughts I started with :)
21:19:33 <DanielK_WMDE> bd808: yea, i can relate to that....
21:19:45 <robla> 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 <brion> #info [on conferences and getting things moving] <robla> 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 <qgil> 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 <qgil> So we spend that money better in the projects and tech that will get the work done?
21:21:07 <brion> qgil: :)
21:21:30 <brion> qgil: is it an event to support implementing the plan, or an event to support making the plan?
21:21:40 <tgr> qgil: how would you answer the same question about Wikimania and the Wikimedia Hackathon?
21:22:02 <qgil> brion, both, but still having an impact on current and future plans should be the driver.
21:22:06 <bd808> and is it about the WMF's plans or the plans of the MediaWiki developer community?
21:22:48 <qgil> We are mixing many conversations...
21:23:06 <tgr> IMO conference events are not off-sites
21:23:07 <qgil> 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 <legoktm> 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 <brion> #info [ah now things get interesting] <brion> is it an event to support implementing the plan, or an event to support making the plan? <qgil> both, but still having an impact on current and future plans should be the driver. <bd808> and is it about the WMF's plans or the plans of the MediaWiki developer community?
21:23:29 <tgr> for razor focus on WMF annual plans, we have the rest of the year
21:23:39 <brion> legoktm: i think it does :)
21:23:52 <subbu> legoktm, yes. i think so.
21:24:06 <legoktm> #info <legoktm> Having a good architecture is what enables developers to implement the rest of the strategy / annual plans.
21:24:12 <brion> +1
21:24:34 <qgil> "a good architecture" for what? User needs still guide the architecture.
21:24:54 <brion> qgil: yes, ideally we have some kind of data flow...
21:25:06 <brion> ... from user needs to dev ideas to basic prioritization/triage ...
21:25:16 <brion> ... to planning how best to design/implement (architecture) ...
21:25:21 <brion> ... to actually doing the work.
21:25:26 <subbu> qgil, but, aren't user needs already part of the annual plan, quarter goals, community wishlist survey processes?
21:25:29 <brion> that sounds very "waterfall"y though :D
21:25:41 <bd808> 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 <qgil> no
21:25:54 <DanielK_WMDE> 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 <DanielK_WMDE> 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 <qgil> what I am saying is
21:26:23 <tgr> DanielK_WMDE: +1
21:26:46 <tgr> MediaWiki is cutting edge as a wiki software but very much not cutting edge as a development environment
21:26:48 <qgil> 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 <brion> 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 <DanielK_WMDE> yea...
21:27:44 <subbu> 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 <DanielK_WMDE> (should apache development be driven by end user needs, or to dev needs?)
21:27:57 <qgil> Do you agree with the idea of picking a few topics and macking sure that everybody involved is invited?
21:28:02 <brion> 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 <bd808> qgil: and is the change about then about narrowing compared to past efforts?
21:28:20 <DanielK_WMDE> qgil: sure, for appropriate values of "topics"
21:28:44 <robla> As we expand beyond WMF in invites, I would like to expand our developer community
21:28:50 <legoktm> qgil: Would "fix page editing" aka T120414 be an acceptable "user need"? Seems like all users need to edit pages.
21:28:50 <stashbot> T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces - https://phabricator.wikimedia.org/T120414
21:28:51 <brion> #info [re tech debt & WMF planning getting better] <subbu> 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 <qgil> Narrowing beforehand in order to have time to invite people beyond the devs that anyway will attend is one change, yes.
21:29:14 <legoktm> And EditPage.php is easily our best (or worst) example of terrible tech debt.
21:29:43 <DanielK_WMDE> legoktm: yea, we'll definitly needs this for MCR
21:29:55 <robla> we should figure out who we *wish* was on wikitech-l, to invite to help us pay off our technical debt
21:29:57 <brion> #info [on purpose for inviting] <robla> As we expand beyond WMF in invites, I would like to expand our developer community
21:30:21 <qgil> 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 <tgr> we did pick some topics in 2016: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Discussion_areas
21:30:51 <tgr> presumably we are having this conversation because we do not all agree that worked well
21:30:53 <legoktm> 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 <brion> 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 <qgil> "Software engineering" is an area, not a topic.
21:31:11 <tgr> what would be an example of a topic?
21:31:28 <brion> eg if we want to concentrate on a tech debt issue, what do we need to do to make that happen
21:31:29 <Scott_WUaS> qgil: :)
21:31:52 <brion> or on some specific user-facing issue, or whatever :)
21:31:57 <tgr> content format, content access, UI seem topics to me
21:32:24 <qgil> 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 <qgil> #3 Central Global Repository for Templates, Lua modules, and Gadgets
21:32:40 <subbu> 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 <qgil> That is a topic reflecting "user needs", that has many ramifications all the way to architecture and infrastructure.
21:33:25 <subbu> tech debt and maintenance and refactoring as well.
21:33:50 <subbu> ramifications all the way up to user needs .. looking up.
21:33:50 <brion> #info <qgil> 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 <qgil> 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 <tgr> qgil: you seem to be saying that there cannot exist any useful discussion which does not touch on user-visible features
21:34:25 <qgil> Then my next (and basically last) proposal is that such topics are formulated from a "user need" perspective.
21:34:27 <brion> i think the trick is making sure we pick apart those ramifications and then follow up on them :)
21:34:53 <DanielK_WMDE> what tgr said.
21:35:31 <qgil> 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 <tgr> as an off-topic example, take to controversy around the previous ED
21:36:02 <brion> 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 <tgr> 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 <DanielK_WMDE> 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 <subbu> interesting example tgr :)
21:36:36 <tgr> some concerns simply cannot be directly mapped to user needs; that does not mean they don't affect them
21:36:50 <bd808> all topics have some impact on user experience, but some are difficult to measure (e.g. mean time to code review)
21:36:53 <qgil> DanielK_WMDE, "implement new features quickly" has a clear impact in the user experience.
21:36:56 <tgr> if MediaWiki was written in assemply, we would have a major problem
21:36:59 <brion> #info <tgr> some concerns simply cannot be directly mapped to user needs; that does not mean they don't affect them
21:37:10 <brion> #info <qgil> "implement new features quickly" has a clear impact in the user experience.
21:37:18 <tgr> asking for it to be discussed in terms of specific user-visible features would not be helpful at all
21:37:21 <tgr> etc
21:37:26 <DanielK_WMDE> qgil: sure, but the "topic" will not be anything that you can relate to a *specific* end user need.
21:37:34 <brion> So definitely there are some open questions in how to select and prioritize the topics
21:38:03 <brion> #info some possible disagreement on how much user-visibility topics need
21:38:04 <qgil> DanielK_WMDE, going back to my aborted example "Improving mobile (web and app) experiences."
21:38:21 <cscott> 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 <cscott> ie, find the user-facing thing that your architecture improvement will enable, then pitch that
21:38:53 <qgil> 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 <brion> 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 <cscott> 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 <bd808> the main problem there is that we are all scared to change the UI
21:39:48 <qgil> Can you provide examples of topics that you think should be high priority at the Summit 2017, please?
21:39:49 <cscott> 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 <cscott> seems like we're having that sort of discussion again here
21:39:58 <qgil> I want to run the "user need" check with each of them.
21:40:08 <qgil> Because I believe that we actuallky agreemore than disagree.
21:40:30 <qgil> It is just that apparently mentioning "product" is counterproductive in certain contexts like this one. ;)
21:40:50 <brion> #info [on prioritizing within wmf] <cscott> 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 <tgr> 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 <robla> ArchCom-RFCs should be driven by user need. If they aren't, that's a problem larger than WikiDev17 planning
21:41:06 <qgil> tgr, propose a topic, please. A real one.
21:41:21 <cscott> 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 <tgr> last year we had a pretty successful discussion about problems with code review, for example
21:41:37 <robla> qgil: I would like to (again) leave it open to RFCs that get proposed by an early-ish deadline
21:41:40 <tgr> there is no way to meaningfully discuss that in terms of mobile or whatever
21:41:47 <cscott> but i think they also wanted simpler stuff, like just pushing the image metadata into the wikidata db.
21:42:00 <cscott> so you could have a wikidata fact corresponding to the license of the commons item, eg.
21:42:13 <cscott> which would have approximately zero user-facing impact. but still a big architectural change.
21:42:14 <DanielK_WMDE> 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 <qgil> 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 <tgr> there was another successful session on dependency injection (which has been followed up with code changes, largely thanks to DanielK_WMDE)
21:42:43 <cscott> so, "store commons metadata in wikidata" is another possible topic.
21:42:52 <tgr> again, not meaningfully debatable in terms of specific products
21:42:55 <DanielK_WMDE> tgr: \o/
21:43:06 <subbu> 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 <cscott> DanielK_WMDE: you probably remember that commons/wikidata discussion in wikimania/mexico better than i do?
21:43:20 <qgil> 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 <brion> #info <subbu> 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 <brion> if necessary, they can be pitched as such?
21:43:39 <DanielK_WMDE> qgil: yes, actually
21:44:03 <cscott> 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 <brion> 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 <brion> maybe less about the _team_ than about having a place on the board to hang things
21:45:20 <tgr> the WMF is interested in Commonsdata, just not interested enough to actually put resources to it :/
21:45:29 <cscott> 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 <qgil> 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 <cscott> 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 <brion> :D
21:46:31 <tgr> 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 <cscott> i'd like to think a little of both, personally
21:46:51 <tgr> ideally architecture planning would happen before the fuckup
21:46:57 <subbu> cscott, right.
21:47:05 <brion> #info <cscott> 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 <brion> #info <cscott> i'd like to think a little of both, personally
21:47:32 <brion> ok so I think that's a major outstanding question we can't resolve today
21:47:34 <cscott> 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 <brion> but finding the question is good!
21:47:54 <qgil> 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 <subbu> 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 <DanielK_WMDE> 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 <brion> #info <cscott> 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 <brion> #info <qgil> 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 <brion> qgil: cscott: i think we have some agreement in the essence
21:48:44 <brion> which is that we gotta know how to Get Stuff Done
21:48:51 <brion> which is dependent in part on picking the right topics
21:48:55 <qgil> DanielK_WMDE, they do, because many user needs are stuck or progress very slowly because those problems aren't solved
21:48:59 <brion> and in part on knowing how to follow up on them
21:49:00 <robla> I think I've gotta come back to http://www.daedtech.com/human-cost-tech-debt/
21:49:03 <cscott> 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 <large refactor>"
21:49:09 <tgr> 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 <DanielK_WMDE> 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 <subbu> cscott, qgil, i think you might be right though that there is more agreement here than the discussions indicate.
21:49:25 <brion> #info [reminder: tech debt rules all] <robla> I think I've gotta come back to http://www.daedtech.com/human-cost-tech-debt/
21:49:28 <subbu> tgr, agreed.
21:49:39 <cscott> qgil: i agree on the "productive discussions that lead to actual plans, resources, releases, deployments"
21:49:52 <DanielK_WMDE> +1
21:50:04 <subbu> +1 as well.
21:50:11 <cscott> 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 <brion> +many :D
21:50:31 <brion> #info much agreement on "productive discussions that lead to actual plans, resources, releases, deployments" being key!
21:50:32 <cscott> instead of everyone just agreeing that the architectural change *should* be done w/o any concrete plan for doing it
21:50:52 <brion> yassssss
21:50:53 <robla> 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 <DanielK_WMDE> #link http://www.daedtech.com/human-cost-tech-debt/
21:51:20 <qgil> 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 <cscott> 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 <brion> 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 <tgr> 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 <qgil> 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 <DanielK_WMDE> qgil: is "structured content handling" too unspecific as a topic?
21:52:36 <tgr> I would hope we are slowly moving towards resolving that disconnect in the opposite direction
21:52:37 <robla> 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 <cscott> tgr: there were also c-level/management/engineering disconnects, so that's not 100% surprising.
21:52:56 <DanielK_WMDE> robla: hear hear
21:53:00 <tgr> and not by not even talking about those issues
21:53:21 <DanielK_WMDE> #info <robla> 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 <cscott> 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 <tgr> cscott: and theoretically we are slowly moving to resolve those as well
21:53:26 <brion> #info <qgil> 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 <brion> 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 <tgr> most prominently with the CTO hire
21:53:51 <brion> qgil: good point, let's make sure we keep talking these next few weeks and hammer out some ideas :)
21:54:12 <cscott> 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 <robla> cscott: agreed!
21:54:45 <cscott> do we have a CTO hire?
21:54:48 <qgil> DanielK_WMDE, how does "structured content handling" affect our ability to make users happier?
21:54:52 <brion> i like this idea
21:54:54 * cscott gets out of the loop easily
21:55:08 <brion> in theory, the january timeline gives us a good chance to lead into annual planning with bottom-up dev input
21:55:16 <brion> we just need to implement :)
21:55:17 <cscott> qgil: that would be an excellent discussion to have at the summit ;)
21:55:19 <tgr> qgil: you keep mentioning "repeating last year"
21:55:21 <brion> ok folks! we have 5 minutes left
21:55:27 <DanielK_WMDE> qgil: better search, easier re-user, automatic localization, better support for workflows...
21:55:32 <tgr> do we have any evaluation of how successful last year was?
21:55:32 <brion> so let's stay on topic and wrap up soon :)
21:55:49 <brion> #info <tgr> do we have any evaluation of how successful last year was?
21:55:57 <qgil> DanielK_WMDE, there you go. :)
21:55:57 <tgr> I don't necessarily disagree but I'm wary of groupthink where everyone just assumes it is so
21:56:13 <robla> I think we should probably take the remainder of the conversation to #wikimedia-tech, wikitech-l@, and the Phab task
21:56:17 <DanielK_WMDE> 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 <qgil> tgr, I replied to this point in wikitech-l earlier today.
21:56:37 <brion> i recall talk of the satisfaction numbers being relatively high :)
21:56:40 <qgil> tgr, my summary: the summit itself, very well; before and after requires lots of improvements
21:56:47 <brion> but we have less of a clear picture of did it have strong outcomes or not
21:56:59 <brion> *nod*
21:57:07 <DanielK_WMDE> 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 <brion> robla: yep! good discussions here and i think we've got a few key points to concentrate on now
21:57:35 <tgr> qgil: all I can find is you saying "My evaluation is based on the number of non-WMF developers specializing on
21:57:38 <tgr> tools, templates, bots, mobile apps, MediaWiki, and other users of our
21:57:40 <tgr> APIs, and what they got from the event. It is also based on how much
21:57:41 <qgil> 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 <tgr> outreach effort we managed to put into assuring that the participation from
21:57:44 <brion> #info <robla> I think we should probably take the remainder of the conversation to #wikimedia-tech, wikitech-l@, and the Phab task
21:57:46 <tgr> these sectors was rich and diverse." which seems to be a different issue altogether
21:58:29 <qgil> tgr, https://lists.wikimedia.org/pipermail/wikitech-l/2016-September/086469.html
21:58:40 <brion> #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 <robla> program note: next week's IRC conv is cancelled because of WMF planning session happening in SF
21:59:00 <robla> #info program note: next week's IRC conv is cancelled because of WMF planning session happening in SF
21:59:01 <brion> #info program note: next week's IRC conv is cancelled because of WMF planning session happening in SF
21:59:04 <brion> heh
21:59:07 <Scott_WUaS> (Thanks for this ever so generative and focused conversation!)
21:59:10 <robla> hee :-)
21:59:12 <brion> ok thanks everybody!
21:59:15 <brion> #endmeeting