GOSH Community Forum

Structure + concept for running regional GOSHs

These ideas came from many people with major contributions from @Jsmleete @juanpedro.maestre @ryanfobel @alisonjparker and others (sorry if I forgot!!!), and emerged from Day 2 of Great Lakes GOSH 2019. Would love feedback from other organizers like @jcm80 @shannond @dusjagr @thomasmboa @jorgeappiah @nanocastro @fernandomeneses and @JiLi

Background

GOSH ‘unconference’ style has been fairly successful at engaging many and diverse people in creating the roadmap. But now that we have a roadmap, our regional GOSHs should be focused on actually DOING the roadmap. The analogy is you use a wrench to build the car, but don’t use it to run the car. Our unconference format is the wrench :). We learned some things at Great Lakes GOSH 2019 that may be helpful in improving.

Concerns about existing structure

The main concern of the current unconference style is that there is too much ‘mush’… meaning too much time rehashing ideas, setting agendas, getting everyone on the same page. Sometimes you can have great conversations when in ‘mush’ mode, but if the goal is to achieve ubiquity by 2025 via the roadmap, the ‘mush’ can feel slow and even frustrating.

From ‘mush’ to ‘bricks’ - quick!

The current unconference structure is not the best for doing the roadmap. So we came up with an alternative structure. @juanpedro.maestre simplified it down quite well - how to go from mush (broad, unstructured discussion) to bricks (clear actions that progress the roadmap we can do now).

We also want to make sure we’re building strong personal relationships and community. So the two primary goals of the conference should be:

GOALS:

  1. community development (people knowing about + liking each other)
  2. action towards the roadmap (achieving our common goal)

The key advantages to “Mush to Bricks” are:

  1. Everyone gets background on the roadmap, so we’re building on work done, rather than re-discussing, and getting new participants up to speed
  2. People move to action when they want, instead of waiting for the entire group to be ready.
  3. We can do more during the event, so share our successes faster. By making part of the conference a ‘working conference’, we can clearly show and celebrate our progress in real time which is motivating for the community.
  4. People who want to work can work straight away Some people like mushy discussions (and they are important!), and some people just want to hack on things. This structure lets people get to work whenever they are ready and not feel stuck.

People may identify a collaborator(s) on day 2 and work on it through the rest of the conference. Maybe they will identify a collaborator(s) on day 2, the collaboration takes 3 hours to complete, and then they return to a table to find a new one. In this way, we can all turn mush to bricks as needed and as appropriate, one brick at at time.

Example structure

What could this look like? Here’s an example structure.

pre-conference (online) Day 1 (evening only) Day 2 Day 3 post-event post-event
Send survey to help identify skills, interests, points of collaboration
’manually’ help connect people beforehand
Morning Manifesto + Roadmap Detail, detailed description of roadmap + parts, overview of progress and state. Important so we start from previous progress!!! Brief Progress updates from Active Collaborations Brief Progress updates from Active Collaborations Fun stuff to build relationships + enjoy our community (going to a lake, etc.) where hacking can also happen. Fun stuff to build relationships + enjoy our community (going to a lake, etc.) where hacking can also happen.
Mid Day Go to Roadmap Tables People go to one of 9 locations (based on 9 parts of roadmap). Each location is like an unconference session - people to sit and talk about that roadmap component and how they can make progress. The goal is to identiify one or more collaborators. Once identified, collaborators break off to work on their projects (leave table and get working!). Others remain and continue to discuss / work until they identify a collaboration and break off, etc. Roadmap Tables for identifying collaborations. Active Collaborations for those already working Roadmap Tables for identifying collaborations. Active Collaborations for those already working
Afternoon Roadmap Tables open for ongoing discussion. Active Collaborations with those working with collaborators (working sessions or hackathon). Roadmap Tables for identifying collaborations. Active Collaborations for those already working Wrap Up pushing work to roadmap (gitlab), feeling good about what we got done, pushing to gitlab what is left to be done
Evening fun stuff! fun stuff! fun stuff! fun stuff!

Potential Downsides

  1. Active collaborations often require preparation + equipment.
  • people should bring their equipment, and/or identify collaborators ahead of time so they know what to bring
  • conference locations should have equipment / space / tools so that if collaboration requires spontaneous stuff (soldering for example), it’s available
  1. People who don’t have active projects may feel lost.
  • Human (facilitation + organizer) support is key. This is still a pretty unstructured thing, so we need to make sure people with experience in the community are there to help support folks who need it, find projects to contribute to, and feel good about their contributions.
  1. Shannon mentioned that we still need a community structure to update and improve the roadmap itself. This type of conference would produce limited feedback into the utility and up-to-date-ness of the roadmap. Probably that should be done at the Global GOSH, rather than regional events, but it’s important to note it’s lacking in this type of structure.
  2. In general, we need more organizers - this structure will work much better with active facilitation, thoughtful ‘connecting’ so people find good collaborations quickly, etc.
5 Likes

Hey Greg, thanks for putting these notes together! I think this is a great start. Really like the idea of using the roadmap as a way to frame the sessions (seems obvious that we should have done that…).

Although there’s nothing about the “unconference” style that prevents people from doing action-focused (i.e., brick) sessions, it seems like there may be value in nudging people into make these things happen so that we don’t spend all of our time rehashing the same topics that come up at every GOSH event. However, I also don’t want to dismiss the value that these “mush” sessions hold in building community, shared-ownership, and helping people to find alignment on interests/actions.

I have a few comments regarding the proposed structure:

  1. I wonder if the 3 day (mush + bricks) main conference + 2 days post-event is the right balance. Personally, I would have preferred if the post-event portion (which was more action oriented) could have lasted longer as it seemed really productive (and fun!). Maybe swapping the length of these sections (i.e., 2 days of unconference followed by 3 days of post-event), or even a 2 day unconference (for onboarding new people into the GOSH community) followed by a week long residency? I could see value in having people go to one or the other or both parts.

  2. Regarding the “unconference” portion, one worry I have with the way it is structured in the proposal above (running mush and brick sessions simultaneously and having people choose where to go), is that you might run into a situation where previous GOSHers (who already know each other and are ready to collaborate) may prefer to jump right into the brick sessions. This may not leave enough of them in the mush sessions to provide continuity of ideas, model the process, culture, etc. Alternatively, if we did mush sessions in the morning and brick sessions in the afternoon, it may provide incentive for people to participate in both types of activities.

Another thing we talked about that didn’t make it into these notes was the idea of having a networking dinner + casual open demo event the night before the conference. The one hour demo session we had was definitely too short, and I think the fact that it was open to the general public intimidated some people from showing off the stuff they were working on. I think it would have been cool if we could have hung out in a space for 3-4 hours with finger food and drinks, and just let people wander around and check out each other’s projects, meet and mingle with each other. This could replace the speed-dating we did on Wed morning in a way that was more relaxing and hands-on. Would also give people an opportunity to pitch/recruit people to work on activities later in the week.

Finally, if we want to encourage more action-focus and pre-conference preparation, we could always make that part of the application and expectations. We could ask everyone to propose one action that they’d like to accomplish during the event (doesn’t have to be huge), and require some form of deliverable (document, report, art, etc.). I think this is how dinacon works. Maybe @hikinghack could comment?

2 Likes

First - let’s call the second part a ‘funconference’ :slight_smile: :slight_smile: ahhhh dad jokes…

+1 on all comments, especially –

  • more fun time
  • mush has value
  • 3 - 4 hours the night before to geek out w/ tables
  • more extensive applications w/ expectations, skills, etc.
1 Like

hi all

I agree on the changes to move towards more bricks in the roadmap regarding gatherings, however I think we should continue the discussions about the community structure and about other related unsettled and mixed discussions as governance, organization and funding.

as @gbathree points in the potencial downsides of this kind of structure, I think we need a more coordinated organization (and maybe some way/funds to sustain its work…?)

I’m also trying to understand if the role and the structure of regional gatherings should be the same and how to integrate both instances.

Hopefully we will have some feedback from the recently finished first latinamerican residence soon to add to the discussion

Saludos

1 Like