Jump to content

Topic on Talk:Wikimedia Developer Summit/2017/Program committee

About merging multiple proposals in one session

8
Qgil-WMF (talkcontribs)

@Cscott has mentioned in different places an intention to merge multiple proposals in a single session. Given that each proposal is supposed to have an ongoing discussion, I wonder how that would work in a 80 minute slot at the event.

Please, let's discuss this. In principle I'd rather select single topics that are more relevant / raise more interest and make sure that there is time to discuss them in pre-scheduled sessions, moving all the rest to the self-moderating dynamics of the Unconference. However, I reckon that there are other possible models that may work too.

Cscott (talkcontribs)

I think it's worth discussing in general what sorts of sessions we want this year. And maybe not all topics (or all sessions) have to be structured the same way.

Last year we have main sessions which surveyed a large range of possible discussion topics under a focus area, and then breakout sessions which tended to focus on a smaller number (1-3) of these. See the software engineering breakout session in last year's Monday schedule for example.

This year I seem to have a number of proposals which naturally group together, and so I thought that something vaguely similar would work ā€” more like the breakout sessions from last year, instead of the incredibly-broad discussion sessions. For example, phab:T147604, phab:T90914, phab:T149554, and phab:T149547 all have something to do with audio/visual integration in articles. So it might be worth having a session on "audio/visual integration in articles", allocating 10 minutes to each proposer to present what they envision on the topic, then spend the rest of the 40 minutes discussing and synthesizing commonalities.

There are also two or three "wikitext 2.0" proposals. Again, it might make sense to have the proposers spend some time at the beginning of the session describing their proposals, then conclude with some discussion time.

I'd admit that this proposed structure has something to do with the fact that I made quite a lot of proposals myself. If I allocated full sessions to each topic, I'd either have to bow out completely or a lot of the sessions would seem rather self-serving. By splitting the sessions up among competing or orthogonal proposals, it seems like I can give not-me an adequate share of the time while also slipping in 10 minutes for my proposal on the topic as well. I've requested a TPG facilitator for the sessions as well to ensure all voices are heard.

Perhaps other topics have a smaller number of submissions, and so this approach doesn't make universal sense. But I think it will work for the wikitext track. I'm open to other ideas as well.

Qgil-WMF (talkcontribs)

OK, this makes sense. What about creating a task with the title of the "umbrella session" and then defining the different related proposals as subtasks? Now it is very difficult to get an idea of what are the sessions related.

I think we still would need to have some check for proven interest of these proposals and/or the umbrella, in order to make the right choices assigning slots.

Cscott (talkcontribs)

Sure. I was going to merge these after the votes for the individual proposals come in, just in case my intuition about what can be combined is off. For example, if there's tons of interest in proposal X, maybe it needs its own slot and shouldn't be combined. I can do the arithmetic to sum interest if necessary. ;)

Qgil-WMF (talkcontribs)

OK, the time for "proposal engineering" ;) is today.

Qgil-WMF (talkcontribs)

I have been thinking further about this idea of merging multiple proposals in a single pre-scheduled slot and, well, I don't see how this would work with the kind of Summit sessions we are after.

We are saying that the Summit is all about discussions. We are saying that pre-scheduled sessions are meant to be preceded by online discussions. Picking 3-4 ongoing discussions and squeezing them in a 90 minute slot only to redistribute them in "breakout sessions" (in practice, Unconference sessions) doesn't make much sense? We burn out one slot for one good discussion, and anyway the 3-4 good discussions will happen in Unconference slots.

For that matter, I think it is better to make the tough call beforehand, pick the most active ongoing discussions, support them offering them the pre-scheduled slots, and then move all the rest directly to Unconference sessions.

Cscott (talkcontribs)

My proposed sessions are https://phabricator.wikimedia.org/T147602#2832989 -- there are basically three merged sessions I'm proposing, one for 'wikitext 2.0', one for audio/video/media/layout support, and another for 'annotations'. Of these, the first two seem pretty solid. The merged session on annotations is more tenuously connected.

I understand the desire to basically get the summit done ahead of time in phabricator comments, but I'm not sure that's ever really worked. You can look at the comment/token/subscriber counts at https://phabricator.wikimedia.org/T147602#2832908 -- there's lots of interest quantified as subscribers and tokens added, but active discussion is not strongly correlated with interest.

Qgil-WMF (talkcontribs)

It's not about getting the Summit done ahead of time. It's about connecting ongoing discussions with the Summit (we have many) and it's also about reducing the risk of spending session time with introductions that could have been done beforehand (a real risk duly noted in previous events).

Reply to "About merging multiple proposals in one session"