Organizational suggestions for Vancouver 2018

[joyeecheung]

I would like to propose that we do a few things this time to make sure we can have a productive summit:

1. Add a 5-10 minute slot on day 1 to bash out the agenda, roughly count the people who want to go to each session, and divide the space based on the head count / nature of the sessions. (For example, there are talk/Q&A-ish sessions and round-table discussion type sessions, the main room would be better for the former and break out sessions would be better for the latter. Also, try not to create conflict among topics that are likely to attract the same group of people)
2. For discussion type of sessions, identify a chair/facilitator and a note taker, if possible, to make sure we can walk out of the room with something actionable, and something that can be looked up later. Having an open-ended discussion without a facilitator among a big group of people is not something that we have to be physically in the same place to do - GitHub is a better forum for that.
3. If there are more than 10 participants in a discussion, it would be really hard to have a productive discussion that could not have better happened on GitHub. I suggest that we iron out the items that need to be discussed before the session (can be proposed as bullet points in the issue), and use something like https://tcq.app/ (used by TC39) to facilitate discussion. If we are going to setup remote participation, this would also help remote participants to have a chance to talk.

[joyeecheung]

Another suggestion: record the session whenever possible.

cc @mcollina @mhdawson I remember the last time we used Zoom in Berlin. Are there any instructions on how to set it up? It would be nice to have them written down before the summit (also we can reuse that for future summits), or have a walkthrough onsite before the summit.

[keywordnew]

Hullo folks! The doc in PR #113 has processes and tools we've used at the last summits, nodejs meetings, and one that I've found super useful for my own purposes.

Feel free to comment or make new commits to the patch branch!

[mcollina]

Add a 5-10 minute slot on day 1 to bash out the agenda, roughly count the people who want to go to each session, and divide the space based on the head count / nature of the sessions. (For example, there are talk/Q&A-ish sessions and round-table discussion type sessions, the main room would be better for the former and break out sessions would be better for the latter. Also, try not to create conflict among topics that are likely to attract the same group of people)

It is better to do it once on Day 1 and once on Day 2: the number of people attending would be different, and certain sessions has been scheduled in a certain why to allow some individuals to attend. I do not think bashing the agenda with 100-300 people is useful in any ways.

I would prefer if we do the room selection on Github first, and do a confirmation-only poll onsite. "Who is going to attend A/B/C"?

How can we solict feedback in the agenda?

For discussion type of sessions, identify a chair/facilitator and a note taker, if possible, to make sure we can walk out of the room with something actionable, and something that can be looked up later. Having an open-ended discussion without a facilitator among a big group of people is not something that we have to be physically in the same place to do - GitHub is a better forum for that.

Absolutely

If there are more than 10 participants in a discussion, it would be really hard to have a productive discussion that could not have better happened on GitHub.

All sessions have more than 10 partecipants in Vancouver, so this is implying that we should have those conversation on Github? Maybe I'm reading this wrong.

I suggest that we iron out the items that need to be discussed before the session (can be proposed as bullet points in the issue), and use something like https://tcq.app/ (used by TC39) to facilitate discussion. If we are going to setup remote participation, this would also help remote participants to have a chance to talk.

+1 on having an agenda before hand and setting up remote participation.
I personally find TCQ extremely confusing, but maybe that's just me.

[joyeecheung]

All sessions have more than 10 partecipants in Vancouver, so this is implying that we should have those conversation on Github? Maybe I'm reading this wrong.

I was suggesting that "it would be very hard unless we do the facilitation right" (i.e. with something like the TCQ), probably a bit ambiguous in the wording there, sorry.

I personally find TCQ extremely confusing, but maybe that's just me.

I think it's less confusing after seeing it in action and use it for a while - it takes a bit of time to get used to but it's a great tool for the purpose it is intended for: facilitate a synchronous discussion among a big group of people within a limited amount of time, and hopefully achieving consensus after different arguments are walked through in an orderly way.

[joyeecheung]

It is better to do it once on Day 1 and once on Day 2: the number of people attending would be different, and certain sessions has been scheduled in a certain why to allow some individuals to attend. I do not think bashing the agenda with 100-300 people is useful in any ways.
I would prefer if we do the room selection on Github first, and do a confirmation-only poll onsite. "Who is going to attend A/B/C"?

Yes I agree, it would be easier to get this sorted out on GitHub first. Maybe we can just open an issue to count the attendance, adding replies for each one of the topic, and ask people to use emojis in the thread to indicate whether they are going to be there or not (like what we do with TSC/Build meetings)? (probably we don't want to do that in the topic issues because there are several emojis there just as reactions already)

How can we solict feedback in the agenda?

I am thinking about two issues, one for attendance counting, and another one for scheduling and try to group the sessions into tracks and to avoid conflicts for people interested in a certain set of topics. WDYT?

[mcollina]

I am thinking about two issues, one for attendance counting, and another one for scheduling and try to group the sessions into tracks and to avoid conflicts for people interested in a certain set of topics. WDYT?

@joyeecheung go for it. I manually checked which wg was scheduling a session and make sure that there was little to no overlap. So far there have been 1 request to move things which could not be satisfied (conflicting question, and I took the approach of first-come-first-serve): some people will not be available on day 2.

[joyeecheung]

@mcollina I've minimized your comment in #114 so it looks cleaner.

(On a side note, should we use a google form so that we don't show the attendance in public? It sort of hits me that it seems to be inappropriate to do this in public)

[mcollina]

You are right. Il giorno lun 1 ott 2018 alle ore 16:18 Joyee Cheung < notifications@github.com> ha scritto:

…

@mcollina <https://github.com/mcollina> I've minimized your comment in #114 <#114> so it looks cleaner. (On a side note, should we use a google form so that we don't show the attendance in public? It sort of hits me that it seems to be inappropriate to do this in public) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#111 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADL4z-NFraLYibKu4m7Pjc8hEXFHsA0ks5ugiQxgaJpZM4W86le> .