Maybe not, but it seems important to be ready to. I’d anchored to the Google Meet limitation of 25 participants without an Enterprise account (which works in the «small-M presenters» × «large-N broadcast» model), but it’s likely that more than 25 would like to be able to follow.
Zoom allows up to 100 on a $15/mo plan that includes recordings, which could be a good fit and enables a lighter touch to moderation. > On Aug 9, 2019, at 7:13 PM, Murukesh Mohanan <murukesh.moha...@gmail.com> > wrote: > > Do we need to moderate heavily from the get-go, or should we implement all > this after a couple of trial calls to see how bad things are? > > On Sat, 10 Aug 2019, 08:27 Scott Andreas, <sc...@paradoxica.net> wrote: > >> On the "virtual" side -- >> >> I've spent some time this week reviewing how the Kubernetes community >> conducts their weekly meetings. References are at the end of this message. >> >> If we'd like to hold occasional virtual meetings among the dev and user >> community, here are some things that may help make them successful: >> >> 1. Agenda: Discussed and committed on the dev list in advance, published >> on Confluence, with speakers confirmed and topic durations assigned. >> 2. Video Call: To be dialed into by confirmed speakers, eliminating the >> need for heavy WebEx-style moderation, several minutes of "please mute, >> everyone mute...," or difficulty enforcing ASF code of conduct if someone >> joins an open call in bad faith. Google Meet appears to be free for up to >> 25 participating / presenting in a call. >> 3. Live stream / broadcast: Google Meet meetings can also be broadcast >> live to YouTube and recorded for non-participating attendees to watch >> (e.g., via EveryCord now that Hangouts on Air is discontinued). This would >> enable a model in which a smaller number of speakers could present, with >> anyone in the community able to join and watch live or at a later time. >> 4. Moderation: An emcee to introduce the agenda, hold speakers to time to >> ensure discussion on one item doesn't prevent the rest from being reached, >> and represent community Q&A. >> 5. Community Q&A: We could conduct Q&A with community members via ASF >> Slack during the call – e.g., a moderator reading questions shared via >> Slack, answered by presenters. Text-based Q&A also mitigates the risk of >> runaway "not really a question but more of a comment..." dialogue. >> 6. Notes: As others mentioned, notes should be prepared (live or after the >> fact) and archived on Confluence alongside the agenda. >> 7. Decisions: Happen on the dev list, though discussion and >> consensus-building may occur during calls like this. >> >> Hosting / moderating calls like this takes planning and effort, but it >> seems very doable if others feel it would be valuable to our dev and user >> community. Happy to help if so. >> >> – Scott >> >> --- >> >> References: >> [1] Meeting doc: >> https://github.com/kubernetes/community/blob/master/events/community-meeting.md >> [2] Agenda: >> https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY/edit#heading=h.en8cy6hno0c6 >> [3] K8s Zoom Guidelines: >> https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md >> [4] K8s Moderation Guidelines: >> https://github.com/kubernetes/community/blob/master/communication/moderation.md >> [5] Example recorded meeting: https://www.youtube.com/watch?v=6uZScaWEb08 >> >> On 8/9/19, 10:27 AM, "sankalp kohli" <kohlisank...@gmail.com> wrote: >> >> @Dinesh/Nate: Yes we need to decide on the timing and we can always >> change >> them as we go >> @Joshua/Gary: We will publish notes on the mailing list. If we need to >> make >> a decision, we will still need to get it voted on the ML. We should not >> have a case where someone misses the boat because they could not >> attend one >> of these. So ML is a big part of this. >> >> Additional feedback welcome. >> >> On Fri, Aug 9, 2019 at 6:28 AM Gary Dusbabek <gdusba...@gmail.com> >> wrote: >> >>> Would publishing notes to the ML be sufficient? Apache board >> meetings work >>> this way. >>> >>> Gary. >>> >>> On Wed, Aug 7, 2019 at 4:51 PM Nate McCall <zznat...@gmail.com> >> wrote: >>> >>>> We can do the time mostly fair if we alternate back and forth >> between PST >>>> morning and evening. This will at least let most folks attend >> every other >>>> meeting. >>>> >>>> I agree with Josh's sentiment on the discussions. We can do it, we >> just >>>> have to be aware of it and defer things to Jira and/or ML. >>>> >>>> On Thu, Aug 8, 2019 at 12:42 AM Joshua McKenzie < >> jmcken...@apache.org> >>>> wrote: >>>> >>>>> The one thing we need to keep in mind is the "If it didn't >> happen on a >>>>> mailing list, it didn't happen <http://theapacheway.com/on-list/ >>> " >>>>> philosophy of apache projects. Shouldn't constrain us too much >> as the >>>>> nuance is: >>>>> >>>>> *"Discussions and plan proposals often happen at events, in chats >>> (Slack, >>>>> IRC, IM, etc.) or other synchronous places. But all final >> decisions >>> about >>>>> executing on the plan, checking in the new code, or launching the >>> website >>>>> must be made by the community asyncrhonously on the mailing >> list."* >>>>> >>>>> So long as we keep that in mind (and maybe push it back to 8am >> PST >>> since >>>>> 9am can get pretty ugly for some of the more eastern european / >> asian >>>>> countries), makes sense to me. >>>>> >>>>> On Tue, Aug 6, 2019 at 6:07 PM Dinesh Joshi <djo...@apache.org> >> wrote: >>>>> >>>>>> Thanks for initiating this conversation Sankalp. On the ASF >> front, I >>>>> think >>>>>> we need to ensure that non-Pacific time participants can also >>>> participate >>>>>> in the discussions. So posting the notes and opening up >> discussions >>>> after >>>>>> the meet up to dev@ would be a great way of making sure >> everyone can >>>>>> participate and gets visibility. Additionally, we should >> consider >>>>>> scheduling this meetup in different timezones as far as >> logistics >>> allow >>>>> it. >>>>>> >>>>>> Dinesh >>>>>> >>>>>>> On Aug 6, 2019, at 2:58 PM, sankalp kohli < >> kohlisank...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> There are projects (like k8s[1]) which do regular >> meetings >>>>> using >>>>>>> video conferencing tools. We want to propose such a meeting >> for >>>> Apache >>>>>>> Cassandra once a quarter. Here are some of the initial >> details. >>>>>>> >>>>>>> 1. A two hour meeting once a quarter starting at 9am >> Pacific. We >>> can >>>>>> later >>>>>>> move this to other times to make it easier for other >> timezones. >>>>>>> 2. Agenda of the meeting will be due 2 days prior to the >> meeting. A >>>>>> sample >>>>>>> agenda for next one could cover updates on 4.0 testing, any >> major >>>> bugs >>>>>>> found and/or fixed, next steps for 4.0, etc. >>>>>>> 3. Each agenda item will have a time duration and list of >> people to >>>>> drive >>>>>>> that item. >>>>>>> 4. We will have a moderator for each meeting which will >> rotate >>> around >>>>> the >>>>>>> community members. >>>>>>> 5. We need to figure out which video conferencing tool to >> use for >>>> this. >>>>>>> Suggestions and donation of tools are welcome. >>>>>>> 6. We will have meeting notes for each item discussed in the >>> meeting. >>>>>>> >>>>>>> Motivation for such a meeting >>>>>>> 1. We currently have Slack, JIRA and emails however an agenda >>> driven >>>>>> video >>>>>>> meeting can help facilitate alignment within the community. >>>>>>> 2. This will give an opportunity to the community to >> summarize past >>>>>>> progress and talk about future tasks. >>>>>>> 3. Agenda notes can serve as newsletters for the community. >>>>>>> >>>>>>> Notes: >>>>>>> 1. Does this violate any Apache rules? I could not find any >> rules >>> but >>>>>>> someone can double check >>>>>>> 2. Are there any other Apache projects which do something >> similar? >>>>>>> >>>>>>> This is a proposal at this time and your feedback is greatly >>>>> appreciated. >>>>>>> If anyone thinks this will not help then please provide a >> reason. >>>>>>> >>>>>>> Thanks, >>>>>>> Sankalp >>>>>>> [1] >>> https://github.com/kubernetes/community/tree/master/sig-storage >>>>>> >>>>>> >>>>>> >> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>>>>> >>>>>> >>>>> >>>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >>
