I've added our Developer-Advocacy team project.
Feel free to drag&drop the task to the Oct-Dec subproject on the workboard (or to "Actions > Change Project Tags" to set Developer-Advocacy (Oct-Dec-2016) and potentially "Actions > Move on Workboard" to set one of the months that we have as columns).

I took a first look at this task today. It seems that overall the unconference worked out really well at the last year's dev summit. A few lessons learned were: Unconference description wasn't clear, scheduling was unfair, and people didn't have much time to schedule sessions. And things where we could've done better: encourage non-WMF members to propose topics and address note-taking better.

Based on this, I've added to the Unconference page here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Unconference. It's the very first draft. The idea is that when we have the final schedule posted, we reach out to participants and ask them to propose topics they want to either host or attend at the summit through our Unconference Wiki page. We use the proposed topics and interest received on them to allocate rooms for the unconference session on the first-come-first-serve basis. On the day of the event, we add the unconference sessions to our schedule. If there are still slots left, we invite people to propose sessions on the fly on a physical whiteboard or directly to the schedule table.

@Qgil @Rfarrand Are there any concerns with this approach, is this headed in the right direction? :)

Interesting. I am trying to conciliate what you have drafted with all what we have said so far in the context of the Call for participation.

scheduling was unfair

Why? I'm not questioning whether it was or not. It's just to understand the reasons.

Based on this, I've added to the Unconference page here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Unconference

That page requests the creation of new proposals, but we have over 30 Unconference proposals already now at Wikimedia-Developer-Summit (2017) , and more will be added from "On track" as soon as the scheduled sessions are announced next week. It seems redundant to ask participants to follow a new process at this point.

The page suggests that it will be possible to schedule Unconference sessions in advance, and that we (the organizers?) will do it on a first come first served basis. This seems to clash with all the work we are doing pre-scheduling the "big" sessions. Also, when proposals presented in advance are being pre-scheduled by an organizer, can we still call this an Unconference?

On registering interest, since we already have Phabricator tasks for sessions, it could be simply done with a "Participants" section added to the description of the task, letting people to add their names (and/or usernames) there.

To be clear, I am not opposing to any of these ideas at this point. I am only asking questions about aspects that seem unclear and I am trying to conciliate the Unconference with the rest of the program. Let's talk, and we will find a solution. :)

Also a detail, the page encourages people with questions to contact you. I think questions should be posted in the discussion page by default, the wiki way as usual. You can specify somewhere in the page that you are the main contact for the Unconference, and then people willing to contact you personally will know what to do.

In T147955#2853762, @Qgil wrote:

Interesting. I am trying to conciliate what you have drafted with all what we have said so far in the context of the Call for participation.

Ahha, may be I misunderstood a few things here :) Let's see as I clarify on a few below :)

scheduling was unfair

Why? I'm not questioning whether it was or not. It's just to understand the reasons.

From lessons learned wiki, it looks like that sessions could not be scheduled in advance, but still some people did and got to keep their spot.

Based on this, I've added to the Unconference page here: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Unconference

That page requests the creation of new proposals, but we have over 30 Unconference proposals already now at Wikimedia-Developer-Summit (2017) , and more will be added from "On track" as soon as the scheduled sessions are announced next week. It seems redundant to ask participants to follow a new process at this point.

I am aware of our unconference sessions and I think that the ones proposed so far are mostly by members of our WMF community. From what I sensed, that we are planning to reach out to the participants asking them to propose an unconference session before the event. Is that correct?
If so, considering that some of our attendees may not be comfortable using Phabricator, and some of them will propose topics quite close to the event or on the spot, it would be easier to do so on the fly on the wikis. But, I agree that it then becomes a duplicated process for those who have proposed already on Phabricator.

The page suggests that it will be possible to schedule Unconference sessions in advance, and that we (the organizers?) will do it on a first come first served basis. This seems to clash with all the work we are doing pre-scheduling the "big" sessions. Also, when proposals presented in advance are being pre-scheduled by an organizer, can we still call this an Unconference?

So, here I didn't mean that we would schedule the sessions in advance, rather allow people to propose topics and express interest in them in advance. And, then on the day of the event, if we have enough rooms, all unconference proposed sessions become active sessions, but if not then we allocate rooms to sessions based on interest received on them. To your question, in a typical unconference, agenda setup happens on the spot (including proposing for topics as well), and this is one such element that we will miss in our event. But, it makes sense because of obvious reasons.

On registering interest, since we already have Phabricator tasks for sessions, it could be simply done with a "Participants" section added to the description of the task, letting people to add their names (and/or usernames) there.

To be clear, I am not opposing to any of these ideas at this point. I am only asking questions about aspects that seem unclear and I am trying to conciliate the Unconference with the rest of the program. Let's talk, and we will find a solution. :)

Yes :) I think we could do something like that :)

Also a detail, the page encourages people with questions to contact you. I think questions should be posted in the discussion page by default, the wiki way as usual. You can specify somewhere in the page that you are the main contact for the Unconference, and then people willing to contact you personally will know what to do.

This is a good idea! I take it.

In T147955#2855240, @srishakatux wrote:

scheduling was unfair

Why? I'm not questioning whether it was or not. It's just to understand the reasons.

From lessons learned wiki, it looks like that sessions could not be scheduled in advance, but still some people did and got to keep their spot.

OK. The solution to this problem is not to provide any means to schedule anything Unconference online beforehand.

Instead, we could

1. Set official time, place, and requirement to schedule Unconference sessions for the same day. For instance, 9am in the board located at X; only sessions with a Phabricator task fitting minimum requirements will be accepted. Promoters of sessions can agree changes between themselves. Any problems to be directed to @srishakatux, who can ultimately resolve Unconference scheduling problems.
2. Document whatever we have decided in the Unconference wiki page.
3. Link to the Unconference page in all our communications to Summit participants. Send an email to all Summit participants a week before the event about the Unconference only.

That page requests the creation of new proposals, but we have over 30 Unconference proposals already now at Wikimedia-Developer-Summit (2017) , and more will be added from "On track" as soon as the scheduled sessions are announced next week. It seems redundant to ask participants to follow a new process at this point.

I am aware of our unconference sessions and I think that the ones proposed so far are mostly by members of our WMF community. From what I sensed, that we are planning to reach out to the participants asking them to propose an unconference session before the event. Is that correct?

Mmmnot really?

There is no "WMF community" vs "the participants". It's the same group, as of today the Summit registration consists of a 75% of WMF members, and that proportion is also reflected in the proposals. The call for participation was announced widely to everybody.

While people will be able to propose Unconference sessions on the spot, we are not encouraging the creation of new proposals at this point. Either you submitted your proposal by the deadline and have been gathering interest / discussing since then, or you will come up with new sessions during the event, mainly as a result of discussions or new ideas at the Summit.

If so, considering that some of our attendees may not be comfortable using Phabricator, and some of them will propose topics quite close to the event or on the spot, it would be easier to do so on the fly on the wikis. But, I agree that it then becomes a duplicated process for those who have proposed already on Phabricator.

Anyone aiming to run a session at the Wikimedia Developer Summit should be able to create a task in Phabricator? Maybe there is a possibility for an exception, but I see this very unlikely.

So, here I didn't mean that we would schedule the sessions in advance, rather allow people to propose topics and express interest in them in advance. And, then on the day of the event, if we have enough rooms, all unconference proposed sessions become active sessions, but if not then we allocate rooms to sessions based on interest received on them. To your question, in a typical unconference, agenda setup happens on the spot (including proposing for topics as well), and this is one such element that we will miss in our event. But, it makes sense because of obvious reasons.

OK, so this is more or less what it is suggested above, right? anyone can schedule a session (fitting some quality requirements) but in case of problems (i.e. not enough rooms), people will be able to reach to you, and you (with whatever help/advice you need) will decide.

Note that we have plenty of rooms, and I don't think in previous years we fit all the slots. Problems are likely that someone prefers a specific time or room based on the schedule / expectations.

How does all this sound?

And a new idea: what about giving a chance to Unconference session promoters to pitch their session very briefly (as in 20 seconds) during the opening? This is especially useful for sessions looking for volunteers (as opposed to those about specific topics where almost everybody knows each other). The idea comes from T149372#2846749

I think all of this is now beginning to make some sense :) A couple of questions and additional things:

Instead, we could

1. Set official time, place, and requirement to schedule Unconference sessions for the same day. For instance, 9am in the board located at X; only sessions with a Phabricator task fitting minimum requirements will be accepted. Promoters of sessions can agree changes between themselves. Any problems to be directed to @srishakatux, who can ultimately resolve Unconference scheduling problems.

I agree on this. But still I am wondering that when in our unconference, there won't be any voting and the proposed sessions will definitely be given a spot, then why do we need to run a scheduling phase for those sessions during the event? Just curious. Could we not schedule alteast those sessions a few hours before the event (update on our wiki and the bulletin board) and allow new ideas to fill up the remaining slots on the board?

1. Document whatever we have decided in the Unconference wiki page.
2. Link to the Unconference page in all our communications to Summit participants. Send an email to all Summit participants a week before the event about the Unconference only.

Yes, all of the above sounds great, and the idea of letting session promoters pitch their session too. One thing to add: in the email to our participants about the Unconference, I think it might still be nice to include a link to the unconference column on the dev summit whiteboard for people to be able to read the proposals, and bring some food for thought to add to the discussion. Also mention that if they haven't proposed yet, they will get a chance to submit their ideas at the event. What do you think about this?

In T147955#2858337, @srishakatux wrote:

I agree on this. But still I am wondering that when in our unconference, there won't be any voting and the proposed sessions will definitely be given a spot, then why do we need to run a scheduling phase for those sessions during the event? Just curious. Could we not schedule alteast those sessions a few hours before the event (update on our wiki and the bulletin board) and allow new ideas to fill up the remaining slots on the board?

If the Unconference scheduling starts (say) at 9am at the venue, then all session promoters are more or less on an equal foot and can organize/discuss themselves in situ. We organizers would not do anything other than set the empty board and be available to answer questions or help reaching decisions in case of conflict.

If we open the scheduling "hours before" and online, then we will stress some people out on their Sunday / during their travel / at their sleep or jet-lag time, opening the can for unfairness that was documented in our Lessons learned.

It is quite normal for Unconferences to have that game of empty schedule, post-its for sessions, and little stickers for people interested. Why not doing just that?

1. Document whatever we have decided in the Unconference wiki page.
2. Link to the Unconference page in all our communications to Summit participants. Send an email to all Summit participants a week before the event about the Unconference only.

Yes, all of the above sounds great, and the idea of letting session promoters pitch their session too. One thing to add: in the email to our participants about the Unconference, I think it might still be nice to include a link to the unconference column on the dev summit whiteboard for people to be able to read the proposals, and bring some food for thought to add to the discussion. Also mention that if they haven't proposed yet, they will get a chance to submit their ideas at the event. What do you think about this?

Sure, to me all this belongs to "Document whatever we have decided in the Unconference wiki page." :) The email could focus on the calls for action, and be short.

Here's my two cents:

• I like the 20-second elevator pitch idea. (Is this just a "Lightning talk" with a "for more, sign up for my unconference session" followup?)
• Scheduling unconference sessions to run concurrently with two tracks of pre-scheduled talks is going to introduce conflicts. We should have slightly better scheduling mechanisms than last year to deal with that. One option: let folks add time preferences or conflicts when they sign up to express interest and "somehow" take these preferences/conflicts into account. The goal is to not select a "10 people are interested" session over a "5 people are interested" and then put it in a time slot when only 2 people can attend.
• One of the disadvantages of unconferences IMO is that because they are scheduled at the last minute on the fly, proposers tend to be rather underprepared. That is, the proposer might have pulled together handouts or thought through an agenda or discussion points, but didn't bother because they weren't sure that the session was going to take place, didn't know how many handouts to print out, etc. Can we somehow encourage those who propose unconference topics to come prepared to actually lead sessions?
  • One way of doing this would be to pre-select some unconference sessions. Proposals which were "on track" but didn't get a prescheduled slot, for example. (But this is "unfair", doesn't guarantee there will actually be attendees, etc)
  • Another way might be to allow pre-expression of interest online, so that certain proposals can be seen early to have a high likelihood of making the cut, which would encourage the proposers to actually prepare materials.
  • A third way would be to separate the "voting" from the actual unconference sessions, so proposers have at least a little bit of time to prepare. For example, voting on the sessions for day 2 could be done during day 1, with votes closed at the end of day 1. That gives the proposers overnight to prepare for the session, and gives the organizers overnight to arrange an optimal schedule for day 2. (Of course this doesn't work for day 1, and may disadvantage ideas brought up too late on day 2 to make day 3's unconference.)

None of these ideas is perfect. I'm interested in hearing other ideas.

I would say if we are going to have "unconference sessions" that are not really unconferece then we should not call them that and just convert one of the unconference rooms into another pre-scheduled room.

I am not actually saying I think we should do this in this case, I will leave it up to the program committee as everything is possible. My point is about not confusing people by calling something one thing that has a clear definition but having it actually be another thing. We do not NEED to have a pure unconference at this event and it might even be interesting to have a discussion on the pros of doing that to understand what we would be loosing if we move to a more "everything is at least a little bit pre-scheduled" model. Just because we do unconference at hackathons does not mean we need to do them here too.

I would like to give support to some of the community members who might want to run a session but are not following the pre-event session organization as closely as soon of the WMF staff are.

For unconference sessions I like the idea of voting for day 2 sessions during day one. Ideally we can leave a small amount of space for last min needs.

Originally it was suggested to do a day of prescheduled followed by a day of unconference. People did not like this idea. So now we are back to both simultaneously. Because of that, and because of the nature of unconference we can not prevent all scheduling conflicts. The situation laid out by @cscott above would not be ideal, however in cases were there are just too many good options... I think there are worse problems to have. The more small and specialized groups we can have the better.

@Rfarrand Hmm, I had the idea that we were doing 2 days of prescheduled (with unconference on the side) followed by one day of pure unconference... but according to the web site, I'm wrong: the final day is "pure unscheduled" with no unconference at all (as I understand it). I guess there's nothing preventing someone from setting up an adhoc unconference on the final day to organize further discussions.

I'm pretty happy w/ our prescheduled sessions, in that they seem to hang together as statements of what we think the entire organization should discuss *together*, as opposed to more narrow subgroup interests. Tracks and parallel unconferences take away from that togetherness, although they do provide some wiggle room for topics which are not actually of interest to 100% of attendees. I'd consider a more discrete "one day of talks/discussions, one day of unconference, one day of unscheduled" for next year, where we put even more effort into the single day sessions to make them compelling and universal. Possible theme for 2018 day 1: "a tour of the future of our platform", with plugs/discussions for as many of the unconference sessions occurring 2018 day 2 as possible, putting the unconference in context.

That's not actually what we have this year, though. I think perhaps the best we can do is vote for day 2 sessions during day 1 (or maybe online, until say 9pm of day 1, to allow for topics inspired by the very last of the prescheduled sessions). Day 1 unconference will be a bit of a crapshoot, perhaps, but then day 2 should be as well-organized and conflict-free as we can make it.

And on day 3 chaos reigns.

@cscott: Day 3 is a self organized day or "Hacking Day" with no meeting spaces available to be scheduled. People can informally meet, discuss, work, socialize, whatever they want and have lots of space to be flexible in. This is due to popular demand and feedback from previous years. We are working on a way to help people indicate what they are doing and find other people and topics to get involved in.

Regarding your second point, I am totally open to anything for future Dev Summits and basically would only make big/major changes based on data from either the feedback survey (help me figure out the best way to ask about this in the survey!) or by request from the program committee. One main thing being to keep the third day free of pre commitment leaving it open for people to use it to adapt to needs that come out of the first two days.

@Rfarrand Yup. We should probably keep this task focused on this year, not next, though. My apologies.

Perhaps we have some consensus on the "schedule day 2 at the end of day 1" proposal, along with letting folks list day 2 conflicts when they sign up to express interest. That ought to give us schedulers enough time & info to try to craft an excellent day 2 unconference schedule, as well as enough advance notice to allow proposers to facilitate excellent sessions.

Do we need to schedule some time for the "20 second pitch" sessions to kick off the unconference? Maybe the prescheduled sessions should also have 20 seconds, so we start the day with a complete lighting overview.

I wonder how folks will decide whether to propose unconference sessions for day 1 or day 2? Perhaps we really only need a single pitch session. If it's at the end of day 1, it could really kick off the voting for day 2, and avoid having folks repeat their pitches multiple time. Day 1's unconference would be pitched online (and maybe with signup online), and then day 2's unconference would be more spontaneous, pitched at the end of day 1 with signup immediately after. Thoughts?

Do we need to schedule some time for the "20 second pitch" sessions to kick off the unconference? Maybe the prescheduled sessions should also have 20 seconds, so we start the day with a complete lighting overview.

yes, this will happen during the Dev Summit opening! :D

Regarding specifics about the Unconference logistic specific stuff I think @srishakatux may have already thought through some of this stuff. Also @Qgil
will be able to comment on the flexibility of the schedule for adding in extra things (like an additional pitch sessions) at the end of day one.

In T147955#2860889, @Rfarrand wrote:

I would say if we are going to have "unconference sessions" that are not unconference then we should not call them that and just convert one of the unconference rooms into another pre-scheduled room.

I agree with @Rfarrand's point here! @Qgil If we are worried about scheduling conflicts/ unavailability of facilitators at certain times, we consider inviting them to book a slot via our schedule table a couple of weeks in advance. For any overlaps, we (I) help resolve that. This also support's @cscott's point of giving facilitators enough time in advance to come prepared for sessions, with handouts, etc. I do think that facilitators prepping themselves beforehand for outcome-driven sessions make sense.

In T147955#2865653, @cscott wrote:

@Rfarrand Hmm, I had the idea that we were doing 2 days of prescheduled (with unconference on the side) followed by one day of pure unconference... but according to the web site, I'm wrong: the final day is "pure unscheduled" with no unconference at all (as I understand it). I guess there's nothing preventing someone from setting up an adhoc unconference on the final day to organize further discussions.

I think that running a pure unconference parallel to the hackathon is a great idea! We use this format to give discussion space to those ideas that got emerged during the day 1 and day 2 of the event.

I think if we decide pre-scheduling our current 'unconference' sessions; we don't need a 20-second pitch for them. We run pitch only for the real unconference sessions on the third day.

For day 3 - we have some room limitations that are not flexible.
Our two biggest rooms will be hacking spaces. Our next biggest room will hold the CE offsite. Our next biggest room is booked for a private meeting for at least 3-4 hours of the day (timing TBD).
For meetings on Wednesday people have these options:

• use 40 person "prince" room when it is not in use for the private meeting
• use 20 person "chapel hill" room
• use 7-10 person "oak" room

I also want to keep this a true unscheduled day. People can move around and use the space as is helpful for them but the organizers are not going to be directing people to go certain places at certain times via schedules.

MONDAY: Unconference organizers need to be at venue at 8:50 to register. There will be one early bus leaving CQ 10 min early.
Unconference scheduling happens between 9:00 - 9:30 at post-it wall in Ventana (not on the wiki). During key notes organizers will add sessions to schedule. All session organizers are responsible for checking the session titles and adding links to correct documentation. After the opening / keynotes finish and the initial unconference schedule is up, any remaning spaces can be scheduled online directly by people who want the space to run a session.

TUESDAY: Unconference organizing happens at 9:00am Tuesday @ post-it wall. Same as Monday.

Two ideas that I have floated in a conversation with Rachel and Srishti:

• Let's embrace the Unconference concept. Even if now it looks like we might have a problem of space because the "Unconference" column has a lot more proposals than slots available and we even need to prepare for new sessions being proposed on the spot, I think at the end it will be fine. The system self-regulates: with max 200 people and max 5-6 concurrent sessions, there is simply no more energy for more concurrent sessions. Every year there have been proposals that at the end didn't happen (for a good reason, people were busy at other sessions they considered more important) and every year there have been some empty slots at the end.

• In case of conflict, let's give priority to those who are proposing their first session. While inertia or "common sense" leads to think that more popular sessions should have an advantage, in fact predicting the actual interest that one session will have when competing with others is very difficult. Most events have big rooms with just a bunch of people while smaller rooms are packed. Something that it is very simple to assess is how many sessions someone has already run, and give priority to those trying to schedule their first session. Diversity of people means diversity of perspectives, and that is a good thing in itself. We still run into the risk of miscalculating space/attendance, but at least we give a chance to more people to drive their session.

Today I have shared our ideas about the Unconference with Cscott and Greg, and both thought that they made sense. Yay!

One point that Cscott made was that it still makes more sense to organize the Tuesday schedule at the end of Monday. This is something that Rachel, Srishti and I discussed in our meeting, and we leaned towards, Tuesday morning, but Cscott has good points:

• If it is about inclusion and diversity, chances are that there will be more people around at the end of Monday that on Tuesday before the first session.
• Specially those who had difficulties arriving early on Monday are likely to have difficulties also early on Tuesday.
• At the end of Monday there is more time to discuss possible conflicts in needed. On Tuesday morning we will have the extra pressure of starting the second day and be on time for the first session.

What do you think?

@Qgil @Rfarrand I've updated the unconference page: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Unconference. Feel free to make edits!

@Qgil Sessions such as T149282, T14930, T148734, and there might be others too, I've not gone through the whole list yet, I'm wondering if we want them to keep them on the unconference board still?

Also, when we reach out to the participants in the next two days, asking them to express interest in sessions they want to attend, what do we say about the ones which do not have an assignee or the assignee won't be able to attend the summit?

I have acted on the tasks that were merged into bigger sessions, either merging them or detaching them from the Summit project.

I have also added a column "Confirmed Unconference sessions" and I have added those that have followed @srishakatux's instructions. Srishti, you can take it from here, moving those proposal that follow your steps (and removing any proposal being moved without doing the changes required to the description.

This distinction will be useful to see who has a stronger plan beforehand. It will be useful for these sessions to gather attention from other participants more easily (we can promote this column in our upcoming announcements).

People will be able to propose sessions on the same day and even on the spot if there are rooms available, so we are not discriminating anybody with this move. We are just helping those actively pushing their sessions.

I think this is the last detail I touched related to the Unconference? :) From now on is all yours.

OK, I made a few changes - mostly formatting to make it easier to read.
I am really sorry if I am confusing things because of my bad memory - but didn;t we agree to keep it consistent and do scheduling both mornings (instead of in the evening on Monday?) If I am remembering that wrong, sorry!! and feel free to change it back.

I will just need to update the times the last shuttle bus leaves on Monday if people are scheduling unconference after the last session. It could also impact people's plans for the small group meals... Like, we can not allow the scheduling Monday evening to go on more than an additional 10 min without messing with people's abilities to choose their dinner groups. I do not want to go back and ask all dinner group organizers to adjust their plans.

We could also try a combination of Monday evening / Tuesday morning. Like people can propose during both times and decisions are made by Srishti Tuesday morning.

Sounds like we need more discussion - and sorry if I am confusing things!

The description says

Prepare slides

Slides is what we had last year, and this is why we need to prepare this documentation again. I would go for on-wiki documentation, easy to refer to and update year after year.

our fancy-schmancy unconference board:
https://upload.wikimedia.org/wikipedia/commons/5/51/Unconference_sessions_Monday_DevSummit17.jpg
https://upload.wikimedia.org/wikipedia/commons/a/a5/Collaborative_unconference_program_at_DevSummit17.jpg