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

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

Description

Agenda

Location: #wikimedia-office IRC channel
Meeting type: Problem definition
Time: Weekly, Wednesday 21:00 UTC (2pm PDT, 23:00 CEST)
Topic:
- Ad hoc ArchCom office hour
  - Briefly touching on Shadow Namespaces (T91162)
  - (last minute addition) T141938: Prepare a program for Wikimedia Developer Summit 2017 to effectively address current high level movement needs

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

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

1	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/
2	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.
3	21:01:34 <wm-labs-meetbot_> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
4	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_'
5	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.
6	21:01:34 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
7	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_'
8	21:01:44 <brion> i'm always sure i do that one wrong :D
9	21:01:47 <robla> o/
10	21:02:00 <brion> ok so while people are filtering in...
11	21:02:21 <brion> ...we had some discussion on wikitech-l list recently about Wikimedia Dev Summit
12	21:02:25 <robla> T141938
13	21:02:25 <stashbot> T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938
14	21:02:29 <brion> thx
15	21:02:41 <brion> #info phab ref T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938
16	21:02:42 <stashbot> T141938: Wikimedia Developer Summit Program - https://phabricator.wikimedia.org/T141938
17	21:03:04 <robla> qgil: thanks for showing up on such short notice!
18	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!
19	21:03:33 <brion> qgil is main organizer
20	21:03:45 <qgil> I'm very happy that you found time for it also on such a short notice.
21	21:03:45 <brion> qgil: would you like to start us off with some background or thoughts?
22	21:04:09 <qgil> Should I assume that the audience of this meeting has followed the wikitech-l thread or not?
23	21:04:26 <robla> I said we'd briefly touch on shadow namespaces, but I think we can consider it touched on :-)
24	21:04:39 <brion> anybody need a refresher on the recent thread?
25	21:04:47 <legoktm> o/
26	21:04:53 <qgil> ok
27	21:05:04 <brion> #info reminder we are not talking about shadow namespaces this time around as previously scheduled
28	21:05:10 <legoktm> okay :P
29	21:05:18 <qgil> brion started an interesting thread last week about "opening up" the Summit
30	21:05:38 <qgil> an interesting discussion followed
31	21:06:04 <qgil> the I contributed the current point of view of rfarrand as Summit organizer and myself as budget owner
32	21:06:11 <qgil> The key ideas being
33	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
34	21:07:23 <qgil> ... and these key topcs should be defined from a product / feature / user perspective
35	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)
36	21:07:44 <Scott_WUaS> (Hi All!)
37	21:07:49 <rfarrand> hey everyone!
38	21:07:52 <qgil> and then be discussed considering all the technical implications (software / architecture / infrastructure)
39	21:08:11 * DanielK_WMDE waves to rfarrand
40	21:08:15 <rfarrand> :D
41	21:08:22 <qgil> This would be a change compared to previous years, where architecture was put upfront (simplifying things a lot)
42	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
43	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.
44	21:09:12 <brion> DanielK_WMDE: that's a good obversation
45	21:09:23 <qgil> (I think this is a fair short summary of the topic to be discussed here?)
46	21:09:38 <brion> #info "unconference" style can open participation once we know who to bring based on what to accomplish
47	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)
48	21:09:56 <brion> qgil: thanks!
49	21:10:08 <robla> here's how I'd like to summarize the position I've taken on wikitech-l:
50	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)?
51	21:10:19 <robla> meeple27 had a great way of putting this: “In-person, annual version of wikitech-l”
52	21:10:35 <brion> #info <robla> meeple27 had a great way of putting this: “In-person, annual version of wikitech-l”
53	21:10:39 <robla> (he was paraphrasing what I was fumbling to describe)
54	21:10:54 <DanielK_WMDE> to me, wikimania always seemed to be the best place for (2), tbh
55	21:11:13 <brion> indeed, wikimania was brought up a few times in thread
56	21:11:34 <brion> and may be an easier place to reach a wider array of "users"/editors
57	21:11:39 <robla> I think there's what wikitech-l currently is, and what we want our "newspaper of record" to be
58	21:11:46 <bd808> sadly WMF engineering is not always "active" at wikimania
59	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"?
60	21:11:56 <brion> whereas WMDS grew out of the staff tech days and tends to be staff-heavy and tech-heavy already
61	21:12:06 <robla> DanielK_WMDE: I think "how"
62	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)
63	21:12:36 <DanielK_WMDE> bd808: perhaps that could be improved, then...
64	21:12:36 <qgil> I don't understand why you see "product" as kind of opposed to "architecture"
65	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
66	21:12:42 <tgr> one thing to be mindful of is that focusing on end users will prevent certain topics from being effectively discussed
67	21:12:51 <tgr> MediaWiki is a complex software with several levels of abstraction on top of each other
68	21:12:58 <tgr> it is unrealistic to expect a single event to span all those levels
69	21:13:09 <tgr> so focusing on the levels available to end users means the other end of the scale will suffer
70	21:13:10 * robla agrees with tgr
71	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)
72	21:13:17 <tgr> which is a fine tradeoff in general, but we already have other events for that
73	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
74	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.
75	21:13:42 <legoktm> in any user-facing sense*
76	21:13:44 <qgil> the architecture exists because there are product needs
77	21:13:56 <brion> does product always mean user-facing UI?
78	21:14:10 <brion> i feel like internal-facing things ought to be productizable as well in how we think about them
79	21:14:17 <brion> with internal "consumers"/users
80	21:14:26 * brion puts mod hat back on
81	21:14:35 <legoktm> qgil: I disagree. Unless the need here is "a functional software platform to build on top of"
82	21:15:00 <qgil> My point is: we could discuss about 1001 topics, but some topics are actually more important / urgent than others.
83	21:15:11 <robla> ori had a really really good article he made me aware of: http://www.daedtech.com/human-cost-tech-debt/
84	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.
85	21:15:26 <DanielK_WMDE> *cause
86	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....
87	21:15:39 <Scott_WUaS> (this is an ArchCom - Architecture Committee meeting - defining here further relationship with wiki products could make sense too)
88	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.
89	21:16:29 <robla> qgil: I think it'll be important to make this a really valuable learning event for WMF's future CTO
90	21:16:30 <DanielK_WMDE> qgil: yes, i see that disconnect.
91	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....
92	21:16:38 <Scott_WUaS> (Is there a "ProdCom" meeting to parallel this, by any chance, or similar?)
93	21:16:41 <bd808> qgil: to me that is largely a problem of "Product" (i.e. WMF managers) not listening to the engineers.
94	21:16:53 <legoktm> qgil: I think many people would see it the other way around, that the priorities were decided later were disconnected ;)
95	21:16:56 <qgil> subbu, this is exactly what I am talking about
96	21:17:04 <qgil> I think we are getting lost in the use of words
97	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
98	21:17:17 <qgil> Let me put an example
99	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.
100	21:17:40 * robla eagerly awaits qgil's example
101	21:17:41 <legoktm> We should discuss a set of both IMO.
102	21:17:58 <qgil> The 2016 WMF strategy says somewhere "Improving mobile (web and app) experiences."
103	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.
104	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.
105	21:18:05 <qgil> Let's pick that just for the sake of having something
106	21:18:38 <robla> qgil: should we pick something that you pick arbitrarily for the sake of having something?
107	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.
108	21:18:56 <qgil> Oh no, robla you can provide an example if you prefer.
109	21:19:05 <bd808> DanielK_WMDE: not so obvious in some discussions I've had with past Wikimedia Foundation board members ;)
110	21:19:25 <brion> perhaps more important than the low-level "who do we invite to which event" thoughts I started with :)
111	21:19:33 <DanielK_WMDE> bd808: yea, i can relate to that....
112	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
113	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
114	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?
115	21:21:07 <qgil> So we spend that money better in the projects and tech that will get the work done?
116	21:21:07 <brion> qgil: :)
117	21:21:30 <brion> qgil: is it an event to support implementing the plan, or an event to support making the plan?
118	21:21:40 <tgr> qgil: how would you answer the same question about Wikimania and the Wikimedia Hackathon?
119	21:22:02 <qgil> brion, both, but still having an impact on current and future plans should be the driver.
120	21:22:06 <bd808> and is it about the WMF's plans or the plans of the MediaWiki developer community?
121	21:22:48 <qgil> We are mixing many conversations...
122	21:23:06 <tgr> IMO conference events are not off-sites
123	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?
124	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?
125	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?
126	21:23:29 <tgr> for razor focus on WMF annual plans, we have the rest of the year
127	21:23:39 <brion> legoktm: i think it does :)
128	21:23:52 <subbu> legoktm, yes. i think so.
129	21:24:06 <legoktm> #info <legoktm> Having a good architecture is what enables developers to implement the rest of the strategy / annual plans.
130	21:24:12 <brion> +1
131	21:24:34 <qgil> "a good architecture" for what? User needs still guide the architecture.
132	21:24:54 <brion> qgil: yes, ideally we have some kind of data flow...
133	21:25:06 <brion> ... from user needs to dev ideas to basic prioritization/triage ...
134	21:25:16 <brion> ... to planning how best to design/implement (architecture) ...
135	21:25:21 <brion> ... to actually doing the work.
136	21:25:26 <subbu> qgil, but, aren't user needs already part of the annual plan, quarter goals, community wishlist survey processes?
137	21:25:29 <brion> that sounds very "waterfall"y though :D
138	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.
139	21:25:50 <qgil> no
140	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?
141	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?
142	21:25:56 <qgil> what I am saying is
143	21:26:23 <tgr> DanielK_WMDE: +1
144	21:26:46 <tgr> MediaWiki is cutting edge as a wiki software but very much not cutting edge as a development environment
145	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.
146	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
147	21:27:10 <DanielK_WMDE> yea...
148	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).
149	21:27:50 <DanielK_WMDE> (should apache development be driven by end user needs, or to dev needs?)
150	21:27:57 <qgil> Do you agree with the idea of picking a few topics and macking sure that everybody involved is invited?
151	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
152	21:28:19 <bd808> qgil: and is the change about then about narrowing compared to past efforts?
153	21:28:20 <DanielK_WMDE> qgil: sure, for appropriate values of "topics"
154	21:28:44 <robla> As we expand beyond WMF in invites, I would like to expand our developer community
155	21:28:50 <legoktm> qgil: Would "fix page editing" aka T120414 be an acceptable "user need"? Seems like all users need to edit pages.
156	21:28:50 <stashbot> T120414: RFC: MediaWiki should provide a pluggable registry for editor interfaces - https://phabricator.wikimedia.org/T120414
157	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).
158	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.
159	21:29:14 <legoktm> And EditPage.php is easily our best (or worst) example of terrible tech debt.
160	21:29:43 <DanielK_WMDE> legoktm: yea, we'll definitly needs this for MCR
161	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
162	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
163	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.
164	21:30:28 <tgr> we did pick some topics in 2016: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016#Discussion_areas
165	21:30:51 <tgr> presumably we are having this conversation because we do not all agree that worked well
166	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.
167	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?
168	21:30:55 <qgil> "Software engineering" is an area, not a topic.
169	21:31:11 <tgr> what would be an example of a topic?
170	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
171	21:31:29 <Scott_WUaS> qgil: :)
172	21:31:52 <brion> or on some specific user-facing issue, or whatever :)
173	21:31:57 <tgr> content format, content access, UI seem topics to me
174	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
175	21:32:32 <qgil> #3 Central Global Repository for Templates, Lua modules, and Gadgets
176	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".
177	21:33:01 <qgil> That is a topic reflecting "user needs", that has many ramifications all the way to architecture and infrastructure.
178	21:33:25 <subbu> tech debt and maintenance and refactoring as well.
179	21:33:50 <subbu> ramifications all the way up to user needs .. looking up.
180	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.
181	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)...
182	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
183	21:34:25 <qgil> Then my next (and basically last) proposal is that such topics are formulated from a "user need" perspective.
184	21:34:27 <brion> i think the trick is making sure we pick apart those ramifications and then follow up on them :)
185	21:34:53 <DanielK_WMDE> what tgr said.
186	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?
187	21:35:32 <tgr> as an off-topic example, take to controversy around the previous ED
188	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"
189	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"?
190	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.
191	21:36:34 <subbu> interesting example tgr :)
192	21:36:36 <tgr> some concerns simply cannot be directly mapped to user needs; that does not mean they don't affect them
193	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)
194	21:36:53 <qgil> DanielK_WMDE, "implement new features quickly" has a clear impact in the user experience.
195	21:36:56 <tgr> if MediaWiki was written in assemply, we would have a major problem
196	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
197	21:37:10 <brion> #info <qgil> "implement new features quickly" has a clear impact in the user experience.
198	21:37:18 <tgr> asking for it to be discussed in terms of specific user-visible features would not be helpful at all
199	21:37:21 <tgr> etc
200	21:37:26 <DanielK_WMDE> qgil: sure, but the "topic" will not be anything that you can relate to a specific end user need.
201	21:37:34 <brion> So definitely there are some open questions in how to select and prioritize the topics
202	21:38:03 <brion> #info some possible disagreement on how much user-visibility topics need
203	21:38:04 <qgil> DanielK_WMDE, going back to my aborted example "Improving mobile (web and app) experiences."
204	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
205	21:38:47 <cscott> ie, find the user-facing thing that your architecture improvement will enable, then pitch that
206	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.
207	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
208	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
209	21:39:35 <bd808> the main problem there is that we are all scared to change the UI
210	21:39:48 <qgil> Can you provide examples of topics that you think should be high priority at the Summit 2017, please?
211	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
212	21:39:56 <cscott> seems like we're having that sort of discussion again here
213	21:39:58 <qgil> I want to run the "user need" check with each of them.
214	21:40:08 <qgil> Because I believe that we actuallky agreemore than disagree.
215	21:40:30 <qgil> It is just that apparently mentioning "product" is counterproductive in certain contexts like this one. ;)
216	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
217	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
218	21:40:57 <robla> ArchCom-RFCs should be driven by user need. If they aren't, that's a problem larger than WikiDev17 planning
219	21:41:06 <qgil> tgr, propose a topic, please. A real one.
220	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
221	21:41:22 <tgr> last year we had a pretty successful discussion about problems with code review, for example
222	21:41:37 <robla> qgil: I would like to (again) leave it open to RFCs that get proposed by an early-ish deadline
223	21:41:40 <tgr> there is no way to meaningfully discuss that in terms of mobile or whatever
224	21:41:47 <cscott> but i think they also wanted simpler stuff, like just pushing the image metadata into the wikidata db.
225	21:42:00 <cscott> so you could have a wikidata fact corresponding to the license of the commons item, eg.
226	21:42:13 <cscott> which would have approximately zero user-facing impact. but still a big architectural change.
227	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.
228	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...
229	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)
230	21:42:43 <cscott> so, "store commons metadata in wikidata" is another possible topic.
231	21:42:52 <tgr> again, not meaningfully debatable in terms of specific products
232	21:42:55 <DanielK_WMDE> tgr: \o/
233	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?
234	21:43:18 <cscott> DanielK_WMDE: you probably remember that commons/wikidata discussion in wikimania/mexico better than i do?
235	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?
236	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,
237	21:43:36 <brion> if necessary, they can be pitched as such?
238	21:43:39 <DanielK_WMDE> qgil: yes, actually
239	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.
240	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 :)
241	21:45:00 <brion> maybe less about the _team_ than about having a place on the board to hang things
242	21:45:20 <tgr> the WMF is interested in Commonsdata, just not interested enough to actually put resources to it :/
243	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.
244	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.
245	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
246	21:46:22 <brion> :D
247	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
248	21:46:35 <cscott> i'd like to think a little of both, personally
249	21:46:51 <tgr> ideally architecture planning would happen before the fuckup
250	21:46:57 <subbu> cscott, right.
251	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
252	21:47:15 <brion> #info <cscott> i'd like to think a little of both, personally
253	21:47:32 <brion> ok so I think that's a major outstanding question we can't resolve today
254	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)
255	21:47:36 <brion> but finding the question is good!
256	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
257	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?
258	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?
259	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)
260	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
261	21:48:36 <brion> qgil: cscott: i think we have some agreement in the essence
262	21:48:44 <brion> which is that we gotta know how to Get Stuff Done
263	21:48:51 <brion> which is dependent in part on picking the right topics
264	21:48:55 <qgil> DanielK_WMDE, they do, because many user needs are stuck or progress very slowly because those problems aren't solved
265	21:48:59 <brion> and in part on knowing how to follow up on them
266	21:49:00 <robla> I think I've gotta come back to http://www.daedtech.com/human-cost-tech-debt/
267	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>"
268	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
269	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".
270	21:49:13 <subbu> cscott, qgil, i think you might be right though that there is more agreement here than the discussions indicate.
271	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/
272	21:49:28 <subbu> tgr, agreed.
273	21:49:39 <cscott> qgil: i agree on the "productive discussions that lead to actual plans, resources, releases, deployments"
274	21:49:52 <DanielK_WMDE> +1
275	21:50:04 <subbu> +1 as well.
276	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
277	21:50:12 <brion> +many :D
278	21:50:31 <brion> #info much agreement on "productive discussions that lead to actual plans, resources, releases, deployments" being key!
279	21:50:32 <cscott> instead of everyone just agreeing that the architectural change should be done w/o any concrete plan for doing it
280	21:50:52 <brion> yassssss
281	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
282	21:51:07 <DanielK_WMDE> #link http://www.daedtech.com/human-cost-tech-debt/
283	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.
284	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.
285	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
286	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
287	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
288	21:52:27 <DanielK_WMDE> qgil: is "structured content handling" too unspecific as a topic?
289	21:52:36 <tgr> I would hope we are slowly moving towards resolving that disconnect in the opposite direction
290	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
291	21:52:45 <cscott> tgr: there were also c-level/management/engineering disconnects, so that's not 100% surprising.
292	21:52:56 <DanielK_WMDE> robla: hear hear
293	21:53:00 <tgr> and not by not even talking about those issues
294	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
295	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.
296	21:53:23 <tgr> cscott: and theoretically we are slowly moving to resolve those as well
297	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
298	21:53:26 <brion> repeating the siautation of previous years is higher
299	21:53:30 * robla has to be careful about pronouns like "we" and "they" because he is part of many "we" groups
300	21:53:32 <tgr> most prominently with the CTO hire
301	21:53:51 <brion> qgil: good point, let's make sure we keep talking these next few weeks and hammer out some ideas :)
302	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?
303	21:54:44 <robla> cscott: agreed!
304	21:54:45 <cscott> do we have a CTO hire?
305	21:54:48 <qgil> DanielK_WMDE, how does "structured content handling" affect our ability to make users happier?
306	21:54:52 <brion> i like this idea
307	21:54:54 * cscott gets out of the loop easily
308	21:55:08 <brion> in theory, the january timeline gives us a good chance to lead into annual planning with bottom-up dev input
309	21:55:16 <brion> we just need to implement :)
310	21:55:17 <cscott> qgil: that would be an excellent discussion to have at the summit ;)
311	21:55:19 <tgr> qgil: you keep mentioning "repeating last year"
312	21:55:21 <brion> ok folks! we have 5 minutes left
313	21:55:27 <DanielK_WMDE> qgil: better search, easier re-user, automatic localization, better support for workflows...
314	21:55:32 <tgr> do we have any evaluation of how successful last year was?
315	21:55:32 <brion> so let's stay on topic and wrap up soon :)
316	21:55:49 <brion> #info <tgr> do we have any evaluation of how successful last year was?
317	21:55:57 <qgil> DanielK_WMDE, there you go. :)
318	21:55:57 <tgr> I don't necessarily disagree but I'm wary of groupthink where everyone just assumes it is so
319	21:56:13 <robla> I think we should probably take the remainder of the conversation to #wikimedia-tech, wikitech-l@, and the Phab task
320	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.
321	21:56:20 <qgil> tgr, I replied to this point in wikitech-l earlier today.
322	21:56:37 <brion> i recall talk of the satisfaction numbers being relatively high :)
323	21:56:40 <qgil> tgr, my summary: the summit itself, very well; before and after requires lots of improvements
324	21:56:47 <brion> but we have less of a clear picture of did it have strong outcomes or not
325	21:56:59 <brion> nod
326	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.
327	21:57:29 <brion> robla: yep! good discussions here and i think we've got a few key points to concentrate on now
328	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
329	21:57:38 <tgr> tools, templates, bots, mobile apps, MediaWiki, and other users of our
330	21:57:40 <tgr> APIs, and what they got from the event. It is also based on how much
331	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.
332	21:57:43 <tgr> outreach effort we managed to put into assuring that the participation from
333	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
334	21:57:46 <tgr> these sectors was rich and diverse." which seems to be a different issue altogether
335	21:58:29 <qgil> tgr, https://lists.wikimedia.org/pipermail/wikitech-l/2016-September/086469.html
336	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
337	21:58:43 <robla> program note: next week's IRC conv is cancelled because of WMF planning session happening in SF
338	21:59:00 <robla> #info program note: next week's IRC conv is cancelled because of WMF planning session happening in SF
339	21:59:01 <brion> #info program note: next week's IRC conv is cancelled because of WMF planning session happening in SF
340	21:59:04 <brion> heh
341	21:59:07 <Scott_WUaS> (Thanks for this ever so generative and focused conversation!)
342	21:59:10 <robla> hee :-)
343	21:59:12 <brion> ok thanks everybody!
344	21: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 Meetings	upcoming	all since 2016-03-30
14:00 PT ArchCom-RFC Meetings	upcoming	all since 2015-09-09

Recurring Event
Next
Previous

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

Details

Invitees

TechCom
• RobLa-WMF
JanZerebecki
MarkAHershberger
daniel

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 mentioned this in T91162: RFC: Shadow namespaces.

• 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 mentioned this in T141938: Prepare a program for Wikimedia Developer Summit 2017 to effectively address current high level movement needs.Sep 6 2016, 10:14 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

14:59:15 <wm-labs-meetbot_> Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.html
14:59:15 <wm-labs-meetbot_> Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.txt
14:59:15 <wm-labs-meetbot_> Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.wiki
14:59:15 <wm-labs-meetbot_> Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2016/wikimedia-office.2016-09-07-21.01.log.html

• RobLa-WMF mentioned this in P3996 ArchCom-RFC-2016W36-irc-E269.txt.Sep 7 2016, 10:03 PM

• RobLa-WMF updated the event description. (Show Details)

• RobLa-WMF updated the event description. (Show Details)Sep 23 2016, 11:15 PM

• RobLa-WMF mentioned this in T146749: Consider using Phabricator Calendar events to schedule Wikimedia Developer Summit sessions.Oct 6 2016, 5:57 AM

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).

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