HomePhabricator

ArchCom RFC Meeting W36: ad hoc (2016-09-07, #wikimedia-office)
ActivePublic

Hosted by daniel on Sep 7 2016, 9:00 PM - 10:00 PM.

Description

Agenda

Meeting summary

  • phab ref T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938 (brion, 21:02:41)
  • reminder we are not talking about shadow namespaces this time around as previously scheduled (brion, 21:05:04)
  • 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 (brion, 21:08:34)
  • "unconference" style can open participation once we know who to bring based on what to accomplish (brion, 21:09:38)
  • 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) (brion, 21:09:47)
  • <robla> meeple27 had a great way of putting this: “In-person, annual version of wikitech-l” (brion, 21:10:35)
  • 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 (brion, 21:12:37)
  • 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) (brion, 21:13:12)
  • [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.... (brion, 21:16:33)
  • <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. (brion, 21:18:00)
  • [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 (brion, 21:20:23)
  • [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? (brion, 21:23:20)
  • <legoktm> Having a good architecture is what enables developers to implement the rest of the strategy / annual plans. (legoktm, 21:24:06)
  • [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). (brion, 21:28:51)
  • [on purpose for inviting] <robla> As we expand beyond WMF in invites, I would like to expand our developer community (brion, 21:29:57)
  • <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. (brion, 21:33:50)
  • <tgr> some concerns simply cannot be directly mapped to user needs; that does not mean they don't affect them (brion, 21:36:59)
  • <qgil> "implement new features quickly" has a clear impact in the user experience. (brion, 21:37:10)
  • some possible disagreement on how much user-visibility topics need (brion, 21:38:03)
  • [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 (brion, 21:40:50)
  • <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, (brion, 21:43:36)
  • <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 (brion, 21:47:05)
  • <cscott> i'd like to think a little of both, personally (brion, 21:47:15)
  • <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) (brion, 21:48:09)
  • <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 (brion, 21:48:21)
  • [reminder: tech debt rules all] <robla> I think I've gotta come back to http://www.daedtech.com/human-cost-tech-debt/ (brion, 21:49:25)
  • much agreement on "productive discussions that lead to actual plans, resources, releases, deployments" being key! (brion, 21:50:31)
  • LINK: http://www.daedtech.com/human-cost-tech-debt/ (DanielK_WMDE, 21:51:07)
  • <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 (DanielK_WMDE, 21:53:21)
  • <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 (brion, 21:53:26)
  • <tgr> do we have any evaluation of how successful last year was? (brion, 21:55:49)
  • <robla> I think we should probably take the remainder of the conversation to #wikimedia-tech, wikitech-l@, and the Phab task (brion, 21:57:44)
  • 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 (brion, 21:58:40)
  • program note: next week's IRC conv is cancelled because of WMF planning session happening in SF (robla, 21:59:00)
  • program note: next week's IRC conv is cancelled because of WMF planning session happening in SF (brion, 21:59:01)

Meeting ended at 21:59:15 UTC.

Log

121: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/
221: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.
321:01:34 <wm-labs-meetbot_> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
421: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_'
521: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.
621:01:34 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
721: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_'
821:01:44 <brion> i'm always sure i do that one wrong :D
921:01:47 <robla> o/
1021:02:00 <brion> ok so while people are filtering in...
1121:02:21 <brion> ...we had some discussion on wikitech-l list recently about Wikimedia Dev Summit
1221:02:25 <robla> T141938
1321:02:25 <stashbot> T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938
1421:02:29 <brion> thx
1521:02:41 <brion> #info phab ref T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938
1621:02:42 <stashbot> T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938
1721:03:04 <robla> qgil: thanks for showing up on such short notice!
1821: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!
1921:03:33 <brion> qgil is main organizer
2021:03:45 <qgil> I'm very happy that you found time for it also on such a short notice.
2121:03:45 <brion> qgil: would you like to start us off with some background or thoughts?
2221:04:09 <qgil> Should I assume that the audience of this meeting has followed the wikitech-l thread or not?
2321:04:26 <robla> I said we'd briefly touch on shadow namespaces, but I think we can consider it touched on :-)
2421:04:39 <brion> anybody need a refresher on the recent thread?
2521:04:47 <legoktm> o/
2621:04:53 <qgil> ok
2721:05:04 <brion> #info reminder we are not talking about shadow namespaces this time around as previously scheduled
2821:05:10 <legoktm> okay :P
2921:05:18 <qgil> brion started an interesting thread last week about "opening up" the Summit
3021:05:38 <qgil> an interesting discussion followed
3121:06:04 <qgil> the I contributed the current point of view of rfarrand as Summit organizer and myself as budget owner
3221:06:11 <qgil> The key ideas being
3321: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
3421:07:23 <qgil> ... and these key topcs should be defined from a product / feature / user perspective
3521: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)
3621:07:44 <Scott_WUaS> (Hi All!)
3721:07:49 <rfarrand> hey everyone!
3821:07:52 <qgil> and then be discussed considering all the technical implications (software / architecture / infrastructure)
3921:08:11 * DanielK_WMDE waves to rfarrand
4021:08:15 <rfarrand> :D
4121:08:22 <qgil> This would be a change compared to previous years, where architecture was put upfront (simplifying things a lot)
4221: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
4321: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.
4421:09:12 <brion> DanielK_WMDE: that's a good obversation
4521:09:23 <qgil> (I think this is a fair short summary of the topic to be discussed here?)
4621:09:38 <brion> #info "unconference" style can open participation once we know who to bring based on what to accomplish
4721: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)
4821:09:56 <brion> qgil: thanks!
4921:10:08 <robla> here's how I'd like to summarize the position I've taken on wikitech-l:
5021:10:13 <DanielK_WMDE> so it seems to me time year we tried to do (1), and this time we are going for (2)?
5121:10:19 <robla> meeple27 had a great way of putting this: “In-person, annual version of wikitech-l”
5221:10:35 <brion> #info <robla> meeple27 had a great way of putting this: “In-person, annual version of wikitech-l”
5321:10:39 <robla> (he was paraphrasing what I was fumbling to describe)
5421:10:54 <DanielK_WMDE> to me, wikimania always seemed to be the best place for (2), tbh
5521:11:13 <brion> indeed, wikimania was brought up a few times in thread
5621:11:34 <brion> and may be an easier place to reach a wider array of "users"/editors
5721:11:39 <robla> I think there's what wikitech-l currently is, and what we want our "newspaper of record" to be
5821:11:46 <bd808> sadly WMF engineering is not always "active" at wikimania
5921: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"?
6021:11:56 <brion> whereas WMDS grew out of the staff tech days and tends to be staff-heavy and tech-heavy already
6121:12:06 <robla> DanielK_WMDE: I think "how"
6221: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)
6321:12:36 <DanielK_WMDE> bd808: perhaps that could be improved, then...
6421:12:36 <qgil> I don't understand why you see "product" as kind of opposed to "architecture"
6521: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
6621:12:42 <tgr> one thing to be mindful of is that focusing on end users will prevent certain topics from being effectively discussed
6721:12:51 <tgr> MediaWiki is a complex software with several levels of abstraction on top of each other
6821:12:58 <tgr> it is unrealistic to expect a single event to span all those levels
6921:13:09 <tgr> so focusing on the levels available to end users means the other end of the scale will suffer
7021:13:10 * robla agrees with tgr
7121: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)
7221:13:17 <tgr> which is a fine tradeoff in general, but we already have other events for that
7321: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
7421:13:22 <legoktm> qgil: because they're different? I mean, the architecture of MediaWikiServices has nothing to do with a product, in any sense.
7521:13:42 <legoktm> in any user-facing sense*
7621:13:44 <qgil> the architecture exists because there are product needs
7721:13:56 <brion> does product always mean user-facing UI?
7821:14:10 <brion> i feel like internal-facing things ought to be productizable as well in how we think about them
7921:14:17 <brion> with internal "consumers"/users
8021:14:26 * brion puts mod hat back on
8121:14:35 <legoktm> qgil: I disagree. Unless the need here is "a functional software platform to build on top of"
8221:15:00 <qgil> My point is: we could discuss about 1001 topics, but some topics are actually more important / urgent than others.
8321:15:11 <robla> ori had a really really good article he made me aware of: http://www.daedtech.com/human-cost-tech-debt/
8421: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.
8521:15:26 <DanielK_WMDE> *cause
8621: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....
8721:15:39 <Scott_WUaS> (this is an ArchCom - Architecture Committee meeting - defining here further relationship with wiki products could make sense too)
8821: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.
8921:16:29 <robla> qgil: I think it'll be important to make this a really valuable learning event for WMF's future CTO
9021:16:30 <DanielK_WMDE> qgil: yes, i see that disconnect.
9121: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....
9221:16:38 <Scott_WUaS> (Is there a "ProdCom" meeting to parallel this, by any chance, or similar?)
9321:16:41 <bd808> qgil: to me that is largely a problem of "Product" (i.e. WMF managers) not listening to the engineers.
9421:16:53 <legoktm> qgil: I think many people would see it the other way around, that the priorities were decided later were disconnected ;)
9521:16:56 <qgil> subbu, this is exactly what I am talking about
9621:17:04 <qgil> I think we are getting lost in the use of words
9721: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
9821:17:17 <qgil> Let me put an example
9921: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.
10021:17:40 * robla eagerly awaits qgil's example
10121:17:41 <legoktm> We should discuss a set of both IMO.
10221:17:58 <qgil> The 2016 WMF strategy says somewhere "Improving mobile (web and app) experiences."
10321: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.
10421: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.
10521:18:05 <qgil> Let's pick that just for the sake of having something
10621:18:38 <robla> qgil: should we pick something that you pick arbitrarily for the sake of having something?
10721: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.
10821:18:56 <qgil> Oh no, robla you can provide an example if you prefer.
10921:19:05 <bd808> DanielK_WMDE: not so obvious in some discussions I've had with past Wikimedia Foundation board members ;)
11021:19:25 <brion> perhaps more important than the low-level "who do we invite to which event" thoughts I started with :)
11121:19:33 <DanielK_WMDE> bd808: yea, i can relate to that....
11221: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
11321: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
11421: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?
11521:21:07 <qgil> So we spend that money better in the projects and tech that will get the work done?
11621:21:07 <brion> qgil: :)
11721:21:30 <brion> qgil: is it an event to support implementing the plan, or an event to support making the plan?
11821:21:40 <tgr> qgil: how would you answer the same question about Wikimania and the Wikimedia Hackathon?
11921:22:02 <qgil> brion, both, but still having an impact on current and future plans should be the driver.
12021:22:06 <bd808> and is it about the WMF's plans or the plans of the MediaWiki developer community?
12121:22:48 <qgil> We are mixing many conversations...
12221:23:06 <tgr> IMO conference events are not off-sites
12321: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?
12421: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?
12521: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?
12621:23:29 <tgr> for razor focus on WMF annual plans, we have the rest of the year
12721:23:39 <brion> legoktm: i think it does :)
12821:23:52 <subbu> legoktm, yes. i think so.
12921:24:06 <legoktm> #info <legoktm> Having a good architecture is what enables developers to implement the rest of the strategy / annual plans.
13021:24:12 <brion> +1
13121:24:34 <qgil> "a good architecture" for what? User needs still guide the architecture.
13221:24:54 <brion> qgil: yes, ideally we have some kind of data flow...
13321:25:06 <brion> ... from user needs to dev ideas to basic prioritization/triage ...
13421:25:16 <brion> ... to planning how best to design/implement (architecture) ...
13521:25:21 <brion> ... to actually doing the work.
13621:25:26 <subbu> qgil, but, aren't user needs already part of the annual plan, quarter goals, community wishlist survey processes?
13721:25:29 <brion> that sounds very "waterfall"y though :D
13821: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.
13921:25:50 <qgil> no
14021: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?
14121: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?
14221:25:56 <qgil> what I am saying is
14321:26:23 <tgr> DanielK_WMDE: +1
14421:26:46 <tgr> MediaWiki is cutting edge as a wiki software but very much not cutting edge as a development environment
14521: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.
14621: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
14721:27:10 <DanielK_WMDE> yea...
14821: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).
14921:27:50 <DanielK_WMDE> (should apache development be driven by end user needs, or to dev needs?)
15021:27:57 <qgil> Do you agree with the idea of picking a few topics and macking sure that everybody involved is invited?
15121: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
15221:28:19 <bd808> qgil: and is the change about then about narrowing compared to past efforts?
15321:28:20 <DanielK_WMDE> qgil: sure, for appropriate values of "topics"
15421:28:44 <robla> As we expand beyond WMF in invites, I would like to expand our developer community
15521:28:50 <legoktm> qgil: Would "fix page editing" aka T120414 be an acceptable "user need"? Seems like all users need to edit pages.
15621:28:50 <stashbot> T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces - https://phabricator.wikimedia.org/T120414
15721: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).
15821:29:00 <qgil> Narrowing beforehand in order to have time to invite people beyond the devs that anyway will attend is one change, yes.
15921:29:14 <legoktm> And EditPage.php is easily our best (or worst) example of terrible tech debt.
16021:29:43 <DanielK_WMDE> legoktm: yea, we'll definitly needs this for MCR
16121:29:55 <robla> we should figure out who we *wish* was on wikitech-l, to invite to help us pay off our technical debt
16221:29:57 <brion> #info [on purpose for inviting] <robla> As we expand beyond WMF in invites, I would like to expand our developer community
16321: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.
16421:30:28 <tgr> we did pick some topics in 2016: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Discussion_areas
16521:30:51 <tgr> presumably we are having this conversation because we do not all agree that worked well
16621: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.
16721: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?
16821:30:55 <qgil> "Software engineering" is an area, not a topic.
16921:31:11 <tgr> what would be an example of a topic?
17021:31:28 <brion> eg if we want to concentrate on a tech debt issue, what do we need to do to make that happen
17121:31:29 <Scott_WUaS> qgil: :)
17221:31:52 <brion> or on some specific user-facing issue, or whatever :)
17321:31:57 <tgr> content format, content access, UI seem topics to me
17421: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
17521:32:32 <qgil> #3 Central Global Repository for Templates, Lua modules, and Gadgets
17621: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".
17721:33:01 <qgil> That is a topic reflecting "user needs", that has many ramifications all the way to architecture and infrastructure.
17821:33:25 <subbu> tech debt and maintenance and refactoring as well.
17921:33:50 <subbu> ramifications all the way up to user needs .. looking up.
18021: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.
18121: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)...
18221:34:20 <tgr> qgil: you seem to be saying that there cannot exist any useful discussion which does not touch on user-visible features
18321:34:25 <qgil> Then my next (and basically last) proposal is that such topics are formulated from a "user need" perspective.
18421:34:27 <brion> i think the trick is making sure we pick apart those ramifications and then follow up on them :)
18521:34:53 <DanielK_WMDE> what tgr said.
18621: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?
18721:35:32 <tgr> as an off-topic example, take to controversy around the previous ED
18821: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"
18921: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"?
19021: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.
19121:36:34 <subbu> interesting example tgr :)
19221:36:36 <tgr> some concerns simply cannot be directly mapped to user needs; that does not mean they don't affect them
19321:36:50 <bd808> all topics have some impact on user experience, but some are difficult to measure (e.g. mean time to code review)
19421:36:53 <qgil> DanielK_WMDE, "implement new features quickly" has a clear impact in the user experience.
19521:36:56 <tgr> if MediaWiki was written in assemply, we would have a major problem
19621:36:59 <brion> #info <tgr> some concerns simply cannot be directly mapped to user needs; that does not mean they don't affect them
19721:37:10 <brion> #info <qgil> "implement new features quickly" has a clear impact in the user experience.
19821:37:18 <tgr> asking for it to be discussed in terms of specific user-visible features would not be helpful at all
19921:37:21 <tgr> etc
20021:37:26 <DanielK_WMDE> qgil: sure, but the "topic" will not be anything that you can relate to a *specific* end user need.
20121:37:34 <brion> So definitely there are some open questions in how to select and prioritize the topics
20221:38:03 <brion> #info some possible disagreement on how much user-visibility topics need
20321:38:04 <qgil> DanielK_WMDE, going back to my aborted example "Improving mobile (web and app) experiences."
20421: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
20521:38:47 <cscott> ie, find the user-facing thing that your architecture improvement will enable, then pitch that
20621: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.
20721: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
20821: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
20921:39:35 <bd808> the main problem there is that we are all scared to change the UI
21021:39:48 <qgil> Can you provide examples of topics that you think should be high priority at the Summit 2017, please?
21121: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
21221:39:56 <cscott> seems like we're having that sort of discussion again here
21321:39:58 <qgil> I want to run the "user need" check with each of them.
21421:40:08 <qgil> Because I believe that we actuallky agreemore than disagree.
21521:40:30 <qgil> It is just that apparently mentioning "product" is counterproductive in certain contexts like this one. ;)
21621: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
21721: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
21821:40:57 <robla> ArchCom-RFCs should be driven by user need. If they aren't, that's a problem larger than WikiDev17 planning
21921:41:06 <qgil> tgr, propose a topic, please. A real one.
22021: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
22121:41:22 <tgr> last year we had a pretty successful discussion about problems with code review, for example
22221:41:37 <robla> qgil: I would like to (again) leave it open to RFCs that get proposed by an early-ish deadline
22321:41:40 <tgr> there is no way to meaningfully discuss that in terms of mobile or whatever
22421:41:47 <cscott> but i think they also wanted simpler stuff, like just pushing the image metadata into the wikidata db.
22521:42:00 <cscott> so you could have a wikidata fact corresponding to the license of the commons item, eg.
22621:42:13 <cscott> which would have approximately zero user-facing impact. but still a big architectural change.
22721: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.
22821: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...
22921:42:36 <tgr> there was another successful session on dependency injection (which has been followed up with code changes, largely thanks to DanielK_WMDE)
23021:42:43 <cscott> so, "store commons metadata in wikidata" is another possible topic.
23121:42:52 <tgr> again, not meaningfully debatable in terms of specific products
23221:42:55 <DanielK_WMDE> tgr: \o/
23321: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?
23421:43:18 <cscott> DanielK_WMDE: you probably remember that commons/wikidata discussion in wikimania/mexico better than i do?
23521: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?
23621: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,
23721:43:36 <brion> if necessary, they can be pitched as such?
23821:43:39 <DanielK_WMDE> qgil: yes, actually
23921: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.
24021: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 :)
24121:45:00 <brion> maybe less about the _team_ than about having a place on the board to hang things
24221:45:20 <tgr> the WMF is interested in Commonsdata, just not interested enough to actually put resources to it :/
24321: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.
24421: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.
24521: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
24621:46:22 <brion> :D
24721: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
24821:46:35 <cscott> i'd like to think a little of both, personally
24921:46:51 <tgr> ideally architecture planning would happen before the fuckup
25021:46:57 <subbu> cscott, right.
25121: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
25221:47:15 <brion> #info <cscott> i'd like to think a little of both, personally
25321:47:32 <brion> ok so I think that's a major outstanding question we can't resolve today
25421: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)
25521:47:36 <brion> but finding the question is good!
25621: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
25721: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?
25821: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?
25921: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)
26021: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
26121:48:36 <brion> qgil: cscott: i think we have some agreement in the essence
26221:48:44 <brion> which is that we gotta know how to Get Stuff Done
26321:48:51 <brion> which is dependent in part on picking the right topics
26421:48:55 <qgil> DanielK_WMDE, they do, because many user needs are stuck or progress very slowly because those problems aren't solved
26521:48:59 <brion> and in part on knowing how to follow up on them
26621:49:00 <robla> I think I've gotta come back to http://www.daedtech.com/human-cost-tech-debt/
26721: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>"
26821: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
26921: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".
27021:49:13 <subbu> cscott, qgil, i think you might be right though that there is more agreement here than the discussions indicate.
27121: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/
27221:49:28 <subbu> tgr, agreed.
27321:49:39 <cscott> qgil: i agree on the "productive discussions that lead to actual plans, resources, releases, deployments"
27421:49:52 <DanielK_WMDE> +1
27521:50:04 <subbu> +1 as well.
27621: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
27721:50:12 <brion> +many :D
27821:50:31 <brion> #info much agreement on "productive discussions that lead to actual plans, resources, releases, deployments" being key!
27921:50:32 <cscott> instead of everyone just agreeing that the architectural change *should* be done w/o any concrete plan for doing it
28021:50:52 <brion> yassssss
28121: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
28221:51:07 <DanielK_WMDE> #link http://www.daedtech.com/human-cost-tech-debt/
28321: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.
28421: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.
28521: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
28621: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
28721: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
28821:52:27 <DanielK_WMDE> qgil: is "structured content handling" too unspecific as a topic?
28921:52:36 <tgr> I would hope we are slowly moving towards resolving that disconnect in the opposite direction
29021: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
29121:52:45 <cscott> tgr: there were also c-level/management/engineering disconnects, so that's not 100% surprising.
29221:52:56 <DanielK_WMDE> robla: hear hear
29321:53:00 <tgr> and not by not even talking about those issues
29421: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
29521: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.
29621:53:23 <tgr> cscott: and theoretically we are slowly moving to resolve those as well
29721: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
29821:53:26 <brion> repeating the siautation of previous years is higher
29921:53:30 * robla has to be careful about pronouns like "we" and "they" because he is part of many "we" groups
30021:53:32 <tgr> most prominently with the CTO hire
30121:53:51 <brion> qgil: good point, let's make sure we keep talking these next few weeks and hammer out some ideas :)
30221: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?
30321:54:44 <robla> cscott: agreed!
30421:54:45 <cscott> do we have a CTO hire?
30521:54:48 <qgil> DanielK_WMDE, how does "structured content handling" affect our ability to make users happier?
30621:54:52 <brion> i like this idea
30721:54:54 * cscott gets out of the loop easily
30821:55:08 <brion> in theory, the january timeline gives us a good chance to lead into annual planning with bottom-up dev input
30921:55:16 <brion> we just need to implement :)
31021:55:17 <cscott> qgil: that would be an excellent discussion to have at the summit ;)
31121:55:19 <tgr> qgil: you keep mentioning "repeating last year"
31221:55:21 <brion> ok folks! we have 5 minutes left
31321:55:27 <DanielK_WMDE> qgil: better search, easier re-user, automatic localization, better support for workflows...
31421:55:32 <tgr> do we have any evaluation of how successful last year was?
31521:55:32 <brion> so let's stay on topic and wrap up soon :)
31621:55:49 <brion> #info <tgr> do we have any evaluation of how successful last year was?
31721:55:57 <qgil> DanielK_WMDE, there you go. :)
31821:55:57 <tgr> I don't necessarily disagree but I'm wary of groupthink where everyone just assumes it is so
31921:56:13 <robla> I think we should probably take the remainder of the conversation to #wikimedia-tech, wikitech-l@, and the Phab task
32021: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.
32121:56:20 <qgil> tgr, I replied to this point in wikitech-l earlier today.
32221:56:37 <brion> i recall talk of the satisfaction numbers being relatively high :)
32321:56:40 <qgil> tgr, my summary: the summit itself, very well; before and after requires lots of improvements
32421:56:47 <brion> but we have less of a clear picture of did it have strong outcomes or not
32521:56:59 <brion> *nod*
32621: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.
32721:57:29 <brion> robla: yep! good discussions here and i think we've got a few key points to concentrate on now
32821:57:35 <tgr> qgil: all I can find is you saying "My evaluation is based on the number of non-WMF developers specializing on
32921:57:38 <tgr> tools, templates, bots, mobile apps, MediaWiki, and other users of our
33021:57:40 <tgr> APIs, and what they got from the event. It is also based on how much
33121: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.
33221:57:43 <tgr> outreach effort we managed to put into assuring that the participation from
33321: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
33421:57:46 <tgr> these sectors was rich and diverse." which seems to be a different issue altogether
33521:58:29 <qgil> tgr, https://lists.wikimedia.org/pipermail/wikitech-l/2016-September/086469.html
33621: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
33721:58:43 <robla> program note: next week's IRC conv is cancelled because of WMF planning session happening in SF
33821:59:00 <robla> #info program note: next week's IRC conv is cancelled because of WMF planning session happening in SF
33921:59:01 <brion> #info program note: next week's IRC conv is cancelled because of WMF planning session happening in SF
34021:59:04 <brion> heh
34121:59:07 <Scott_WUaS> (Thanks for this ever so generative and focused conversation!)
34221:59:10 <robla> hee :-)
34321:59:12 <brion> ok thanks everybody!
34421:59:15 <brion> #endmeeting

People present (lines said)

  • brion (96)
  • qgil (63)
  • tgr (44)
  • DanielK_WMDE (34)
  • robla (28)
  • cscott (27)
  • subbu (14)
  • legoktm (14)
  • bd808 (8)
  • Scott_WUaS (5)
  • wm-labs-meetbot (3)
  • stashbot (3)
  • wm-labs-meetbot_ (3)
  • rfarrand (2)

Other meetings

Architecture meetings
13:00 PT ArchCom Planning Meetingsupcomingall since 2016-03-30
14:00 PT ArchCom-RFC Meetingsupcomingall since 2015-09-09

Recurring Event

Event Series
This event is an instance of E66: ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office), and repeats every week.

Event Timeline

If @Legoktm is available and wants to talk about it, then T91162: RFC: Shadow namespaces is our first choice. Backup plan: we hold a triage meeting.

RobLa-WMF renamed this event from ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office) to ArchCom RFC Meeting W36: (tentative) Shadow Namespaces (2016-09-07, #wikimedia-office).Sep 6 2016, 3:48 AM
RobLa-WMF renamed this event from ArchCom RFC Meeting W36: (tentative) Shadow Namespaces (2016-09-07, #wikimedia-office) to ArchCom RFC Meeting W36: TBD (2016-09-07, #wikimedia-office).Sep 6 2016, 10:12 PM
RobLa-WMF renamed this event from ArchCom RFC Meeting W36: TBD (2016-09-07, #wikimedia-office) to ArchCom RFC Meeting W36: ad hoc (2016-09-07, #wikimedia-office).Sep 7 2016, 5:21 PM
RobLa-WMF updated the event description. (Show Details)
Qgil invited: ; uninvited: .Sep 7 2016, 6:58 PM
RobLa-WMF updated the event description. (Show Details)Sep 23 2016, 11:15 PM
daniel renamed this event from ArchCom RFC Meeting W36: ad hoc (2016-09-07, #wikimedia-office) to ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office).Nov 21 2016, 6:11 PM
daniel changed the host of this event from RobLa-WMF to daniel.
daniel uninvited: Qgil.
daniel updated the event description. (Show Details)
daniel updated the event description. (Show Details)Dec 9 2016, 7:41 AM
daniel renamed this event from ArchCom RFC Meeting Wxx: <topic TBD> (<see "Starts" field>, #wikimedia-office) to ArchCom RFC Meeting W36: ad hoc (2016-09-07, #wikimedia-office).