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