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 https://github.com/nodejs/summit/issues/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 https://github.com/nodejs/summit/issues/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 https://github.com/nodejs/summit/issues/111#issuecomment-425924896, or mute the thread https://github.com/notifications/unsubscribe-auth/AADL4z-NFraLYibKu4m7Pjc8hEXFHsA0ks5ugiQxgaJpZM4W86le .

[mhdawson]

@joyeecheung zoom as mentioned may be a challenge. I have access to one account, I'm not sure if we can multiple concurrent meetings from that same account, but we are limited to a single broadcast on youtube.

[joyeecheung]

Opened https://github.com/nodejs/summit/issues/115

[joyeecheung]

zoom as mentioned may be a challenge. I have access to one account, I'm not sure if we can multiple concurrent meetings from that same account, but we are limited to a single broadcast on youtube.

@mhdawson

Can we just use Google hangout if we can't get multiple concurrent meetings going with Zoom?

[mhdawson]

I think that would work, but I don't know that it will be possible to broadcast more than one at a time on Youtube.

[mhdawson]

@bnb can you remind me of how many Zoom accounts we have? I know you mentioned we have more than one now, but I'm not sure how many more.

[hackygolucky]

We have two, afaik, but only one can webinar and only one at any time can be broadcasting live to Youtube.

On Tue, Oct 2, 2018 at 1:45 PM Michael Dawson notifications@github.com wrote:

@bnb https://github.com/bnb can you remind me of how many Zoom accounts we have? I know you mentioned we have more than one now, but I'm not sure how many more.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nodejs/summit/issues/111#issuecomment-426366708, or mute the thread https://github.com/notifications/unsubscribe-auth/AB46oG5m4XVrDALpdkvs7W8yy2PyP5tTks5ug6YxgaJpZM4W86le .

[mhdawson]

So sounds like it might be hangouts instead of zoom, but that still does not solve the problem of broadcasting more than one on youtube at a time. I think we'd either have to record/broadcast under personal accounts as opposed to the Node.js account or record in some other way. I can't remember if hangouts gives us a record option that we can use and then later publish to youtube .

[joyeecheung]

I think we can broadcast the session in the main room with the most people, and then for the breakout sessions we can just use Google hangouts to setup remote participation and record, then publish to YouTube later? (Assuming we figure out how to record with hangout)

[mhdawson]

Sounds reasonable to me.