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:
- community development (people knowing about + liking each other)
- action towards the roadmap (achieving our common goal)
The key advantages to “Mush to Bricks” are:
-
Everyone gets background on the roadmap, so we’re building on work done, rather than re-discussing, and getting new participants up to speed
-
People move to action when they want, instead of waiting for the entire group to be ready.
-
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.
-
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
- 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
- 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.
- 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.
- In general, we need more organizers - this structure will work much better with active facilitation, thoughtful ‘connecting’ so people find good collaborations quickly, etc.
7 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:
-
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.
-
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?
3 Likes
First - let’s call the second part a ‘funconference’ 
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.
2 Likes
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
2 Likes
Hi @Jsmleete @juanpedro.maestre @ryanfobel @alisonjparker @jcm80 @shannond @dusjagr @thomasmboa @jorgeappiah @nanocastro @fernandomeneses @JiLi @mariafrangos @small_peanut
Thanks for continuing the discussion.
Do you intend to send a survey to participants regarding what they keep and would change? Did you do it in previous gatherings? If yes, are the results public?
Regarding the agenda proposed by Greg:
How do we ensure that participants agree on your agenda and roadmap, respectively can enhance them?
How can the group improve their way of collaborating during the event?
What about speaking of each participant being able to find meaning in the activities, and cooperate in a constructive way with each other, even with people they don’t like? Let’s foster inclusion, not communautarism. 
Best,
So the the core goal of the international GOSH is to handle the roadmap. Not to say it can’t be adjusted or updated or have suggested changes at other times, but because it’s a large scale community document, having international GOSHs as the main update point I think makes sense (and has been at least so far the norm).
Rd: your point regarding inclusion and interaction… this is one of those tricky things… it’s a broader question of how a community self-organizes (and thus is self-motivated to do so) and handles items that people don’t actively want to do (like work with people they don’t like, or perceive they don’t like, or on issues that aren’t super interesting)…
In my experience so far, giving time for humans to enjoy each other’s company and foster empathy kind of handles that problem on the back end. Also, many members have taken on tasks they haven’t really wanted to do, but did so in the spirit of knowing they needed to get done (organizing is one for sure, but also @julianstirling and @amchagas and others for keeping tabs on the git repo and sending out gentle reminders and update requests.
So those things help, but to your point they are probably not enough, and I agree other ideas that foster inclusion would be helpful.
2 Likes
Hi @gbathree, @ryanfobel and all
Thank you for the great Job, I really enjoyed this event.
Regarding the “Structure + concept for running regional GOSHs”, my comment is threefold.
-
I want to share with you what we are doing for AfricaOSH to build our program
Attending AfricaOSH is by applications. Where we ask people which topics interest them, what kind of activity they want to do during the event (presentations, workshops, panel, nothing….). From selected applicants, we are doing an analysis of their replies and that is how themes emerged from the ground. That means, our program is shaped in advance regarding expectations and willing of attendees. At the end, all attendees can do what he wanted to do or share with the audiences. Generally, I am in charge to build the program. Even if it is true that qualitative analysis takes a lot of time, it is a fair way to have the real expectation of a group.
Usually, the type of session we have are: individual presentation, Panel discussion, breakout sessions, workshop and unconferences.
-
About unconferences.
Unconferences are very important because the facilitate the coming out of a certain of attendees who are discovering OSH, or are new in the field. Because, during the event, an Idea can bloom in their mind and they can decide to share with people. Generally, these unconferences are scheduled at the end of the day, before the daily wrap up.
-
Regarding the GOSH roadmap
We did a session on the GOSH roadmap only during the first edition. But do it every year, can be problematic. Because, people will feel like they are in the box and the GOSH roadmap is not an evolutive document; like that we are going to lost all the potential of this strategic powerful document. So, put GOSH Roadmap everywhere in the program can have a reductive effect. As organisers, we all know that all sessions we are doing during the event can fit in one of the section of the Gosh roadmap (grow, support, learning). Based on our report, we can put the outcomes of our sessions in each section of the roadmap which fit with. That is how the roadmap can evolve year after year, region by region; because we don’t have the same challenges.
The problem we have is the lack of volunteers who can help with documentation.
That is what I can say for the moment (never forget Extra activities aka…funny-conferences/ retreat. 
)
3 Likes
I think “mush” has a huge role to play in bringing people into the community. These sessions at GOSH in Shenzhen really made me feel like a valued member of an open community from day 1, and this has driven my future involvement. I think that hacking on a project or two would have been fun, but wouldn’t have brought me into the community in the same way. I hope that regional GOSHs can also find a way to keep this, while also doing more bricks.
I don’t really like the term “mush”, it sounds negative to me. I think the “mush” is really the “cement” that holds us together. When we first started we needed lots of cement to pour solid concrete foundations. We are now building the walls and we need bricks for that*, but we still need cement for mortar or the bricks will come apart.
Semantics and analogies aside, I think it is important for new members at regional and global gatherings to be aware they can help shape the roadmap. Cement/Mush helps with this, and I think it works best if new and seasoned members are present. That being said, we need more bricks if we want to achieve our goals.
@gbathree: You understand unconferencing better than me… would the following work?
We could set a timetable with times which are all bricks and times which are all cement/mush. Then use the unconference planning session to both plan sessions for the cement/mush, and to introduce bricks. The bricks could be active projects we want help on, projects we would love to start, or even things we don’t have the ability to do but hope someone else might want to take on. Along side the bricks could be skills workshops to help new people engage.
* To anyone who wants to fight my analogy by bringing up all concrete building… the “bricks” become “rebar”!
4 Likes
Thanks to everyone who replied. Thomas - I really like the idea of an expert in the community actively shaping (qualitative analysis as you said) the themes based on input of the applicants. That’s a nice middle ground, and to your general point Fabio we need to take advantage of expertise whenever possible.
I think in the moment, ‘mush’ was not feeling great, but your right Julian that it’s critical. Cement is a far far better and most positive analogy, I’ll use that from here on out. And what you outlined also sounds good - I think our general concept wants more opportunity to take action on a new and interesting idea in the moment, and what you’re suggesting hits on that as well.
I don’t know the exact answer but this conversation has definitely helped me, and I definitely hope that future local organizers look at this thread to inform how they organize things.
Also, Thomas, if you have a good method that you’ve got good feedback on (and it’s structured more than you’ve already described), it’d be worth putting up somewhere.
1 Like