Yesterday I went systematically through all the proposals missing a good description, ongoing discussion, or both. Currently we have 18 proposals missing expected fields and 11 missing active discussion. 24 proposals are on track.

I also sent a reminder to wikitech-l, encouraging people to help pushing the proposals they are interested about.

By 6 Nov 2015 all Summit proposals must have active discussions and a Summit plan documented in the description. After this deadline, we can start organizing the schedule.

@RobLa-WMF, I was trying to check the Architecture Committee evaluation of proposals against the "Missing expected fields" and "Missing active discussion" proposals, and it is not clear to me what should I do. They seem t be happy keeping many of those sessions regardless of the fact that today have no clear description and/or no discussion. I welcome your help deciding which one should be removed from the game.

On the other hand, their evaluations are already useful to highlight the ones that are more relevant. I was thinking of creating a "Prioritized" column and start moving there the best ranked sessions, as a previous step to having a grid and start pre-scheduling these sessions. What do you think?

Hi @Qgil, could you provide a specific example of confusing session without a clear description and/or discussion? Feel free to contact me privately if you aren't comfortable saying it here.

A couple of clear examples of proposals that applying strictly our process and deadlines could be detached from the Summit:

• T114803: Service-Oriented Architecture, quo vadis?
• T96903: Identify and prioritize architectural challenges

My hesitation comes from these facts:

• The ArchCom spreadsheet contains ok/positive evaluations for most of the sessions under "Missing expected fields" and "Missing active discussion".
• In fact, some of those sessions are being proposed by ArchCom members.
• However, that spreadsheet has many blank cells, so I don't know how representative are the current scores.
• On top of this, I made several people unhappy in the past by being too strict applying our process...

So in practice I'm quite blocked, waiting for your specific feedback on which proposals we should remove from the Summit queue (if any), and which ones should start being promoted in the schedule.

@Rfarrand, could you share a list of rooms available and capacity of each, in order to start building a program skeleton, please?

@Qgil: thank you for pointing this out; I agree we need to start narrowing things down to specifics, given our time constraints. Do you think we can orchestrate a collaborative process for building the schedule using some unconference techniques? For example, can we use mediawiki.org and/or Phabricator as our post-it wall for building the schedule?

Rob and I met yesterday and we agreed that Quim will create a skeleton schedule on-wiki, we will invite people to propose their own slots in the schedule by placing their sessions directly. Then Rob, the owners of each area, the ArchCom, and myself will massage the schedule until it is finalized.

Thursday, December 17 looks like a decent deadline to complete this process.

Before building the skeleton of the schedule, I took a look at https://www.mediawiki.org/wiki/MediaWiki_Developer_Summit_2015/Lessons_learned#Schedule

45 minute sessions were too short, and people thought that there were too many conflicting simultaneous sessions. To solve this problem, I'm proposing this skeleton:

https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/2016-01-04
https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016/2016-01-05

• Only the three main rooms are open to pre-scheduled sessions. The rest is to be scheduled in literal unconference style, on the same day.
• Pre-scheduled sessions run up to 80 minutes (plus 10 minute break between sessions, resulting in 90 minute slots).
• There will be 7 pre-scheduled sessions in the main room, in addition to two keynotes and the wrap-up session. The selection of these sessions should be highly moderated, assuring representation from the different areas, promoting the proposals that demonstrated more interest and activity, and obtaining the approval from the ArchCom as relevant discussions to have.
• There will be 14 slots for big rooms. We can invite people to propose their sessions for these slots, and deal with the risk of good sessions being left out while weaker sessions got in. Soft moderation from the owners of each areas, Rob, and Quim is expected.
• With 3 pre-scheduled sessions at each time, avoiding direct conflicts will be an easier task.
• All the rest will go to the unconference rooms and to Wednesday's activities, which will be all scheduled on the same day.
• The default time slot for unconfere rooms should probably be 45 minutes, with a chance to extend to 90 minutes or more based on availability.

@RobLa-WMF, what do you think?

@Qgil, cool, I think this can work! I put in some proposed boilerplate that I think we should put in every unreserved spot so as to encourage people to put their nominations in, and to make it clear that putting something on the calendar makes it a nomination, not a claim.

Perhaps we should also come up with a technique for categorizing things into the following:

• Must do (+2) - these are the items that there is clear consensus we need to fit into the calendar (Edit: see T119593: Define the list of "must have" sessions for WikiDev '16)
• Should do (+1) - we'll survive if items here don't make it onto the list, but we should really make an honest effort to schedule them
• I suppose / silence is assent (0) - yeah, it'd be nice to get to these too, but eh...whatever
• Someday maybe (-1) - perhaps a worthwhile discussion to have, but probably not the best use of our time at Wikimedia-Developer-Summit-2016
• Um...no (-2) - this session proposal is poorly conceived, and further discussion about this seems like a bad use of our time

Perhaps a productive thing to do now in Phabricator is have a "build the 'must do' list for WikiDev 16", creating a list of Phab tasks in the description, and then inviting people to put their +2s in the comment section. The task assignee (@Qgil? @RobLa-WMF? TechCom?) can be responsible for building the list in the description of the task. Thoughts?

Cool. If we are inviting people to what is basically a survey, maybe we can just run a survey with survey software? Qualtrics or Google Forms, whatever is simpler. I volunteer.

Should the survey be open to anybody or to people currently registered to the Summit?

I'm not proposing a survey; I'm proposing a discussion. Using a survey
tool suggests we're asking for a vote.

To be clear, I'm also not suggesting the +2/-2 range should imply that we tally up the score and arrive at a total. I'm making an admittedly confusing comparison to how we think about code review. In the code review context, "+2" is not a vote, it's a statement that a trusted reviewer makes ("yes, this code should be part of our codebase") In the meeting context, we can't afford to give anyone the same type of "+2" rights that trusted code reviewers get. That said, if someone is willing to stake their reputation on giving a meeting idea a "+2", we should listen to what they have to say.

I went ahead and created T119593: Define the list of "must have" sessions for WikiDev '16, which I plan to discuss at the ArchCom meeting tomorrow.

@RobLa-WMF, ok understood. Yes, I was initially confused by the scale of numbers from +2 to -2 that you gave. Now I understand what you mean. Let's continue working on the pre-scheduling of must-have sessions at T119593: Define the list of "must have" sessions for WikiDev '16.

I'm going to repeat what I wrote in T119018: Working groups/areas for macro-organization of RfCs for the summit. I think the owners of each of the subtasks there are doing a good job of figuring out what the "must haves" for each working area.

Here are the subtasks (a.k.a. "working areas") that are being discussed:

• Content format (T119022) - This is about the format of our data, with a primary emphasis on the future of Wikitext & markup (or possibly, the future of eliminating it). The central problem in this area: "how do we make manipulating our data easier and more useful" (both for humans and computers)
• Content access and APIs (T119029) - this is about getting our data in-and-out of the system (e.g. rest.wikimedia.org). The central problem in this area: "how do we make accessing and distributing our data easier and more useful?"
• Collaboration (T119030) - this is about how we work together. Central problem: "how do we scale editing our code up to populations similar to editing our projects, proportionally increasing our positive impact and productivity?"
• Software engineering (T119032) - this is about building and delivering high quality code. Central problem: "how do we build high-quality software that we can dramatically increase the number of people that can understand it while increasing the reliability and maintainability of Wikimedia sites?"
• User interface presentation (T119162) - improving our user interactions. Central problem: "how to we make our software look and feel joyful to use?"

I'm not sure exactly how we will allocate time between the different working areas. It will almost certainly not be an equal split; but let's use T119018 as a place to discuss if that's even the right list of questions to consider.

Given the quality of discussions happening in the working areas, I think we should give a lot of consideration to the top recommendations in each of the areas. For example, @daniel has done an excellent job of organizing the tasks in T119032: WikiDev 16 working area: Software engineering. I believe the proposals are what we should consider +2s from that area (once the dust settles on the T119032 conversation). Do we want to require that the organizers of the T119018 subtasks also put their +2s as a comment in this task, or should Quim and I set a deadline to stop editing those subtasks, and then use some evaluation time to infer +2s off of each of the T119018 subtasks?

Quim and I met earlier, and we agreed to a main room schedule for WikiDev '16:

• Monday, 2016-01-04
• Tuesday, 2016-01-05

Here's where things stand:

1. Each of the working groups/areas defined in T119018: Working groups/areas for macro-organization of RfCs for the summit should have a session in the main room (Robertson 1, which seats 200). Discussion of how we should use the focused time in each area should happen in the working area Phab tasks.
2. Two main room sessions are scheduled:
   • T114542 - Next Generation Content Loading and Routing (Adam Baso and Gabriel Wicke)
   • T113210 - How should Wikimedia software support non-Wikimedia deployments of its software? (Gilles Dubuc)

We still have many open slots in the schedule to fill, but we now have a little better idea of what those things will be competing against. Barring a radical change the discussion or in our planning process this week, what Quim and I plan to do is start filling in the slots in the competing rooms (Robertson 2 and Robertson 3) from the must have list (T119593). We'll also be prodding the working areas to decide on their plan for their allotted Robertson 1 time at WikiDev.

If you are interested in this topic and have the time for it, please join us at E121: WikiDev '16 Agenda Bashing Session (2015-12-16, 22:00 UTC on #wikimedia-office) where we plan to discuss this more.