The original idea comes from @vbaudry and @nauman from the http://rubyonrails.link team, by the end of 2015. The concept was to use Slack to create content based on a rich discussion between experts and novices in one field. And use that content to create an organized archive that could be published in some way (on a website, as a newsletter, ...).
Because it roots its concept into what a podcast does, @mose came up with the name 'SlackCast'. It just has no spoken words, just writen ones.
For each SlackCast event, a topic must be defined in advance. That way participants can prepare in advance question or resources that they can share about it.
It's an event where participants need to be strongly engaged in their interactivity, so they need to prepare in advance that they won't be available for any other interaction during a given unit of time.
One hour seems to be an arbitrary duration that is reasonable enough, but this can vary on case by case basis.
To conduct the flow of the conversation and make it bounce smoothly, someone has to take the role of moderator, or animator. This person is in charge of keeping people on the topic, relaunching the subject if there is any void, maybe preparing a list of important questions on the topic.
The participants are better if defined in advance and are present for the whole duration of the SlackCast. On slack we are used to see people pop up in the middle and it's all good, but given the goal of the event, it's better for consistency and fluidity that everyone follows the same stream of discussion from the beginning to the end.
Ideally the group of participants should be composed by people of 2 categories:
The goal is is to have a natural flow of discussion and fruitful sharing of knowledge and experience between all the participants.
When the SlackCast is closed, someone will go into the logs and curate the content to split it by subtopics, remove pieces of content that bring no value, extract the good juice form the whole flow, and prepare something that could be publishable in some ways. The format of publication is to be negociated with the publisher.
When the SlackCast is curated by the Editor, the publisher will .. well, publish it. In many cases I guess the editor and publisher can be the same person, it can also be a participant but it's not required.
Depending on the publication media the format can vary.
All this is good and well, but now we need to make it real. We plan to organize a first recording session during december 2015, on a week-end.
When: Saturday January 9th, 2016, 13:00 - 14:00 UTC
Topic: How to publish your ruby code
Summary: we will discuss about github committing, how to shape a project to make it publishable, how to write a ruby gems, how to package ruby gems in other package management systems (debian, freebsd, or others), what about the lifecycle after first publication, and how to pass a project over to someone else if you abandon it.
Moderator: Nauman Tariq
Note: This is a prototype, not a real session,which purpose is to produce a proof of concept. But anybody is welcome to join. Contact @nauman or @mose on rubyonrails.link slack group if you want to jump in.