Talk:Wikimedia Developer Summit/2017/Program committee

Hi, when the Schedule review ends this Friday... is the work of the Program committee completed? Or do you still see us having a role in the Summit 2017 as a committee?

Well, I expect to have a role running sessions on my assigned topic. I hope there will be a role for the program committee summing up the results of their sessions at the end of the summit as well.

And you'll probably need some help organizing the unconference.

And I hope we'll do a post mortem after the summit, and write down some suggestions for next year's committee.

According to the timeline, we have to publish a draft schedule by Monday, December 12.

Let’s start with these assumptions:

• Two rooms for pre-scheduled sessions.
  • The biggest room in theater configuration (up to 200 people, only chairs, no tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
  • A big room in classroom configuration (up to 70-80 people, chairs and tables) and required video recording (meaning also that people have to wait for the mic to speak etc).
• 80 minute slots + 10 for changing sessions.

The draft is being produced in a private document accessed by the Program committee members plus Rachel and Srishti as organizers.

I have asked about the preferences for room size and video requirements to the candidates to be pre-schedule in the main topic "How to grow our technical community", and also in those sessions without a main topic (example). Their answers should help figuring out which sessioons should be pre-scheduled where, and which ones actually prefer an Unconference setup.

I have asked the facilitators of each main topic to decide the one session that should be pre-scheduled. This assures at least one session for each main topic. Once this is done (hopefully by Monday 5, latest) then we will discuss the rest, where some main topics are expected to have more pre-scheduled sessions than other.

@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.

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.

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.

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. ;)

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

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.

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.

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).

Sprint completed.

The next deadline:

• 2016-11-28: Deadline for consolidating a discussion, regularly summarized in the proposal.

What is expected for each main area (this is my own opinion, feel free to disagree):

• Go through the proposals missing active discussion and try to push the conversation in those that you think should be pre-scheduled

To be clear, tasks missing an interesting discussion will have a very hard time getting one of the ~18 slots for pre-scheduled sessions. Currently we have 49 proposals, and 3 of them (Community Wishlist) have their slot assured. This means that today we have 46 sessions competing for 15 slots:

• A plan for the Community Wishlist 2016 top results: 3 proposals (to be scheduled)
• Handling wiki content beyond plaintext: 12
• Building a sustainable user experience together: 5
• Building on Wikimedia services: APIs and Developer Resources: 4
• How to manage our technical debt: 4
• Artificial Intelligence to build and navigate content: 7
• How to grow our technical community: 9
• None (all of them related to editorial collaboration): 5

We will send a communication to all the registered participants and the main mailing lists encouraging everybody to participate in their preferred proposals, and also to award Phabricator tokens to the sessions they are interested about. All this regardless of whether they will attend the Summit or not (since we want to improve remote participation). Tokens will be considered a complement to register "proven interest"about a session.

After a conversation with @Sherah (WMF), we have agreed to close "Building a sustainable user experience together" due to a lack of critical mass and push in the topic as a whole. Specific session proposals still might be pre-scheduled, based on their own merit.

I have started moving proposals to either "On track" (when they had a clear track of support and discussion) or "Unconference". At the end of today, the "Missing proven interest" column should be empty. If there are any proposals left by tomorrow, I will deal with them (the worst thing that might happen is that someone disagrees and then we discuss and eventually change something).

I didn't really touched any of the "beyond plaintext" proposals, since there is @Cscott and other Program committee members involved. I didn't decide on a few other proposals belonging to other main topics because I wasn't sure whether they should be evaluated as having enough interest or not. For instance, there are several proposals with a relative high number of subscribers and tokens, but no discussion at all. Please help triaging those. As Program committee members, you can also weigh in at the proposal itself by adding a comment with your own opinions.

In other words, there are still 21 proposals to triage, and if all Program committee members help, this will be an easy task. If not, the risk of me making mistakes will be a lot higher.  :)

Yesterday's Program committee meeting logs and summary are available at phab:E356.

Alright, this is the next deadline:

2016-11-14: Deadline for defining a good problem statement, expectations, and links to relevant resources.

What is expected for each main area (this is my own opinion, feel free to disagree):

• Main topic wiki page should be ready by now.
• Each main topic should have a corresponding "Facilitating.." task in Phabricator.

Facilitators should go through all the sessions proposed and

• Set all the tasks related to your main topic as subtasks of the Facilitate... task.
• If there is a proposal related to your area that has any problem (from needing a better description to being a bad idea altogether), now it is the time to discuss whether such proposals should be improved or declined.
• The proposals that you want to promote should be listed in the main topic wiki page.

There might be proposals that are not related to any main topic but still might make sense to pre-schedule. If that is the case, we will decide collectively what to do with them.

It is also time for a first real-time meeting of the Program committee. Today I'm observing a local holiday. Tomorrow I will propose a date.

The main goal between now and the end of next Monday is to clean the Backlog and Missing basic information columns at https://phabricator.wikimedia.org/project/view/2205/

Good quality proposals will be moved to Missing active discussion (the next milestone / deadline) or On track. The rest will either go to Unconference (if the promoters are responsive) or will be declined (if they seem abandoned).

The "Missing basic information" column is empty now.

Above there are some requests for main topic facilitators. In short, wiki content, AI, tech debt, and community have done their homework. 

UX, API, and Wishlist not quite. Please let me know if you are planning to follow the steps proposed in that topic, or whether you have other plans.

Done.

The Program committee also advises on travel sponsorship cases upon request from the event organizers, as per phab:T132111.

Done.

Right now all the focus goes to assuring that proposals for activities are submitted before the deadline by the end of next Monday. Please make sure that whoever you want to see submitting a proposal in your areas does it!

A task in Phabricator with two lines i.e. " We should discuss about ContentHandler, should we?"  is enough to pass this deadline. We have more deadlines to polish these proposals and proof interest, but they are weeks away.

After Monday's deadline, we should... meet?  (OMG!) and discuss next steps, how to go from there to a schedule + unconference in the terms we want.

Hey folks. I was talking to Guillaume on IRC and he was wondering about being able to attend just one topic area at the dev summit without having to find something to do during long periods of discussion that are irrelevant to him. It seems like having themed tracks or maybe different focuses on different days would allow us to accommodate attendees like Guillaume. What do you think? Does that already jibe/clash with some plans that have already been put in place?

There are no plans already put in place, and we can organize the schedule in the way that makes more sense. Grouping by tracks would make sense, and we did a bit of that last year already. Doing it in a more clear way is something we should consider.

However, in order to make this fit with i.e. Guillaume's case, we would need to commit already now to topics/days (while the registration is open, asking participants which days they plan to attend). That sounds more complicated to do now, when the call for participation is still open and some main topics still don't have any proposal.

Why would we need to commit to days/topics now? It seems that Guillaume could adjust his schedule to which ever day/time we pick.

OK, then maybe I was seeing it as more complicated than it actually is. Good.  :)

If space allows, maybe we could have permanent rooms by big topics, where people can hang out and work during "irrelevant" sessions? That way we wouldn't need full-time tracks. For example, we could have a "Research" room where people interested in research could work together when they're not attending another presentation. Maybe that same room could be used for planned or impromptu workshops.

I have no idea of what the logistics are, so let me know i this doesn't make sense.

The idea makes sense in theory. We will check it against our availability of spaces. Thank you!

Edited: in fact, the room would be needed only when there are no pre-scheduled sessions about the topic, which gives a higher percentage of possibilities for this to work out.

I'd be more in favor of "daily themes" than "focused tracks". My experience last year was that it was hard to have multiple tracks that didn't require me to be in two places at the same time. Now, this might just be due to the fact that (a) I submitted a bunch of proposals, and (b) I try to be a generalist on the projects -- but I know there are quite a bunch of other folks at WMF which are similarly multidisciplinary -- and in fact, encouraging mixing between "focus areas" (IMO) ought to be one of the aims of the summit. Like required humanities courses at an engineering school -- it's good for you, and we might all be surprised to find that the subject wasn't quite as irrelevant as you originally thought. Hopefully we'll get interesting cross-pollination, and if we don't we at least get more holistic views of the organization.

Rather than subject-area tracks, maybe we can split between "discussion groups" and "working groups". We might all fruitfully offer or hear some opinions of (picking a random example) the future of Flow ("discussion group"), but when it comes time to nail down the precise DB schema needed for roadmap item 4 ("working group"), it might be best for a small group of specialists to meet off to the side.

Of course, it may be that a few of those specialists happen to be in high demand, so we perhaps have stumbled onto the tracking problem again from the other side. Perhaps "working groups" could be scheduled alongside general hackathon time (for everybody else), rather than risk conflicting with another session.

If we concentrate this month on the selection of good topics to be pre-scheduled (based on the interest of the topic and other factors), then we will see which pieces we have to combine. Speaking about a structure before knowing the sessions is difficult.