Session Formats #43
Comments
|
+1000 I LOVE the interactive component you're adding here, where people actually create something to present to the group and feed into our documentation. This is brilliant. I'll take this over to the libp2p DM issues as an alternative to 1:many presentations. Where I could use help:
EDIT: Having thought this through a bit, I like the idea of asking people to commit to (at least) one of these in advance. It levels the playing field between experts, who could do a posters in their sleep, and non-experts, who may need to do some background reading and thinking the days before. |
|
@diasdavid Are you envisioning physical posters, or markdown "posters" rendered on a display screen? Physical posters would be more fun to create. Markdown posters would be easier to translate into documentation afterwards. Unfortunately, Markdown obviously does not lend itself well to columnar layouts, so every poster is going to be a long scrolling page. |
Session FormatsThis is a slight modification to @diasdavid's proposed formats. I propose having a mix of
Some design principles to keep in mindHave a variety of activity types: It's a healthy practice to provide a variety of activity types throughout the days -- some lecture format, some small-group work, some big-group discussion, etc -- and ideally we want to let people move around, use their bodies, etc. Each session should have clear, declared outcomes that are achievable in that time frame, and the activities should be designed to achieve those outcomes. By selecting good overall formats, we are making it easier for people to propose a session/topic, slot it into the best-suited format (Technical Deep Dive, Poster-Making Session, etc), and have a bunch of the basic planning work already done for them. Project Update Lightning TalksShort project updates in rapid succession. No more than 30-45 minutes at a time (6-9 updates).
Examples of project updates:
Deep Technical Design SessionsIntensive Technical Design Session This is what @diasdavid is calling "Protocol Design Sessions". We tackle dense technical topics other than Protocol Design, so I prefer to define this session type more broadly as Deep Technical Design Sessions.
Examples:
Working SessionsSmall Team Working Sessions This is a variant on the poster-making sessions @diasdavid proposed. Rather than having people document something in a poster, let them work together in small teams to tackle a work package using techniques like pair programming.
Todo: start the list of work packages people could select from Note: Ideally these teams should be formed before everyone arrives in Berlin. Poster-Making and Poster Viewing SessionsHave fun working in small groups to create posters and other documentation, then give a one-minute presentation of your work. These are the Poster Sessions @diasdavid proposed. I'm just repeating his words with different formatting:
These topics will be pre selected (pre proposed) and they should be things that people keep asking for better explanations or simply are things that are "complex" and we need to document better. Think things like:
The Tetris game of Schedule PlanningWe only have 2 days for pre-scheduled activities, plus a full day for unconference. I have a hunch that some of the unconference sessions will end up using one of the formats we've exposed people to in the first 2 days. The challenge will be choosing the right stuff to put in the pre-scheduled days. To help us think about time constraints and flow through the three days, I've created a [2018][Dev Meetings] Schedule Planning document. We will probably put the finalized schedule into sched.com, but a spreadsheet is easier for the initial planning and rearranging. Some of the items have to be at a specific time. Others are changeable. I put the changeable ones in italics. |
I think people will enjoy themselves more, and potentially produce more interesting documentation if we give them the option of producing physical posters and provide raw materials for doing that (markers, poster board, scissors, construction paper, glue sticks, tape) |
|
FYI I've added all of these formats as PRs (session proposals) in https://github.com/ipfs/developer-meetings/pulls -- @diasdavid I've attributed some of them to you. Please tweak them as you see fit and then 👍 if you're fine with merging it. (or just merge them) |
|
One note: while I think something like an interactive poster making session might be useful for some things, I'd really like to have a knowledgeable person explain in detail most of the things in that list: DHT, secio, libp2p connection flow, IPNS... I think it's a better use of the time to have people that currently hold that knowledge disseminate it with ample time for a presentation and for questions. We currently lack proper slides, talks and docs about many aspects of these things. This would be a perfect chance to produce them. Collaborative exercises are very good when creating, brainstorming and putting things on the table, but I think what we need here is knowledge transfer from people who know a lot to people who know little. |
|
I agree with Hector, but with a twist. I think there is room for both 1:many presentations as well as poster sessions, depending on the topic. The key is that even the poster session needs to be led by a high-knowledge person on that topic. See this issue where I'm trying to recruit those folks for libp2p topics you mentioned: libp2p/developer-meetings#10 Add new topics in the issue, or further explain what you're looking for, @hsanjuan |
|
There are a bunch of interesting pieces which are not libp2p (more IPFS):
|
ghost
mentioned this issue
|
@diasdavid I chatted a little bit with @why, and he's thinking Protocol Design sessions will work best if we do them as 90-minute blocks. (Probably 45+break+45.) I'm going to schedule based on 90 minute blocks for Protocol Design, but if you think they should be shorter (or longer), we can debate it here. |
|
I just have one remark. The high throughput / intense work sessions should not go above 3~4 people otherwise we will have a lot of spectators. Another issue that might happen is that one session will swipe entirely the brains that have most of the knowledge. The Deep Dive sessions should also be 2~4 people tops and multiple should be run in parallel. |
|
Yes, agree on running in parallel. There will be a poster block, and a protocol design block. For protocol design, I think 90 minutes is the right length for the block. @diasdavid For the posters block, any opinion on the right length? I'm leaning toward 60 minutes right now (not including the time afterwards to come back and present to the full group). I've never done this activity before, so not sure. |
|
@diasdavid I disagree about limiting the deep dives to 2-4 people. If the point is to disseminate knowledge, you have to accommodate spectators. A deep dive with 2-4 actively engaged known actors is something we can (and should) arrange any time. Having those 10 other people available to be spectators physically in the room with you is the rare opportunity. Contrast: I agree that work sessions should be limited to 3-4 people. More sessions with smaller groups. During those sessions, people like @diasdavid, @Stebalien and @whyrusleeping will probably need to be circulating around the various groups. |
I want to propose two new session formats in addition to the unconf, invited talks and discussions for the Developer Meetings. I'm calling them "Work Packages" & "Design Sessions" and both have a focus of putting people to work and work together.
Work Packages => PosterSessionsThese sessions consist on gathering people into small groups (2~3) and explore and understand in depth one of the selected topics before hand. At the end of the session, everyone should have a poster ready (this will be fun!) and present it to the rest of the group.
These topics will be pre selected (pre proposed) and they should be things that people keep asking for better explanations or simply are things that are "complex" and we need to document better. Think things like:
These posters and discussions will then be converted into docs and/or specs to the IPFS repos.
These sessions promote collaboration, knowledge transfer through deep dives and generation of materials that can be used by others in the future.
Protocol DesignSessionsOne of the things that we did a lot in the first couple of years of IPFS was to really dive deep and paint the bike shed in order to come up with things such as IPLD, PubSub and other advancements to the original IPFS protocol. These design sessions were intense and they were not about explaining how things work, they were focused on finding the solution with the knowledge and resources we had available.
I want to get back to that and I want others to experience it. We have a bunch of open problems (e.g. Private DHT, scale up the DHT, reduce the information leakage on a libp2p dial, GraphSync, etc).
The output of each of these session would be a RFC like document (can be very raw) that describes the proposed solution (even if with known shortcomings).
@flyingzumwalt @mgoelzer can we have time on the schedule for these?
The text was updated successfully, but these errors were encountered: