[18:00:04] Hello everyone! During the next hour we will be holding office hours for the Wikimedia Developer Summit. Anyone is welcome to ask any questions that they have. vcoleman debt & I are here to answer your questions! [18:00:15] \o/ yay [18:00:25] Hi everyone! [18:00:27] No agenda, just make sure people have the oportunity to ask whatever they like [18:01:00] We have made a lot of updates to the wiki recently: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2018 [18:01:18] \o/ [18:02:04] Topic leaders are starting to work on session planning and can probably use your help here: https://phabricator.wikimedia.org/project/view/3119/ [18:04:39] rfarrand, vcoleman: how should we as attendees interact with the phab tasks? [18:06:38] Depends on the task :-) [18:07:19] I would suggest reading them at least so that everyone is aware of the plan for each session [18:07:25] *nod* [18:08:15] probably worth thinking about the Qs in https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2018/Purpose_and_Results for each track and just scribbling some prep notes :D [18:08:39] yes, that would be great [18:09:15] brion, some of the sessions already have "Pre-event questions for discussion" sections, e.g. https://phabricator.wikimedia.org/T183313 which should/could be discussed in the phab task over the next 12 days. [18:09:24] We want the outcomes of the summit sessions to lead into recommendations for priority areas for the Phase II of the strategy work [18:09:34] quiddity: ah perfect! i'll just click through them all later :D [18:10:16] Phab is also the best place for people who are not attending the summit to follow along and be involved at this stage [18:11:03] it's still unclear to me what exactly participants are supposed to do at the summit; maybe I missed some announcement? [18:11:08] are we all supposed to give a presentation of the position statement? or should those worked into a single item per topic? or does each topic leader decide separately how best to proceed? [18:12:27] <_joe_> If I had to give a talk, I would've expected to be notified at a earlier date than now. [18:12:32] to echo rfarrand, Phab should also have all the links to notes, etc for the sessions during the DevSummit [18:13:19] more generally, what preparation should we do before the summit? e.g. two years ago (I think) people were expected to hash things out in Phabricator beforehand to the extent possible and arrive with a clear understanding of what needs to be discussed; that worked pretty well IMO [18:13:23] * DanielK_WMDE_ is late to the party [18:14:08] Each session leader or leaders will have decided how to work their topic - whether they would like to have talks, round table discussions or panels for example. I suggest reading Phab and connecting with your session lead. [18:14:25] I'd like to know how non-attendees will be able to follow along during and/or afterwards, too. [18:14:51] <_joe_> I was about to ask about how to interact with non-attendees [18:14:53] vcoleman: the documents I have linked as prep reading in https://phabricator.wikimedia.org/T183313 are not public, so non-staff cannot read them. How can we fix this? [18:14:55] <_joe_> :) [18:14:58] _joe_ no worries there :) although anyone is welcome to contact session leaders (though the phab tasks) and get invoved in the planning of the sessions [18:15:16] There will be extensive note taking to share with non attendees [18:15:27] apergos, _joe_: session outcomes should be documented in the tasks, and discussion will continue there, I suppose. [18:15:43] The sessions are very broad and high-level. there will be plenty of need for further discussion [18:16:03] quiddity is working on the documentation side of things with melodykramer [18:16:08] @DanielK - yes, please! [18:16:09] <_joe_> It's not clear to me if I can pick wich sessions to participate in, given they're not in parallel [18:16:24] it would be nice if I could find out from https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2018/Participants who my session lead is, without reading through all session material [18:16:30] more constructively, I can add those links if you think the grouping is stable enough :) [18:16:31] <_joe_> and I think my input could be valuable in various situatins [18:16:43] eg should we stick to one track or feel free to track-hop? [18:16:48] tgr: sure, that would be helpful! :) [18:17:07] what about presentations, if there are any? or panel discussions, would they be made available to the broader wmf community? [18:17:43] apergos: all sessions will be essentially workshops. [18:18:08] they are deliberation sessions. no big presentations or panels. [18:18:48] brion: you mean, switch sessions during a break? how well that works will depend on the sessions, i guess [18:19:02] *nod* [18:19:06] _joe_ / brion: anyone is free to move around from session to session as they like. Cindy worked hard to try and make sure that session interests didnt not overlap based on what people wrote in their position statements. She put a lot of thought into trying to make sure that there was as little interest overlap as possible [18:19:19] tgr: "your" session lead depends on which session you attend :) [18:19:30] classic unconference style has the idea that you should be able to move to wherever is most productive; if a track ain't floating your boat there's always others [18:19:38] :D [18:20:06] ( I suspect a number of us will be hopping somewhat, though I would recommend picking a main one ) [18:20:09] it's unclear to me that this uses the unconference approach though brion (does it?) [18:20:22] DanielK_WMDE_: I assume everyone is supposed to attend the session where their position statement belongs, at least [18:20:25] exactly my query purpose :) [18:20:34] rfarrand: position statement topics and people expertise might not coincide though [18:20:48] no, no unconference. quite the opposite. but i suppose nobody will mind if you switch sessions. [18:20:57] some of us have a position statement that was not categorized. shall we be flitty butterflies? :-D [18:21:01] yeah, just porting in that concept [18:21:18] volans: yes, agree. This is also another reason why we only have two ongoing sessions at a time maximum [18:21:47] apergos: yes, free to go to whatever interests you the most at any point or hang out by the snacks :) [18:21:51] apergos: i don't think the idea was to *assing* anyone to a session. just attend whatever interests you. [18:21:58] ok! [18:21:59] assigning* [18:22:01] unless you are a session lead - then you should be around for your session :) [18:22:09] apergos, quantum butterflies. Based on super-position statements. ;-) [18:22:36] you laugh now but wait til that goes on my nametag [18:22:46] apergos :D [18:23:29] Have we missed any questions so far? [18:23:38] oh i see - the idea behind "assigning" position papers (and thus, people) to sessions was to minimize conflict. but this was by no means intended to tell people what to attend. [18:23:49] <_joe_> DanielK_WMDE_: ok thanks [18:24:13] "Cindy worked hard to try and make sure that session interests didnt not overlap based on what people wrote in their position statements" > for future consideration, it would be better to just ask people what sessions they are interested in, as the position statement is not necessarily indicative of that [18:24:23] +1 [18:24:24] * debt muses oh...nametags! [18:24:55] <_joe_> tgr: I was about to say the same [18:25:12] tgr / _joe_: we can do this next year [18:25:22] tgr: it really happened the other way around: sessions were defined by clustering position statements. session topics were derived that way [18:25:24] tgr: thanks for explaining better what I was trying to say before ;) [18:25:26] (if it ends up being the same kind of event, that is not decided) [18:25:30] <_joe_> well I hope next year we won't have a closed number of participants [18:25:40] indeed [18:25:49] rfarrand: Is it too late to suggest a new session? [18:26:04] _joe_: we always do. there are always more people interested than we can accommodate. at all events we have. [18:26:13] but i also hope we can be more inclusive next time [18:26:35] <_joe_> DanielK_WMDE_: yeah you know what I meant, last year there were what, 80 / 90 people? [18:26:44] kaldari: at thispoint, yes. If you tell me what you are thinking I can bring it to tomorrows program commitee meeting and see if it can be combined or will already be covered with another session in some way. [18:26:53] All-hands has time for technical discussion though [18:27:14] _joe_: more like 130 I think... too many for constructive problem solving, really. [18:27:22] <_joe_> we're down to 50/60 this year? I know for a fact only two people from my team is the lowest attendance in 4 years, and I think it's a negative [18:27:43] <_joe_> DanielK_WMDE_: I strongly object, my experience last year was of an incredbily productive dev summit [18:27:45] rfarrand: but that'S only for wmf staff. i won't be able to attend. [18:28:22] just suggesting the current alternatives, another is to do a tech talk on the topics that are not included. I can help organize those [18:28:26] rfarrand: No worries. I was thinking it would be nice to have a session devoted to the latest Community Wishlist Survey, either at Dev Summit or All Hands. So that people who wanted to discuss any of the 10 new projects from the survey could discuss them. [18:29:58] kaldari: since the summit focuses on strategy this year, there is little room left for concrete technical discussions. I very much agree we need room for them somewhere, but it's not clear yet when or where that will be. [18:31:01] <_joe_> I am unsure how strategy can be laid out in terms of what we need to do as an engineering community, without concrete technical discussions being part of it [18:31:01] If it doesn't happen in January, maybe at the Hackathon, although we'll already be well into some of the projects by then. [18:31:05] DanielK_WMDE_: I don't think the conference size has much to do with problem solving ability; you'd just have more sessions in parallel (which is bad if the goal is to identify a core group of contributors and make sure everyone gets some insight into as many topics as possible, but a position statement approach wouldn't make much sense for such a goal anyway) [18:31:23] <_joe_> tgr: +1 again [18:31:45] if you have goals of hasing out a pan for x y and z, those are just sessions, and people self select to show up [18:31:48] *plan [18:31:54] OTOH there are budget limits obviously, and if we can e.g. have a larger hackathon at the cost of a smaller dev summit, that's a good tradeoff IMO [18:32:04] <_joe_> but focusing on the dev summit as it is, I have a question. [18:32:14] (not to mention SF vs. some place with sane prices) [18:32:14] <_joe_> how should I prepare for the sessions? [18:32:17] but I've found the cross-fertilization at larger conferences to be very helpful indeed, to my thinking in smaller sessions [18:32:34] <_joe_> just follow phabricator? Add a document of mine to those tickets before the summit? [18:33:30] _joe_: that's at least a good start :) [18:34:04] I'd also recommend to think about the session topic in the context of the desired outcomes. I have tried to give a rough guide here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2018/Purpose_and_Results [18:35:42] <_joe_> DanielK_WMDE_: I read that page a few times, it didn't help me much. I hope we can get to the summit with well framed topics to discuss, or it will most likely get nowhere [18:36:40] <_joe_> that's btw why talks + discussion are a good way to have many people participate to a session - the talk can frame a thesis and that can be the focus of the discussion. [18:36:45] yes, i shared that concern. we should use the phab tasks to try and provide that framing. [18:36:49] tgr: I agree about hackathons [18:36:51] we are learning a lot from this smaller format as it relates to the needs of the dev community and we will reflect that in the game plan for dev events next fiscal. Budget is certainly a consideration [18:37:01] i mentioned this earlier to a session leader, but I'm one of those people that needs to prep in advance for discussions like these, so the sooner there is framing the better [18:37:30] I'd like to reemphasize the importance of a shared understanding of what level of preparation is expected [18:37:39] *nod* [18:37:43] apergos: can you help to provide that framing? [18:38:06] tgr: I will add that to the meeting agenda for the Program Commitee tomorrow and we will come up with something to send out to participants in the next email [18:38:07] how would I do that? I mean, I'd be happy to if I had even a vague notion of what it would look like [18:38:10] for example one approach is that everyone puts what they have to say on Phabricator and everyone who goes to a session is expected to have read the position of others beforehand [18:38:33] that's very productive but also a lot of effort [18:41:11] even if we just had the lists of current and planned capablities for each session, and links to ocs for anyone who wanted to get the gist for something they hadn't been aware of... dunno [18:41:17] *links to docs [18:42:10] apergos: as a session lead I can tell you that I have the same problem. [18:42:16] apergos: we have asked session leaders to include all of that in their Phab tasks. Another apporach would be to ping tasks with questions if anything about the session is not clear. [18:42:33] I can tell you what *I* want to discuss. But I can't tell you what we, as a group, *should* be discussing [18:42:55] yes, please ask questions [18:43:25] The Topic Leaders are still forming their ideas for the sessions now - so its actually a great time to have influence over what happens [18:44:19] Topic Leaders can reach out to all the folks that submitted position papers to help influence how they want to run their sessions [18:44:46] it's not something that just *one* person is in charge of their session...it takes a village sometimes! [18:45:10] That is exactly the expectation [18:45:41] <_joe_> good to know :) [18:46:35] \o/ [18:46:46] Wiki is also free for editing, so people are welcome to help reword things if there is a better way to get some of these ideas across [18:48:11] I would expect that each participant would be prepared to speak to the topics that they wrote about. Maybe they want to give a talk. Maybe they want others to discuss a topic... Whatever they think is needed in order to nail down a priority area for Phase II [18:49:08] We are also hoping to have a followup session at the WMF Conf in Berlin to firm up the recommendations coming out of the summit [18:49:09] vcoleman: can you clarify "give a talk." I think what you mean is being ready to speak up in an already planned session with their point of view but just want to be sure. :) [18:49:33] yes, that's what I meant [18:49:58] tgr: "it would be better to just ask people what sessions they are interested in, as the position statement is not necessarily indicative of that." Agreed, absolutely, but I worked with what I had. [18:50:04] We can follow up at the Barcelona hackathon also! [18:50:05] I read through *all* of the position statements and tagged them with some free-form tags pulling out some key points. I then clustered them into about 16 sessions with common themes. [18:50:10] I'd imagine the overlap of participants between the devsummit and the WMFconf to be tiny [18:50:15] We then met as a committee and decided on 8 as the optimal number of sessions given the amount of time and space. [18:50:22] Since we had two parallel tracks, I wanted to at least make an effort not to have two highly correlated tracks scheduled at the same time. [18:50:28] So, I used a bit of Lua and a query to build a matrix to deconflict sessions based upon the themes in the position statements. http://cindy.wmflabs.org/devsummit/index.php/Main_Page#tab=Session_Matrix [18:50:29] <_joe_> CindyCicaleseWMF: thank you very much for working on that [18:50:33] I would have loved to have more information about the interests of the authors, but I worked with what I had. [18:50:51] More devs in Barcelona than the Berlin conference I think. [18:51:14] _joe_: you're welcome :-) [18:51:15] We can have followups in both events. [18:51:33] vcoleman: i don't think there will be any time for talks by participants, considering we have 60+45 minutes for all of "mediawiki architecture". [18:51:33] <_joe_> (also I feel for the pain of having to write LUA. It's never pleasant :)) [18:52:16] Berlin will be strategy heavy so a good place to inject the outcomes of the dev summit in the planning process for those of us who will be there [18:52:42] vcoleman: do we know whether there will be room for tech strategy at wmcon? were participants selected with tech strategy in mind? [18:53:02] so iow if I want to attend a session I should think about what a position statement might have been if I had wrote one for that session? [18:53:16] and come prepared to discuss? [18:53:21] CindyCicaleseWMF: I realize criticising is easy and doing actual work is hard, but just asking participants what sessions they are interested in works well in such a case IMO [18:53:29] apergos: that sounds like an excellent approach, yes [18:53:38] just throw up a google sheet and have everyone add X marks [18:54:25] tgr: that sounds like a good solution [18:54:26] We can work with Nicole to make a room/session available [18:54:35] 5 min warning everyone! [18:54:48] vcoleman: wmcon is invite-only and in practice pretty much limited to board and employees of affiliate orgs [18:54:48] <_joe_> apergos: that, or read what others wrote and be ready to discuss that [18:55:03] <_joe_> the division Cindy did is a good starting point [18:55:06] You can ping any of us at any time of course, but if you have any remaining publuc questions either ask them here / now or on the event talk page [18:55:10] if people heavily involved with development are there, that's only by accident [18:55:10] of course I will have read what others wrote carefully [18:55:34] *public [18:55:45] (OTOH, there should be a good representation of people involved with *funding* development) [18:56:23] tgr: sure, something to consider for next time. But, the key point is that anybody is free to attend any session. The matrix was just to try to help in scheduling to make an educated guess at which sessions are highly correlated and which are not. [18:56:31] that's a problem. Tech should be well represented in strategy discussions and leadership in general. We kinda depend on it for most everything :-) [18:57:40] tgr: the idea is that the summit provides the people that are involved with funding development with the information they need to make strategic decisions [18:58:34] vcoleman: well, so far, wmcon was mostly about the day-to-day of running a chapter. [18:58:43] until last year, i mean [18:59:12] CindyCicaleseWMF: exactly :) [18:59:30] DanielK_WMDE_: I'm somewhat skeptical of decisionmaking where funders are involved but subject-matter expertise is not [19:00:01] Wikimedia lacks a decent tech decisionmaking forum, in my opinion [19:00:50] the devsummit usually lacks participation from funding decisionmakers, wmcon lacks participation of tech people, Wikimedia is too large and noisy [19:01:01] tgr: yes. and that's what the summit should be. in the past it was trying to be that as well asa hackathon and a conferences. trying to be too much at once. [19:01:03] that always reminds me of the old idea of making more inclusive breakout committees associated with techcom [19:01:14] this time, it's very small and very high level. let's see how that goes [19:01:20] we might want to think about which topics need more ongoing work & discussion [19:01:33] afterwards :D [19:01:50] bofs [19:01:52] brion: the problem is that runnign such working groups takdes a lot of time and effort. [19:02:07] DanielK_WMDE_: agreed, that's why we haven't spun em up :D [19:02:17] but judicious use where applicable might be good to think about [19:02:20] TechCom is our tech decision making forum in my view [19:02:23] DanielK_WMDE_: a recurring complaint about the summit is that leadership is not represented, and the current rules seem to make that worse [19:02:45] I have the vague notion that techcom is a little more narrowly focusses than tgr was thinking [19:02:48] vcoleman: TechCom seems to be a decision-suggesting forum at best [19:02:53] *focussed [19:03:11] it has no power to actually decide for something to happen [19:03:30] (or decision-approving, maybe) [19:03:44] tgr: it seems to me that we have more product-side participation this time around. which is a good thing. [19:04:03] <_joe_> tgr: it's also reactive and not proactive, at the moment, and we need to change that too [19:04:07] we are changing that! re the TechCom - maybe we do another IRC or maybe we can squeeze in a quick discussion at the summit [19:04:08] OK - hours up! Thanks everyone for attending and talking with us [19:04:33] Btw, Katherine will be speaking at the summit and so will Toby [19:05:33] _joe_: a lot of funding bodies are purely reactive (including most inside Wikimedia), that's not necessarily bad [19:05:50] \o/ [19:05:51] although personally I'd also prefer a more proactive TechCom [19:05:59] +1 :) [19:06:21] if only there were another committee that could handle all the rfc work so the techcom could do other things ( :-P :-P ) [19:06:39] tbh I'm very happy with the rfc handling process, the way it's evolved I mean [19:07:02] vcoleman: here's to hoping they'll also listen at the summit which is IMO more crucial :) [19:07:07] * _joe_ off [19:07:25] +1 to all of the above - we are changing the TechCom slowly - adding capacity and membership [19:08:42] gone, thanks everyone [19:09:37] thanks everyone who was involved in organizing the dev summit! I tend to focus on complaints but on the whole I'm pretty happy about it; and clearly a huge amount of work and thought went into it and it's good that we keep experimenting with new formats [19:09:49] * tgr wanders off