Hi, while overall I think video meetings are a great way to socialise and grow the ties between community members I think there is a risk of excluding people if not done correctly.
On Wed, Jun 07, 2017 at 10:08:26AM -0500, Matt Rutkowski wrote: > - Post recordings of meetings and link from website (with agenda) for > offline access (and for new contributor education) One word of caution: Having to watch videos to figure out what's going on is not a very efficient way of catching up. I think it would be important to also capture meeting notes after each of these conference calls. Imagine having to watch 56 videos a year from now to figure out which alternatives were discussed in relation to some specific feature. > - Educational: “how does this component work?”, “how to debug this?”, etc. I believe this would be important to also capture on the website documentation for those who don't have the bandwidth to watch the video. > - Feature / idea discussion: **non-binding** discussion of anyone’s ideas > to make any part of the project code “better”, more “pluggable” or > integrateable, etc. > + of course, we would want to move/capture such discussions to “dev” > list (binding) and share/develop designs on our Confluence Wiki, as well > as move to GitHub epics/issues once consensus is reached Make sure to avoid creating a climate where people believe that the call is the only way to get new features in, or even just the most effective means to get attention to one such feature. > - Serverless Community: Share experiences on Serverless (conferences, > meetups, etc.) and what is going on in the Serverless space to raise > awareness Again something that should also be mirrored to the lists. > - Connecting: Greet new people and hear their interest and help them > connect with others. Again this shouldn't be done in video only mode, otherwise you'll risk isolating those who don't have the bandwidth to join the call. > - Volunteers: identify key code work areas where we need help and seek > volunteers. Again something where me personally I would try and capture that in an async way as well. Other projects have made good experiences with either explicit calls for action if areas needing help were very general or with flagging issue tracker entries as either beginner friendly or helping hands needed so that ppl interested in helping can find those whenever they have time to look. Sorry for the many caveats, but I think it makes sense to think about what could go wrong and trying to find ways to address these concerns before the community is split into those informed by having the time and bandwidth to participate in weekly meetings and those who don't. From personal experience, integrating those who cannot contribute full time does take extra effort, but typically these people do have very interesting perspectives and often can be turned into active contributors over time. Isabel -- Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most likely involving some kind of mobile connection only.)
