---
tags: podcast
---

# Videopodcasts project

## List of interesting guests

1. [Arnau (Decidim)](https://hackmd.io/l4UnVxwfTr6M1fRb2zT-3w). Estimated: Sept 8, 2020
2. Rasmus (OS2)
3. Someone from an association of municipalities (VNG?)?
4. Developer?
5. Vendor (OpenZaak?)
6. Signalen (who?)

Guests should already know who we are, and preferrably we should have already collaborated.

### Guest selection criteria

Guests have an interesting perspective to contribute to the development of public codebase stewardship based on their own experience. They can come from anywhere (including non-public open source projects).
The overlap between the guest's experience and our interests should be clear in the invitation, the question guide and our communications for the podcast.

## Following steps

1. [x] Benchmarking: Twitch/Youtube Live, etc. for streaming. All of them ([Streamyard](https://streamyard.com), etc.)?- Alba. Let's start with Streamyard.
2. [x] Benchmarking on how to turn video into audio - Jan
3. [x] Take some ideas from [this list of podcasts](https://civictech.guide/listing-category/podcasts/), [the gov.uk one](https://gds.blog.gov.uk/category/podcast/), or even from [Decidim](https://www.decidim.barcelona/assemblies/BCNdesdecasa/f/3830/proposals/23767). - Alba
4. [ ] Ask colleagues at the Foundation to recommend guests.
5. [x] Think of a name.
6. [x] Contact Elena, Ben and Boris
7. [x] Prepare first [set of questions](https://hackmd.io/l4UnVxwfTr6M1fRb2zT-3w) (Arnau)
8. [x] Contact first guest.
9. [x] Create a short [explanation of Public Code](#Explanation-of-Public-Code) (almost like a bumper) that we can tailor for the intro section
10. [ ] Make a guide for interviewee that we can send to them in advance with general technical advice and possibly reminder that it's a video stream so that they might consider what they wear (if they have a dress code in their public org) and possibly a reminder to give a heads-up to their comms.

## Formats, length and schedule

1. **Frequency**: Amibtion to make it at least monthly
- Do we want it alternating with the second format? Con: long time in between, could be perceived as irregular. Pro: We will not "run out of" codebases quickly. If we do every month, we will have to repeat ourselves quite soon.
2. Two different **formats**: one for codebases, one for the Foundation.
- Stewards. Interview: first a small introduction of the guest, his/her project. Then start the interview. Prepare for at least 20 minutes long but be prepared to go longer depending on how the conversation unfolds and the audience's questions, (that's why it's live). Since it's a hands-on talk related to actual codebases we are stewarding it might be interesting to be conducted by Jan and Alba. If there are anyone else on the team better suited to talk to a particular codebase, switch with Jan. Interviewing is done by a pair (to handle both questions received during the livestream and to introduce dynamicism to the conversation)
- Foundation, *optional*. Ben & Boris having a theoretical conversation: the could talk about the ideas behind the Foundation or news from that month. The duration of this one could be longer but we have to specify this to the audicence. This one could be more a "Community from the Foundation" thing, so maybe Elena could host it. Alba doesn't mind helping here either.
3. Intro: animation and music made by Felix and Jan. Felix is working with a script in order to help us with different copies and titles in future episodes.
4. Language: English
5. Have one or a few recurrent questions we ask every guest. That builds familiarity of the show and can also reveal aspects / differences between codebases.
6. One idea is also to end by asking the guest (and possibly the audience) who we should interview in the future. By doing so we "compromise" another person.
7. Timing: minimum 20 minute livestream during business hours - start 4pm. Promise that podcast will be live by CoB the next day. Aim to hold this on Tuesdays.
8. Get inspiration for the questions from the big assessments spreadsheet

## Goals

- **Become discoverable:** Create another way for people we would like to know who don't know that we exist or what we do *to discover us*.
- **Grow** our codebases **community**.
- Get in **direct touch with key figures** of top projects. Possible way in to steward or make them members of the Foundation for Public Code.
- Get **more** Social Media **followers** since we are going to use those networks for this project.

## Target audience

- Codebase level:
- Civil servants working on public code codebases (ie. potential stewardship material). Project managers.
- Civic tech people working on codebases in use by public orgs
- People interested in FOSS in general
- People interested by specific types of software
- Media following up on a particular codebase or use case.
- The codebase being interviewed and its followers.
- Politicians interested in a specific project/city
- Vendors/tenders
- Other people involved in the codebase: designers, UX, communication, competitors, etc.

- Personal level (interviewee):
- 3Fs: family, friends and fools
- Media if controversial speaker
- Side projects of the interviewee
- Conferences, events, webinars, or similar activities the speaker might be involved with

**Keep an eye on underrepresented collectives (ethnicity, gender, religion, sexual orientation, etc.)**

## Distribution

Use Streamyard.com. It can livestream to several platforms at once. We can start by streaming to:

- [Youtube]. We have to create an account here.
- [Twitter](https://twitter.com/publiccodenet)/Periscope (make sure there is a Periscope account connected to the Twitter account)
- [LinkedIn](https://www.linkedin.com/company/publiccodenet/) page
- Youtube (need to be created)
- [Facebook page](https://www.facebook.com/publiccodenet/)

The Streamyard account need to have someone who has administrator/editor rights on these destination platforms to connect them before streaming (only need to be done once). It's $39/month, up to 8 destinations.

### Reuse as actual podcasts

After the livestream, we could also reuse the audio. By doing some editing on it (cut out long pauses, normalize and compress audio etc.) adding more bumpers in some place we can make it sound more professional. Then we can distribute through any of the existing podcast networks (or even host it ourselves if we want). When a podcast is set up somewhere, and there is a RSS feed for it, it can also be connected to [Hacker Public Radio](http://hackerpublicradio.org/) and [Free Culture Podcasts](http://freeculturepodcasts.org/).

## Awareness raising/marketing

### Basics: native platform video links

For LinkedIn and Youtube the streams can be created long before, and will give the followers an option to be reminded. On Facebook it's only possibly a week in advance. But for all these, they are quite favoured by the algorithms and followers will generelly recieve notifications unless they opt-out.

Twitter only have a shareable link once the streams start, but it is also possible to tag people in the tweet so they easily can retweet it when it starts. For this reason one tactic could be to make the introduction long enough for the guests to be able to retweet it before they are brought on screen. The guests should of course be briefed about this so that they are prepared.

### Before the videopodcast

- Ready **three weeks** (at least) in advance:
- Copies
- Images
- Graphs
- Social Media campaign: short video (?)
- Shared strategy with the stakeholders involved for every interview
- Test everything in advance
- Share the questions with the guest so no delays happen and he/she can run it with his/her communications dept. if needed.
- An ace up your sleeve: backup name in case the current guest can't make it. Ideally, that person would be the next guest.

### During the videopodcast

- Test everything before going live
- Keep an eye on attendees questions and behaviour: when are they connecting, which is the most successful platform and why, best timing, etc.
- Remind them what the Foundation for Public Code does and how to contact us in an easy way
- Remind them at the end of ways of keeping in touch with us and tell the audience who the next person we are trying to interview will be. This is always going to be last question we are going to make to our guest, so the following person would *have to* listen to the *public call*.
- Follow up of attendees/viewers: connect them to a Call to Action such as sign up for our tailored-to-your-preferences-newsletter.

### After the videopodcast

- Set a date for the following one (ideally with a months notice)
- Social Media campaign ending
- Make both video and audio available in our website (if software allows it, right after the interview finishes.)
- Post a blogpost with the link to the video and also the audio
- Keep an eye on the other codebases
- Metrics (number of views, number of people that signed up, increase on number of leads that reach out to us later on, number of clicks in our blogposts, videos, audios, social media, etc.). Iterate, engage and act according to prior data.
- Feedback request: audience and guest

### Other ideas

- Announcing our podcast in a blogpost and share that blogpost on all the platforms we will stream to as a heads up.
- Promotion through the guests network. Give them all the links, graphs, copies, etc. created in advance so that they easily can share them.
- Invite people from diverse backgrounds and underrepresented collectives as well.

## Explanation of Public Code

From [About](https://about.publiccode.net/glossary/public-code-definition.html):

>Public code is both civic code (like policy or regulation) and computer source code (such as software and algorithms) executed in a public context, by humans or machines.
>
>Because public code serves the public interest, it should be: open, legible, accountable, accessible and sustainable.
>
>By developing public code independent from but implementable in a local context, as well as documenting the development process openly, it can provide a building block for others to re-implement in their local context, take as a starting point to continue development or as a basis for learning.
>
>To facilitate re-use, public code should be either released into the public domain or licenced with an open licence that permits others to view and reuse the work freely and to produce derivative works.

From the [Standard](https://standard.publiccode.net/introduction.html#definition-of-public-code):

> Public code is both civic code (like policy or regulation) and computer source code (such as software and algorithms) executed in a public context, by humans or machines. Public code is explicitly distinct from regular software because it operates under fundamentally different circumstances and expectations.

.. so we define public code to be both civic code (like policy or regulation) and computer source code (such as software and algorithms) executed in a public context, by humans or machines. And because it serves the public interest, it should be: open, legible, accountable, accessible and sustainable.

## Youtube description (<1000 characters)

*Should we also use it as a trailer speaker text?*

At the Foundation for Public Code we enable public-purpose software and policy that is open and collaborative.
This results in higher quality services for the public that are more cost effective, with less risk and more local control.

We define ‘public code’ as open source software developed by public organizations, together with the policy and guidance needed for reuse.

On this channel we will livestream our show 'Let's talk about Public Code' and share recordings of our presentations.