Talk:Wikimedia Developer Summit/2017/Program

Done

Call for participation is about to open and the first proposals for activities will be submitted soon. We need to define and document our selection process. I think last year's process was good enough, and I would only try to apply improvements to it.

@RobLa-WMF has already mentioned that the requirement for an RfC should be more flexible, and I agree with this. Sometimes an RfC will be the right context for a proposal, sometimes not.

I suspect there is going to be more competition to get one of the pre-scheduled slots in the agenda, which probably will have an implication on the size of the room as well (we have a new venue and I still don't know the details and flexibility about room sizes). For this reason, I propose to be more strict on the requirements for prior discussion and good preparation of the proposal before the event. Something like this:

• Proposals for pre-scheduled sessions with a good problem statement, defined expectations and links to relevant resources move forward, the rest don't.
• Proposals for pre-scheduled sessions with active discussion properly summarized move forward, the rest don't.
• If these filters are not enough, we have the possibility to send a request to all the Summit participants to RSVP in the sessions they would like to attend, in order to get an idea of potentially required room sizes.

Thanks Quim, this looks like a process that can work. If we do things the way I'm hoping, one thing we'll need to set expectations for is that this won't be acceptable:

1. Get your topic accepted in September/October
2. Do a lot of private conversations/rehearsals/etc (while being radio-silent publicly)
3. Have a prepared agenda in January, with a big room and plenty of time to talk at people

What that means is that the vetting process will continue until January, and that our October topics should be treated more as a well-informed hunch than something that is set in stone. Public conversations should build continuously throughout October, November and December, and everyone who wants to make sure we talk about a topic in January would need to keep the topic alive until then. We should reserve the right to nuke topics that appear to have lost relevance in December, and make room for more relevant stuff then.

I fully agree. Even if the proposals that go through these quality filters are not enough to fill the schedule initially planned, I'd rather accommodate more time for these proposals than let in other that didn't do the homework like the rest.

I have reflected this at Wikimedia_Developer_Summit/2017/Call_for_participation#Selection_process now, and I think it is ready to go. We can still fine tune milestones and dates.

Fixed

The session named "Asynchronous processing in production: one queue to rule them all" is listed as starting at 2:30pm, but the parallel session starts at 3pm, the section heading it's under says "3:00pm", and room 2 won't even be available because the labsdbs session doesn't end until 2:55pm. Is this a typo, or is this session actually offset from the rest of the schedule in some way?

Thank you for spotting this problem. It's fixed now. A general fine tuning of times was on its way, and I just applied it.