openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Isabel Drost-Fromm <>
Subject Re: Propose weekly "Technical Exchange" video meeting for OpenWhisk
Date Wed, 07 Jun 2017 18:24:40 GMT


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.


Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most likely involving
some kind of mobile connection only.)

View raw message