Here's one that I've noticed:

In T183312#3903314, @Niharika wrote:

I think doing ""why am I here?" introductions by each participant" will end up being a big time sinkhole. Getting a general idea of participant expectations beforehand would be way better. We can do that using an etherpad or on this task, whichever people prefer.

We can also use that etherpad for answering -

• What are the important unanswered questions? What are the important strategic goals?
• What critical outcomes must be achieved to answer these questions/achieve these goals?

Thanks @debt. I'd like to add that a few sessions seem to collect participant thoughts on the spot and somehow figure out the "main" concerns. I'm not sure if there's a concrete plan for how that'll happen. If everyone was to just take turns talking, it could pretty quickly lead the conversation off on a tangent because the topics are really broad.

I think we can either make people put down a keyword or two about what they expect from the session/what they find most important/what's their concern on a big whiteboard or use post-its on a wall for that. Then we can cluster related keywords and come up with recurring themes which we could take turns to go through. I'd prefer if we use an etherpad for this because that lets participants and remotees participate ahead of the meeting, giving them time to think and articulate their thoughts on the topic.

In short-

1. Float an etherpad for each session well ahead of the conference.
2. Ask participants to fill out a set template of questions in the etherpad.
3. Consolidate response in feedback and figure out recurring concerns/themes.
4. Use that to guide the session so conversation doesn't go off-topic or too deep and major concerns are addressed.

Making sure @Quiddity sees the previous comments :)

I'd prefer if we use an etherpad for this because that lets participants and remotees participate ahead of the meeting

Each session has some standard structure in the task description, which is intended to encourage exactly this kind of pre-event participation. However, we're encouraging people to discuss the topics in phabricator ahead of time (instead of etherpad), I think primarily because that generates email/notifications, which thus reminds everyone to see the latest update(s). Ideally, the topic leaders will collate and summarize the feedback received within the phab comments, before (or at the start of) their sessions. I did add etherpad links to all the sessions yesterday, but primarily so that they'd be ready for live notetaking on the day. The one you already commented on has been merged with the default placeholder bits. https://etherpad.wikimedia.org/p/wm-dev-summit-2018-supporting-3rd-party but it might be good to raise those thoughts in the phab comments, too. :-)

In T185012#3911065, @Quiddity wrote:

I'd prefer if we use an etherpad for this because that lets participants and remotees participate ahead of the meeting

Each session has some standard structure in the task description, which is intended to encourage exactly this kind of pre-event participation. However, we're encouraging people to discuss the topics in phabricator ahead of time (instead of etherpad), I think primarily because that generates email/notifications, which thus reminds everyone to see the latest update(s). Ideally, the topic leaders will collate and summarize the feedback received within the phab comments, before (or at the start of) their sessions. I did add etherpad links to all the sessions yesterday, but primarily so that they'd be ready for live notetaking on the day. The one you already commented on has been merged with the default placeholder bits. https://etherpad.wikimedia.org/p/wm-dev-summit-2018-supporting-3rd-party but it might be good to raise those thoughts in the phab comments, too. :-)

I don't know if it's just me but adding thoughts in an etherpad seems much more convenient than Phabricator. When you're commenting in Phabricator, it invokes other people to respond to your comment. This turns it into a discussion and does not allow sufficient space for everyone to just put down their thoughts as they like. If this is the intention, then it's fine.
Also the fact that Phabricator comments trigger notifications for a fair number of people add to my hesitation. There is also less scope of editing stuff once you've put it down and people have started quoting you and responding to your comment. My 2 cents. :)

Good points! Thanks for that. Yeah, everything has pros/cons, and all people have personal subjective weighting of each of those pros/cons. I guess leaving it up to the topic leaders for each, is the most pragmatic. :/

Updated ver of feedback I sent internally yesterday, to make sure we don't lose it. Nothing too private I think. :)

• format is a bit confusing going in, but with the moderation/facilitation seems to work well
  • keeping the rooms/attendence smaller feels really good in terms of helping to facilitate actual conversation, but people who didn't get to come felt left out -- it's been a morale issue for some. I think the best way to handle this is to really concentrate on the idea that we're sending delegates/representatives -- not a full meeting of everyone involved in MediaWiki, but a representative group who can bring up the concerns of their colleagues.
• thought the 3rd party session went very well in terms of structure & conversation
• thought the arch session went less well, but still surfaced great discussion and helped to identify some "yes"es and some "mmmmmaybe later"s
  • next time we need to organize better ahead of time, with the format clear.
  • the arch session was *way overflowed* with things to talk about, and we had to rush through. needed a lot more time, or to break it up over two separate sessions.
• i like that we're getting people in the room to propose things and discuss more concrete proposals than we had sometimes at past summits.
• need to consider how to resource tech debt issues like 'update special pages to be api-friendly' and 'clean up old non-DI code' that don't have a team ready to work on them. And then those that have teams like 'unify the parsers' and 'actually write an api-based frontend' still will need to work with other folks on integration issues, support for extensions and user-created customizations etc.
  • discussion is good and is necessary to socialize ideas, get agreement, and surface further details to work out... But we must move on to decision-making at some point (techcom?) and resourcing (managers!). On the TechCom & WMF management end we need to make sure we have a good process for confirming that things are resourced so we can break the cycle of discuss->no resources->discuss again we identified in past years.

In T185012#3920684, @brion wrote:

• keeping the rooms/attendence smaller feels really good in terms of helping to facilitate actual conversation, but people who didn't get to come felt left out -- it's been a morale issue for some. I think the best way to handle this is to really concentrate on the idea that we're sending delegates/representatives -- not a full meeting of everyone involved in MediaWiki, but a representative group who can bring up the concerns of their colleagues.

This might a few changes to make (limited participation) work in a way that doesn't feel exclusionary and morale-deflating:

• if accepted position papers are a condition of participation, you need some "exception mechanism" in scenarios where some important perspective is missing
• if we are going to have position papers, position papers cannot be solely individual and if participation is limited, the collaborators figure out who gets to participate in the summit
• need avenues for those not present to observe / contribute / participate in some way -- via some combination of (a) pre-summit discussions (b) live-streaming (c) recording ... or other such

Since some sessions are much longer than others (and afternoon sessions are more likely to get impinged upon), we should try to match longer topics to longer sessions.

Found the keynote speech on Tuesday morning not really connected to Wikimedia. More emphasis on health domain and perhaps the speaker's current employer was not positive.

Explaining the nature of audience and highlevel things that we love to hear from the speaker might help.

In T185012#3920877, @santhosh wrote:

Found the keynote speech on Tuesday morning not really connected to Wikimedia. More emphasis on health domain and perhaps the speaker's current employer was not positive.

Explaining the nature of audience and highlevel things that we love to hear from the speaker might help.

I found all the keynotes except for the first on monday (Boring software) to be really boring and irrelavent.

The keynote session on Monday afternoon was between an ongoing session. IMO it affected the continuity of session. The cross project collaboration session was planned as 45 minutes but had to cut to 30 minutes because of this.

Have a coat check would have been cool.

Feedback from a participant: it's unclear what the next steps are -- some sessions haven't identified clear action items or didn't clearly assign owners to them. Worried about the idea that we're bringing up the same issues year after year.

From me: we need to actually knock out a few of these major issues brought up through our process this year so we can prove next year that we delivered! I think the TechCom<->WMF-manager interface is going to be key in this; the outputs from DevSummit need to be the inputs to TechCom's decision-making (via the owners making RFC-ready proposals) and the TechCom<->dev-owner<->manager interface is going to be critical in making sure that things get resourced and finished. This needs to be something we make very clear and explicit in our process.

Feedback from me: I actually liked the several keynotes from other perspectives. But some ran overtime and affected ability to get things done in sessions; we need to adequately timebox.

In T185012#3920983, @brion wrote:

Feedback from a participant: it's unclear what the next steps are -- some sessions haven't identified clear action items or didn't clearly assign owners to them. Worried about the idea that we're bringing up the same issues year after year.

+1

Noticed the vegetarian option for lunch Tuesday was 'available on request' instead of being put out with the meaty food. This may be an issue for people.

In T185012#3921003, @brion wrote:

Noticed the vegetarian option for lunch Tuesday was 'available on request' instead of being put out with the meaty food. This may be an issue for people.

I also thought it was seriously inadequate. Some more options would have been great.

Noticed the vegetarian option for lunch Tuesday was 'available on request' instead of being put out with the meaty food. This may be an issue for people.

That's unfortunate... I didn't realize. I just enjoyed a large amount of cous-cous instead.

In T185012#3921003, @brion wrote:

Noticed the vegetarian option for lunch Tuesday was 'available on request' instead of being put out with the meaty food. This may be an issue for people.

I would like to note that during the time that i was passing by the food, a waiter was continuously pointing to/offering people the vegetarian option. But it is quite likely that this sort of stalled at some point after i passed the queue. Signs in view are better :)

In T185012#3921149, @TheDJ wrote:

In T185012#3921003, @brion wrote:

Noticed the vegetarian option for lunch Tuesday was 'available on request' instead of being put out with the meaty food. This may be an issue for people.

I would like to note that during the time that i was passing by the food, a waiter was continuously pointing to/offering people the vegetarian option. But it is quite likely that this sort of stalled at some point after i passed the queue. Signs in view are better :)

I've both seen signs (two) and have been questioned as well by the same waiter (downstairs).

There was a conflicting Wikimedia event for product managers Tuesday. A PM mentioned they would have liked to attend a session, but could not because of this.

I'd like to see next steps from the session leaders include some means of publicizing the sessions and result of the sessions to all the folks who couldn't be present, including a means to collect feedback from nonparticipants who may support/object/amend conclusions of the session.

Next year I'd like to see the sessions recorded and streamed.

In T185012#3920881, @santhosh wrote:

The keynote session on Monday afternoon was between an ongoing session. IMO it affected the continuity of session. The cross project collaboration session was planned as 45 minutes but had to cut to 30 minutes because of this.

+1, the keynote should have been before or after the sessions.

In T185012#3920684, @brion wrote:

• keeping the rooms/attendence smaller feels really good in terms of helping to facilitate actual conversation, but people who didn't get to come felt left out -- it's been a morale issue for some. I think the best way to handle this is to really concentrate on the idea that we're sending delegates/representatives -- not a full meeting of everyone involved in MediaWiki, but a representative group who can bring up the concerns of their colleagues.

I've been calling it the "not-really-developer summit", since developers in general weren't welcome unless they had some strategic vision and were able to express it in a position paper. If this format is used again next year, I'd recommend renaming it to "strategy summit" or something more accurate.

The posters at the event called it a "development summit". FWIW. ;)

I was a little disappointed that the position papers weren't used more. I understand that the session leaders used the position papers to group sessions and seed the session with topics, but there was a still a lot of oral discussion that just restated points folks have previously made in their position papers.

As a strawdog: each session could have been a panel composed of N participants, grouped by position paper, and it could have started with the panel participants restating their position paper (or have these put before the attendees in some other form). Then the participants could have debated their positions directly with each other and the audience, which would have helped identify strengths/flaws and find consensus between positions. The result of the session would be a coherent position, instead of a disconnected collection of action items.

Are we trying to get folks with a broad range of perspectives in a room together? Are we trying to do high level planning for the WMF, which means certain folks need to be there to weigh in on resources need to be there because they'll be crucial to the effort? In either case, position statements were not a great gatekeeper mechanism.

The reason folks started advertising the existence of the vegetarian lunch on day 2 is because I was snooping around the entrees looking sad. Better late than never I guess.

The architecture session, I thought, was the most productive of the sessions I was in, but that was mostly due to ignoring the session guidelines from the organizers and deciding that we couldn't get anything concrete out of a long term strategic vision.

I understand the reluctance to stream the group discussions. The keynotes could at least have been streamed and/or recorded for later viewing by the community.

I would have liked to see the keynotes be related to specific topics for discussion, OR have the sessions be a lot more focussed.

In T185012#3921663, @Anomie wrote:

I've been calling it the "not-really-developer summit", since developers in general weren't welcome unless they had some strategic vision and were able to express it in a position paper. If this format is used again next year, I'd recommend renaming it to "strategy summit" or something more accurate.

I'd like to point out that the position statement wasn't really supposed to be a "strategic vision". From my reading, position statements were about specific technical/non-technical problem areas which participants felt strongly about.

Would like to request small honorarium budget for keynotes for next year, both to ensure that we can ask keynotes to create fresh, relevant material — and we can go over it in advance – and to widen the geographic pool of candidates.

We told keynotes specifically not to change their set talk because they were volunteering their time this year. I would very much like to ensure that we can iterate on this approach, and have read all of the feedback related to keynotes above.

I've been to conferences where leads have been trained in advance (or the night before) by a professional facilitation team – and that was really great for me (as someone who was learning how to facilitate.)

In T185012#3931913, @MelodyKramer wrote:

I've been to conferences where leads have been trained in advance (or the night before) by a professional facilitation team – and that was really great for me (as someone who was learning how to facilitate.)

The team practices group had given training for all facilitators of the Dev summit. In case anybody interested, here is the training document

(I only skimmed the above feedback)

• Breakfast food on both days was great.
• First day's dinner didn't really have sufficient vegetarian food, myself and a few others ended up getting dinner somewhere else.
  • Also according to the drink menu there were only two non-alcoholic drinks...and by the time I got up there they had run out of root beer. Some more options for those of us who don't drink alcohol would be nice (I didn't ask/check to see if they had normal soda)
• Second day lunch had vegetarian food kept separately, which wasn't really an issue for me, but I know at least one omnivore that also wanted their share of vegetables, but didn't take any since they wanted to ensure there was enough food for vegetarians.
• Attendee selection needs to be improved/re-thought. Flying people to SF (for WMF all hands) but then saying they can't attend an event 30 minutes away, where all of their peers are is not great. I have some more thoughts on this that I need to write up in a longer form.
• If the event is going to be in Berkeley (I understand this lowered costs a lot), is it also possible to have a hotel in Berkeley too, so we aren't taking BART there and back? At least at the end of the day spending an hour on the train back is exhausting.
• Evolving the MediaWiki architecture session had way too much crammed into one session slot.
• There were too many keynotes on the first day - I got the most out of the speaker from Etsy and Toby. Also splitting one of the sessions with a keynote should be avoided in the future if possible please :)
• I really appreciated Victoria being in the sessions and participating.
• I'm glad that Katherine/Toby/Victoria had the "fireside chat", but I think we needed more time allocated for Q&A.

• The fig bars were incredible, I need to know what brand/bakery they came from
• If we want product input, I suggest they work on organizing the position papers into sessions and inject questions and concerns that they want each session to address.
• If we don't want product input, we should work together on organizing the sessions instead of putting that burden on a small committee that might not have the necessary context.
• Sessions like Evolving the Mediawiki Architecture were too short and interrupted while sessions like the Contributor Experience were unnecessarily long.
• Having two separate sessions in each time slot seemed forced at times. For the big sessions like Architecture and Open Source, we can just have one at a time.
• The position papers and limited participation was brilliant, it was the first summit that gave me hope. With another iteration and working out the kinks above I think it can become one of our most productive gatherings.

Thanks to all that have given feedback on this ticket - it's greatly appreciated!

If you haven't already, please check out the survey that was sent out by @Rfarrand:

Survey deadline: 20 February, 2018

*FEEDBACK SURVEY LINK:* https://goo.gl/forms/XvFRXSRVEaSxjhe52

Many of the questions are fill-in-the-blank so you can choose to answer all of them or only the ones related to areas where you would like to give feedback.

You do not need to have attended the Wikimedia Developer Summit 2018 to fill out the feedback survey, we welcome input from anyone.

A summary of the survey results will eventually be posted here:
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2018/Lessons_Learned

Thank you very much in advance for taking the time to help us improve!

Four months later: Who is supposed to be the owner of this task and follow up on the comments in this task?

Thanks @Aklapper ! I will close this once I am sure that last years lessons are incorporated into this year's organization.