Update queue documentation

review of documentation

README.md

@@ -18,10 +18,18 @@ Where we can link to other free culture sites that provide usefull services.
 - Requested Topics
 Where we can track topics that have been requested, and link to shows that addressed them.
 
+## HPR Policies
+
+[See Policies](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/policies.md)
+
 ## Podcatcher and Podcasting Platform Compatibility
 
 [See Podcatchers](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/podcatchers)
 
+## Branding Into and Outro
+
+[See Branding](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/branding.md)
+
 ## Workflow
 
 - [Uploading a Show](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/workflow/uploading_a_show.md) - the processes involved in getting your show to the HPR servers.

branding.md

@@ -0,0 +1,142 @@
+# HPR Branding
+
+## The Intro
+
+### Duration
+
+It will always be 30 seconds long and in some edge cases may be slightly longer.
+The following table will help put that into context.
+It gives the percentage of the show the intro takes related to the length of the shows.
+
+      1.7% of an average show (29 minutes 30 seconds)
+      0.1% of our longest show (7 hours 27 minutes)
+    187.5% of our shortest show (16 seconds)
+
+### Breakdown
+
+### Generation
+
+The intro is generated by the [process\_episode.bash](https://repo.anhonesthost.net/HPR/hpr-tools/src/branch/main/workflow/process_episode.bash#L1388-L1391) script and uses the [say.php](https://repo.anhonesthost.net/HPR/hpr_hub/src/branch/main/cms/say.php) file to generate the data.
+
+The text is [created](https://repo.anhonesthost.net/HPR/hpr-tools/src/branch/main/workflow/process_episode.bash#L1427) using [piper test to speech](https://github.com/rhasspy/piper).
+It was previously created using [espeak](https://espeak.sourceforge.net/), and we are open to [suggestions](https://repo.anhonesthost.net/HPR/hpr_hub/issues/new) on how to improve it.
+
+The text is played over the HPR Theme Music
+
+### Theme Music Credits
+
+The background is an arrangement by [Maestraccio](https://repo.anhonesthost.net/HPR/hpr_website/src/branch/main/www/theme/intro-ak-Maestraccio-cc-by-4.0.mp3) which is released under the [Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)](https://creativecommons.org/licenses/by-sa/4.0/) license, of the [HPR Theme](), composed by [slick0](https://hackerpublicradio.org/correspondents/0042.html) which has [No Copyright](https://creativecommons.org/publicdomain/zero/1.0/) applied.
+
+### Message
+
+To effectively communicate an event it's important to convey the answers to **Who?**, **What?**, **When?**, **Where?**, and **Why?**
+
+> The Five Ws is a checklist used in journalism to ensure that the lead contains all the essential points of a story. As far back as 1913, reporters were taught that the lead should answer these questions about the situation being reported.
+
+[https://en.wikipedia.org/wiki/Five_Ws](https://en.wikipedia.org/wiki/Five_Ws)
+
+
+#### What?, When?, Where?
+
+The first sentence is always **This is Hacker Public Radio episode (show id) for "(day of week)" the "(day number)" of "(month and year). **
+
+Saying the name of the show at the beginning of an episode is called establishing [brand recognition](https://en.wikipedia.org/wiki/Brand_awareness#Brand_recognition).
+It is standard for podcasts, TV and Radio shows as well as on broadcast networks, not to mention the pre-rolls in a movie.
+
+We started to do it because some of our Visually Impaired users appreciated knowing what show is playing.
+Now the same reason can be applied to everyone as the use of visual controlled [User interfaces](https://en.wikipedia.org/wiki/User_interface) have diminished.
+Most people control the playlist with headset or voice controls.
+
+Saying the show id, and date is common where there are a lot of episodes eg: news or weather shows. 
+It is often skipped where the content is sufficient to identify the episode, eg "the last episode of the foo bar baz podcast, or the last Saturday Night Live"
+
+We include the show id and date to allow the listener to refer to the episode easily.
+As we have literally thousands of shows, we need to help people identify which show they are now listening to, so that it can be easily shared, or commented on.
+
+#### What? Why?
+
+We always include **Today's show is entitled. (title)**.
+If the episode is part of a series then we also include **It is part of the series (series name)**.
+We always include the show **(synopsis)**.
+
+This tells the listener what the show is about.
+It allows them to skip the episode if they wish.
+They may wish to do this for many reasons, for example:
+
+- because they are not interested in the topic, 
+- they wish to listen to it while in front of a computer to reference the accompanying show notes, 
+- they are listening in public and the topic might not be appropriate.
+
+#### Who?
+
+The next part will either be **It is the first show by new host (host name)**, **It is the (multiple of 10)th show of (host name)**, or **It is hosted by (host name)**
+
+We are required by the [Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)](https://creativecommons.org/licenses/by-sa/4.0/) license to credit our hosts, so we do.
+
+We think it's important to highlight new hosts especially, so our community we encourage them to continue to contribute.
+
+It's also nice to call out hosts who have been contributing a lot by highlighting each 10th show they send in.
+
+#### Where?
+
+We always include **and is about (minutes)minutes long** to give people an idea of how long the show is.
+
+Normal broadcasts have to fit neatly into a standard TV/Radio Broadcast schedule. 
+Many podcasters now follow the same tradition of having episodes of a predictable length. Eg: 30 minutes or an hour.
+
+On HPR, [there is no restriction on how long the show can be](https://hackerpublicradio.org/about.html) so it's desirable to give the listener a way to know how long the episode is so they can plan accordingly.
+
+
+#### Warning
+
+We always include either **It carries a clean flag** or **It carries an explicit flag**.
+
+This is also common for broadcasts where they are dealing with a topic that may be disturbing to some people.
+
+#### What
+
+We always include **The summary is. (summary)**.
+
+As this also tells the listener what the show is about.
+
+#### License
+
+In the event that the show is not released [CC-BY-SA](https://creativecommons.org/licenses/by-sa/4.0/) we include **Todays show is licensed under a (license_long_name) license.**
+
+## Outro
+
+### Theme Music Credits
+
+The background is an arrangement by [Maestraccio](https://repo.anhonesthost.net/HPR/hpr_website/src/branch/main/www/theme/intro-ak-Maestraccio-cc-by-4.0.mp3) which is released under the [Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)](https://creativecommons.org/licenses/by-sa/4.0/) license, of the [HPR Theme](), composed by [slick0](https://hackerpublicradio.org/correspondents/0042.html) which has [No Copyright](https://creativecommons.org/publicdomain/zero/1.0/) applied.
+
+Over the music is the following text recorded by [Manon](https://hackerpublicradio.org/correspondents/0449.html) which has [No Copyright](https://creativecommons.org/publicdomain/zero/1.0/) applied.
+
+> You have been listening to the Hacker Public Radio podcast, at [hackerpublicradio.org](https://hackerpublicradio.org/).<br>
+> Today's show was contributed by a HPR listener like yourself.<br>
+> If you ever thought of recording a podcast, then visit the [HPR site](https://hackerpublicradio.org/) to find out how easy it really is.<br>
+> Hosting for HPR has been kindly provided by [anhonesthost.com](https://anhonesthost.com/), the [Internet Archive](https://archive.org/),  [rsync.net](https://www.rsync.net/), and the [HPR Community Content Delivery Network](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/ccdn).<br>
+> Unless otherwise stated, today's show is released under a [Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)](https://creativecommons.org/licenses/by-sa/4.0/) license.
+
+# Discussions about the HPR Theme
+
+- [2023-04 intro](https://hackerpublicradio.org/eps/hpr3837/index.html#comments)
+- [2022-03 Great Intro](https://hackerpublicradio.org/eps/hpr3553/index.html#comment_3378)
+- [2022-03 TTS](https://hackerpublicradio.org/eps/hpr3461/index.html#comment_3306)
+- [2022-03 The TTS voice](https://hackerpublicradio.org/eps/hpr3461/index.html#comment_3377)
+- [2021-11 Theme - was "Possible cause and solution to subscriber attrition(trying again without encryption)"](https://lists.hackerpublicradio.com/pipermail/hpr/2021-November/004327.html)
+- [2020-08 the voice](https://hackerpublicradio.org/eps/hpr3139/index.html#comment_3007)
+- [2019-11 Ken's Voice Is Better Than espeak](https://hackerpublicradio.org/eps/hpr2936/index.html#comment_2799)
+- [2018-09 HPR Branding](https://lists.hackerpublicradio.com/pipermail/hpr/2018-September/003541.html)
+- [2018-09 Accordion outro](https://hackerpublicradio.org/eps/hpr2625/index.html#comment_2493)
+- [2018-10 Intro volume](https://hackerpublicradio.org/eps/hpr2651/index.html#comment_2515)
+- [2018-10 TTS over intro music](https://hackerpublicradio.org/eps/hpr2651/index.html#comment_2517)
+- [2016-02 speech synthesis during intro](https://lists.hackerpublicradio.com/pipermail/hpr/2016-February/002881.html)
+- [2015-12 How to check if the intro and outro are added](https://lists.hackerpublicradio.com/pipermail/hpr/2015-December/002795.html)
+- [2015-02 Intro and Outro](https://lists.hackerpublicradio.com/pipermail/hpr/2015-February/002515.html)
+- [2014-12 Outro Theme](https://lists.hackerpublicradio.com/pipermail/hpr/2014-December/002410.html)
+- [2014-12 Bug Fix HPR Intros](https://lists.hackerpublicradio.com/pipermail/hpr/2014-December/002399.html)
+- [2014-11 MaryTTS, clipping](https://hackerpublicradio.org/eps/hpr1642/index.html#comment_991)
+- [2014-11 An HPR Theme Question, And First Time Member](https://lists.hackerpublicradio.com/pipermail/hpr/2014-November/002312.html)
+- [2014-02 What's the word on intro and outro clips?]()https://lists.hackerpublicradio.com/pipermail/hpr/2014-September/002266.html
+- [2011-09 HPR Theme](https://lists.hackerpublicradio.com/pipermail/hpr/2011-September/000455.html)
+- [2009-06 my eps for HPR and intro](https://lists.hackerpublicradio.com/pipermail/hpr/2009-June/000084.html)

ccdn/README.md

@@ -1,13 +1,12 @@
 # Community Content Delivery Network (CCDN)
 
-A location to track the deployment of the HPR Community Content Delivery Network, that provides a mirror network for our content.
+_A location to track the deployment of the HPR Community Content Delivery Network, that provides a mirror network for our content._
 
+## Availability of HPR Content
 
- Availability of HPR Content
+The HPR site has traditionally been run on a single instance which makes the project vulnerable. 
 
-The HPR site has been traditionally been run on a single instance, which makes the project vulnerable. 
-
-We have experienced several times where we have suffered from issues resulting from system outages, denial of service attacks, forced decommissioning, or increased costs.
+We have experienced several occasions where we have suffered downtime, resulting from system outages, denial of service attacks, forced decommissioning, or increased costs.
 
 There is a clear need to host the content in multiple geographically distributed networks to increase reliability and redundancy.
 
@@ -15,27 +14,26 @@ Applying a [Content Delivery Network](https://en.wikipedia.org/wiki/Content_deli
 
 These large vendor solutions provide free tiers, but the long term business model shows that these are not sustainable. 
 
-Additionally the algorithms used would flag behavior considered normal for HPR contributors, as suspicious and would deny them access.
+Additionally the algorithms used would flag behavior, considered normal for HPR contributors, as suspicious and would deny them access.
 
-
-# Looking to the past
+## Looking to the past
 
 At the dawn of the Internet, it was common for websites and services like DNS to be [mirrored](https://en.wikipedia.org/wiki/Mirror_site) by friends.  
 
 This was for a long time not a viable option for HPR as the quantity of Audio Content was expensive to host and transfer, and was therefore beyond what a home user could reliably serve.
 
-Over time, in some locations members of our community have access to facilities that a few years ago would have been reserved for Internet Service Providers.
+Over time, and in some locations members of our community have access to facilities that a few years ago would have been reserved for Internet Service Providers.
 
-If you are interested in helping hosting the HPR site and media, then please get in touch with _admin @ hackerpublicradio.org_
+If you are one of the fortunate people, and would like to contribute hosting of a mirror of the HPR site and media, then please get in touch with _admin @ hackerpublicradio.org_
 
 
-## Requirements for Hosting
+### Requirements for Hosting
 
 - 24/7 Home Service
 - fixed IP address
 - unlimited bandwidth
 - fast > 500mb/sec upload
-- large > 1T of storage
+- large > 3T of storage
 - permission from your ISP to run a web server
 - Contact information know to the Janitors
 - Optional: [UPS](https://en.wikipedia.org/wiki/Uninterruptible_power_supply)

developer_information.md

@@ -36,7 +36,7 @@ That said, we move with the times when there is a clear advantage to do so.
 
 We run up to date patched stable software.
 
-We have a long tradition of supporting and sharing hacker culture. Any identified vulnerability are fixed with credit if requested.
+We have a long tradition of supporting and sharing hacker culture. Any identified vulnerabilities are fixed with credit if requested.
 
 We use [RSS](https://www.rssboard.org/rss-specification) as a delivery mechanism, which is by default fault tolerant.
 
@@ -46,7 +46,7 @@ All our code is on [GitTea](https://repo.anhonesthost.net/HPR), please clone loc
 
 [Our database](https://hackerpublicradio.org/hpr.sql) is updated frequently, please copy locally.
 
-Our media is served from our [Community Content Delivery Network (CCDN)](https://repo.anhonesthost.net/HPR/hpr_documentation/ccdn/)
+Our media is served from our [Community Content Delivery Network (CCDN)](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/ccdn/README.md).
 
 Bug reports, and patches are welcome from anyone without commitment.
 
@@ -61,5 +61,5 @@ In order to contribute you need to [create an account](https://repo.anhonesthost
 Once you have set up your account, you will need to set up your local
 development environment. [Instructions here](set-up-development-environment.md)
 
-Changes can be submittted as described in [hpr3797 :: How to submit changes to HPR](https://hackerpublicradio.org/eps/hpr3797/index.html).
+Changes can be submitted as described in [hpr3797 :: How to submit changes to HPR](https://hackerpublicradio.org/eps/hpr3797/index.html).
 

images/Novecento-Font/Fonts Empire.txt

@@ -1,13 +0,0 @@
-Download this font and many other at "https://fontsempire.com/"
-
-"Fonts Empire " Features an amazing collection of free fonts,
-premium fonts and free dingbats. You've come to the best place to download fonts! 
-
-Some fonts provided are trial versions of the full versions and may not allow embedding, 
-Unless a commercial license is purchased or may contain a limited character set. 
-Please review any files included with your download, 
-Which will usually include information on the usage and licenses of the fonts. 
-If no information is provided, 
-Please use at your own discretion or contact the author directly. 
-
-Note: Must mentioned (Fontsempire.com) as a providor of this font if you use it commercially.

podcatchers/README.md

@@ -22,9 +22,9 @@ The following are some of the clients, and we request that people help out repor
 - [Podchaser](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/podcatchers/Podchaser)
 - [Podtail](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/podcatchers/Podtail)
 - [Radio.net](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/podcatchers/RadioNet)
+- [Sonos](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/podcatchers/Sonos)
 - [Spotify](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/podcatchers/Spotify)
 - [stagefright](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/podcatchers/stagefright)
 - [Top Podcast](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/podcatchers/TopPodcast)
 
-
 See Wikipedia for a [list of podcast clients](https://en.wikipedia.org/wiki/List_of_podcast_clients).

podcatchers/Sonos/README.md

@@ -0,0 +1,25 @@
+# Sonos
+
+<a href="https://upload.wikimedia.org/wikipedia/commons/a/a8/Sonos_Logo.jpg" >
+  <img width="200" src="https://upload.wikimedia.org/wikipedia/commons/a/a8/Sonos_Logo.jpg" alt="Sonos logo" />
+</a>
+
+<!--
+- Confirmed working with HPR Feeds and [CCDN](https://repo.anhonesthost.net/HPR/hpr_documentation/wiki/Community-Content-Delivery-Network)
+- [Source Code on GitHub](https://gpodder.github.io/)
+-->
+## Description
+
+![Sonos UI](podcatcher_Sonos.png "A screenshot of the Sonos UI")
+
+```
+
+```
+## How to install
+
+
+## Subcribing to HPR
+
+
+## Playback
+

policies.md

@@ -0,0 +1,146 @@
+# Policies
+
+## Did you notice Harm ?
+
+"Therefore if there are any shows that are on the site which you feel [harm HPR](https://lists.hackerpublicradio.com/pipermail/hpr/2022-June/004492.html), first see if a [response episode](https://lists.hackerpublicradio.com/pipermail/hpr/2021-September/004250.html) is sufficient to address the grievance. If not then please bring it to the attention of the janitors at hpr, and we will see if the concerns are grounded based on the same criteria as if the show was been posted today."
+
+## We don't tolerate Harassment, Trolling
+
+Hacker Public Radio is dedicated to sharing knowledge in a welcoming community that offers positive feedback and encourages respectful debate.
+
+[Harassment on HPR](https://lists.hackerpublicradio.com/pipermail/hpr/2019-December/003804.html)
+
+## Free speech and general conduct
+
+We place trust in the people of the community to do the right thing. 
+It is always first and foremost the responsibility of the host themselves to think how their words would impact on others in the community. 
+
+If you are thinking about adding an explicit tag, means you should add the tag.
+
+While [Swearing](https://lists.hackerpublicradio.com/pipermail/hpr/2012-April/000640.html) is allowed, remember JWP's Granny is listening.
+If you do, then always use the explicit tag, and don't go out of your way to be belligerent.
+
+We follow the principle that inside the shows, free speech applies. 
+As with [Shouting_fire_in_a_crowded_theater](https://en.wikipedia.org/wiki/Shouting_fire_in_a_crowded_theater), but there are exceptions. 
+We do not post hate speech, copyright music, etc.
+
+If you think it's going to be excessive then, please put a warning at the beginning of the show.
+Something like - "Sorry I went off on a bit of a rant in this one, 
+so if you're listening to this in a public place it might be best to put in headphones or listen later". 
+If there are complaints we have [policies](https://repo.anhonesthost.net/HPR/hpr_documentation/src/branch/main/policies.md) to deal with it. 
+
+Outside the podcast audio, eg shownotes, tags, feeds etc we still expect the host to do the right thing.
+In cases where they don't the janitors can and do intervene.
+We follow the [Parental Advisory](https://en.wikipedia.org/wiki/Parental_Advisory) approach, 
+akin to the covers on the cd's in the shops.
+Listen to "[hpr2210 :: On Freedom of Speech and Censorship](https://hackerpublicradio.org/eps/hpr2210/index.html)" for more information.
+There is no point in having a warning on the intro of the show if the shownotes, title,
+and text to speech intro already contain the offending phrases. 
+
+This of course extends to anywhere where we have an "official HPR" presence, chatrooms, mastodon, email, conferences etc
+
+The policy is that within your own show the freedom of expression is upheld.
+
+## Schedule Guidelines
+
+You must have your show recorded before you reserve a slot.
+
+You must only post a show every two weeks.
+
+[Changes to scheduling guidelines](https://lists.hackerpublicradio.com/pipermail/hpr/2025-September/004922.html)
+
+## Community News
+
+The Community News presenters may exercise discretion in what they read out and refer the audience to the skipped content.
+
+[HPR Community News Comment Summaries](https://lists.hackerpublicradio.com/pipermail/hpr/2025-July/004873.html)
+
+## Janitors
+
+They are the people who work in the background to make sure the shows come out every day.
+
+## Auditors
+
+The Auditors role is to observe and report if necessary that the Janitors are been faithful in their communication.
+
+[Auditors on HPR](https://lists.hackerpublicradio.com/pipermail/hpr/2025-September/004908.html)
+
+[Permission to move out a show](https://lists.hackerpublicradio.com/pipermail/hpr/2022-March/004419.html)
+
+## Permission to move out a show
+
+[Permission to move out a show](https://lists.hackerpublicradio.com/pipermail/hpr/2022-March/004410.html)
+
+Janitors can move shows on host permission as normal, but will always ask the mail list where the host cannot or will not move their show.
+
+[The janitors](https://hackerpublicradio.org/eps/hpr4566/index.html#comment_4594) *really* do not like to move shows around once they are posted.
+
+Before a show is posted, it's ID is more or less the key you get when you upload, once it's posted the unique id is the hpr episode number.
+
+Moving the primary key leads to a mess with the synchronization of files between the HPR site, the Internet Archive, and the HPR CCDN.
+
+We've had to do it in the past, so I'm again speaking from experience. 
+We moved a show from a host which happened to be part 2 and it would have gotten aired before the part 1. 
+This meant we had 4 shows to move. 
+So we will never move a show without getting permission from the Host, and if they do not get back to us, or we feel that it's important enough, the mail list.
+
+Moving shows breaks some RSS readers that *only* look at the enclosure/@url element. If that remains the same, then they have no reason to download it again. So anyone who has already downloaded *any* of the moved shows will not download them again. Which basically breaks the future feed entirely.
+
+Moving a show can easily spiral into a lot of work. We will and have done it on occasion, but if it's urgent enough, you should reserve a slot.
+
+## HPR is not a podcast platform
+
+[Is HPR a podcast or podcast hosting platform ?](https://lists.hackerpublicradio.com/pipermail/hpr/2022-August/004615.html)
+
+There seems to be a clear desire to keep HPR as a podcast and not transition to a podcast hosting platform. What I came to realize was that the HPR setup could be adapted to become a podcast hosting platform with minor changes. For example, were we to not release the main feed, remove the HPR branding, and provide each show their own schedule, then each hosted podcast (now HPR series) would be their own entity. However it's not something that the community, janitors, or the HPR patrons are enthusiastic about implementing.
+
+## Not everything that "could be of interest to hackers" is allowed.
+
+[Rejecting a show on the grounds that it is "using HPR as a means to push a particular product or view"](https://lists.hackerpublicradio.com/pipermail/hpr/2025-July/004883.html)
+
+
+## We promote other Creative Commons Works
+
+On dropping the Non Commercial License: [HPR: RFC Changing show to CC-BY-SA](https://lists.hackerpublicradio.com/pipermail/hpr/2011-June/000384.html)
+
+Supporting [Various Creative Commons Works](https://lists.hackerpublicradio.com/pipermail/hpr/2013-April/001216.html), that allows people to to submit (a single) interesting/important creative commons works on a given topic to the queue. It should be prefixed with a short introduction as to why we should be interested, then submit it under your own name to the queue. 
+
+### [Policy Change: removal of non free CC-BY-NC license](https://lists.hackerpublicradio.com/pipermail/hpr/2025-March/004853.html)
+
+### [Policy Change: Clarification that contributions are CC BY-SA 4.0 unless otherwise stated](https://lists.hackerpublicradio.com/pipermail/hpr/2024-October/004791.html)
+
+### [Policy Change: Should we reject a show with copyrighted fair use clips in it ?](https://lists.hackerpublicradio.com/pipermail/hpr/2019-May/003673.html)
+
+- From [Kevin O'Brien](https://lists.hackerpublicradio.com/pipermail/hpr/2019-May/003683.html): "Fair Use is not, in the U.S., a right recognized by any statute. It is best understood as "the right to hire a lawyer"."
+- From [stankdawg](https://lists.hackerpublicradio.com/pipermail/hpr/2019-May/003692.html): "Sorry. Not worth the risk. I appreciate the contribution and do not want to discourage the submissions.  But it is too dangerous.  And for the record... no one else can voluntarily accept responsibility. It falls back to me as site owner no matter what."
+- From [Ken Fallon](https://lists.hackerpublicradio.com/pipermail/hpr/2019-May/003695.html): Remember that our policy is also a commitment to anyone using our feed. I know there are downstream projects like college radio, workplaces, shops etc that are using our feed. They would not need to buy a public music license, for feeds [that] contains *only* Creative Commons content.
+
+## Search Page
+
+[Boo, Hiss, a google search on top of the HPR webpage!](https://lists.hackerpublicradio.com/pipermail/hpr/2013-March/001145.html)
+
+Why we do search like we do.
+
+## Site Security stays with the Site admin
+
+[Implemented a deny list on HPR](https://lists.hackerpublicradio.com/pipermail/hpr/2013-March/001112.html)
+
+Attacks to our site get blocked, no discussion required.
+
+## Avoiding background music
+
+[Bed Music](https://lists.hackerpublicradio.com/pipermail/hpr/2012-November/000877.html)
+
+It can be distracting so avoid if possible.
+
+## What is a Syndicated show ?
+
+[Syndicated shows](https://lists.hackerpublicradio.com/pipermail/hpr/2011-January/000214.html)
+
+If a show is posted elsewhere prior to been posted to HPR then it would be considered to be a syndicated show.
+
+## When to wind down HPR
+
+[HPR RIP ?](https://lists.hackerpublicradio.com/pipermail/hpr/2010-September/000109.html)
+
+After a period of intermittent posting, the community decided to continue posting HPR shows.

queue.md

@@ -0,0 +1,837 @@
+# The Queue
+
+The queue is necessary as "Hacker Public Radio ... releases shows every weekday Monday to Friday."
+
+## Why release like this ?
+
+Back in 2010, shows were getting released on an ad hoc basis. 
+Some days there were as many as two or even three shows released per day. 
+More often than not though, there was no show at all. 
+As time went on the period between no shows increased. 
+After a time it was unclear if HPR was alive. 
+This was reflected in a steady decline of subscribers.
+
+One of the policies that we decided on was that "one show a day - every day, builds trust and retains listeners." 
+This has turned out to be true based on the steadily increasing subscriber base, and since then lots of research has been done that supports it. 
+
+- [youtube: "A consistent, sustainable release schedule is critical when building and fulfilling audience expectations...."](https://support.google.com/youtube/answer/13616979)
+- [spotify: "When podcasters don't stick to a steady schedule, it can be the first sign of podfading, when a show becomes less and less regular until it eventually disappears."](https://podcasters.spotify.com/resources/learn/create/podcast-schedule)
+
+Should it matter ? No. 
+
+Does it matter ? Yes.
+
+For those that prefer to have the shows as soon as they are posted, we also have a [Future Feed](https://hackerpublicradio.org/rss-future.php).
+
+## Scheduling 
+
+> HPR can only control the release rate (fixed at 5 shows a week), and has no control over the rate at which shows are submitted.
+
+Sometimes there are very few shows in the queue resulting in problems for the admins in getting shows to air.
+
+Other times there are a lot of shows in the queue resulting in hosts waiting a long time for their show to air.
+
+Despite the problems we haven't missed a day since 2010-09-21, and sometimes that is the only thing that keeps the Janitors going.
+
+![](images/rate-limiting.David_Turner.CC-BY-SA_4.0.png)
+
+Copyright © David Turner<br>This work is licensed under a 
+<a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.
+
+## History of scheduling on HPR
+
+Over the years we tried various different methods to ensure one show every weekday Monday to Friday. 
+
+<ul>
+<li>To begin with hosts signed up for a particular day based on a published [calendar](https://lists.hackerpublicradio.com/pipermail/hpr/2008-January/000000.html).</li>
+  <ul>
+  <li>This failed as hosts could not meet the scheduled time, or found the pressure too much.</li>
+  </ul>
+</li>
+<li>Then shows were released that were available on the FTP server.
+  <ul>
+  <li>This lead to arguments as there appeared to be no order to the when the shows were posted.</li>
+  </ul>
+</li>
+<li>Then we switched to a first come first out method. 
+  <ul>
+  <li>This lead to having too many shows from the one host or on one topic, where a hosts posted a series of shows at the one time.</li>
+  <li>This also lead to arguments about time critical shows been left too late.</li>
+  </ul>
+</li>
+<li>Then we went through several mechanisms of rules, first in first out, except for new hosts, interviews, etc, etc.
+  <ul>
+  <li>Needed to be updated too frequently</li>
+  <li>It was not clear what the rules were, and shows came out in a seemingly in random order.</li>
+  <li>The Janitors were been accused of favouring other peoples shows</li>
+  </ul>
+</li>
+<li>Pick a slot from a schedule where the hosts themselves got to pick a slot
+  <ul>
+  <li>Works well but can lead to <a href="https://en.wikipedia.org/wiki/Mechanical_equilibrium">unstable equilibrium</a> between supply and delivery.</li>
+  </ul>
+</li>
+<li>Current: Schedule with free slots been filled from a reserve pool.
+  <ul>
+  <li></li>
+  </ul>
+</li>
+</ul>
+
+## Scheduling Rules
+
+<ol>
+  <li>You must have your audio recording ready to upload <strong>before</strong> you pick a slot.</li>
+  <li>All hosts must leave at least 9 slots (approximately two weeks) between their shows.</li>
+  <li>New hosts, Interviews, and other time critical shows should use the first free slot. 
+  Otherwise, when the queue is filling up then leave some slots free for new contributors by selecting a slot in the first empty week.</li>
+</ol>
+
+</p>
+
+We have a <a href="https://repo.anhonesthost.net/HPR/hpr_documentation/raw/branch/main/workflow/SchedulingGuidlinesFlowChart.odg">flow diagram</a> if that helps.
+
+
+---
+
+# Updated version of [hpr4195 :: Hacking HPR Hosts](https://hackerpublicradio.org/eps/hpr4195/index.html)
+
+
+> Social Engineering more contributions to HPR by picking when to publish your show
+
+Hosted by Ken Fallon on Friday, 2024-08-30 is flagged as Clean and is released under a CC-BY-SA license.
+
+Tags: HPR, Queue, Scheduling, Buffering.
+
+## There’s no Business like …
+
+While we may be "dedicated to sharing knowledge", we are competing for the time and attention of our Audience. 
+Therefore we are in the Entertainment Business.
+
+The clue is in this statement from the about page.
+
+<blockquote>
+Hacker Public Radio (HPR) is an Internet Radio show (podcast) that releases shows every weekday Monday through Friday.
+</blockquote>
+
+Let’s compare that to others.
+
+Any event promoter needs to provide the Who, What, Where, and When, to their potential audience.
+
+<ul>
+<li>U2, UV Achtung Baby Live playing the Las Vegas Sphere, from 23 to the 30 June 2024.</li>
+<li>Richard III in the Globe Theatre, All Summer. (The resident players is implied)</li>
+<li>BBC News at Ten. (The what and when are in the name, BBC News Team is implied, as is Daily)</li>
+<li>Season 2 of Firefly, returns to Netflix in the Fall.</li>
+</ul>
+
+A theater will have an address and a schedule for when the events occur. 
+On TV and radio they have predefined channel locations, and often have 24x7 schedule of programs.
+
+For Hacker Public Radio (HPR) our "venue" or channel is our RSS Feed, and our schedule is a show every weekday Monday through Friday.
+
+A podcast production enterprise, like the NPR, BBC, etc have permanent staff who’s day job is to come in and create content. 
+Other approaches used by Netflix, or Disney+, etc is to commission external parties to record unique content. 
+They might also just purchase in shows. 
+Regardless of the approach, they all have a mechanism to meet the production schedule.
+
+Unlike other podcasters, HPR has no control of our supply chain. 
+We do still have a contract to deliver one "product" a day Monday to Friday, 
+but we also have no control over our distribution channels.
+
+I think it’s important to understand just how much energy goes into managing this balancing act.
+
+It’s the absolute <strong>core</strong> of the project, and is what takes up most of our time and energy.
+
+# Feeding the Queue
+
+We have to feed the queue.
+
+## Control of our supply chain
+
+<blockquote>
+A supply chain, .. is a complex logistics system that consists of facilities that convert raw materials into finished products 
+and distribute them to end consumers or end customers. 
+Meanwhile, supply chain management deals with the flow of goods within the supply chain in the most efficient manner. 
+</blockquote>
+<a href="https://en.wikipedia.org/wiki/Supply_chain">From Wikipedia, the free encyclopedia</a>
+
+Our supply chain is entirely dictated by the generous hosts who donate their time to recording a show. 
+Therefore the Janitors have no control over when shows are sent in. 
+As Janitors, we can only contact the community to remind them to send in shows.
+
+We need your help to manage this.
+
+### Boom/Bust Supply
+
+![Diagram of a ball placed in an unstable equilibrium](images/Diagram_of_a_ball_placed_in_an_unstable_equilibrium.OrdinaryArtery.CC-BY-SA_4.0.png)
+
+<a href="https://commons.wikimedia.org/wiki/File:Diagram_of_a_ball_placed_in_an_unstable_equilibrium.svg">OrdinaryArtery</a>, 
+<a href="https://creativecommons.org/licenses/by-sa/4.0">CC BY-SA 4.0</a>, via Wikimedia Commons
+
+
+Usually there is a burst of contributions after a "Call for Shows",
+which is itself as a result of a lull in the amount of contributions.
+This leads to boom and bust/saw tooth delivery of shows. 
+There is a painful behaviour that the Janitors observe after a "Call for Shows".
+
+<ul>
+<li>There is a burst of contributions all taking the first available slots.</li>
+<li>The queue quickly fills up the upcoming weeks.</li>
+<li>It takes time for the "Call for Shows" to get to everyone.</li>
+<li>A potential host is late hearing the "Call for Shows" and sees a full queue, resulting in them not submitting a show.</li>
+<li>Worse is that it instills the feeling of HPR "<a href="https://en.wikipedia.org/wiki/The_Boy_Who_Cried_Wolf">Crying Wolf</a>", 
+incorrectly assuming the subsequent "Call for Shows" can safely be ignored.</li>
+<li>After a few weeks our queue is empty and we need to put out another "Call for Shows", which that host ignores.</li>
+</ul>
+
+The timely delivery of shows is an inherent challenge with volunteer contributions. 
+Fortunately this is a well understood problem known as <a href="https://en.wikipedia.org/wiki/Queueing_theory">Queueing theory</a>, 
+and we have implemented the <a href="https://hackerpublicradio.org/contribute.html#schedule_reserve_pool">Reserve Pool</a>,
+as a means to regulate/<a href="https://en.wikipedia.org/wiki/Data_buffer">buffer</a> the incoming delivery with outgoing supply.
+
+<blockquote>
+The reserve queue is intended only to be used in the cases where there is still a gap in the schedule one week prior to release. 
+This was known as the emergency queue, but now can also be used when the hosts don’t care when the shows are scheduled. 
+They will be used on a first in first out basis, when there is no conflict with the scheduling guidelines. 
+These shows contain a message alerting listeners to the fact that we had free slots that were not filled.
+</blockquote>
+
+### Scheduling Rules
+
+When you are contributing a show, you decide when to post your show.
+The choice of slot may even encourage others to submit a show themselves.
+
+Our observations show that there is a <a href="https://en.wikipedia.org/wiki/Goldilocks_principle">Goldilock Zone</a>
+where there are just the right amount of free slots to encourage contributions.
+
+#### Too Many free slots
+
+When there are too many free slots some people get disheartened and don’t want to contribute to a dying project.
+
+On the other hand too many free slots can send regular hosts into a panic to fill them. 
+We all suffer from this, and it can lead to burnout.
+
+Fortunately we now have the <a href="https://hackerpublicradio.org/contribute.html#schedule_reserve_pool">Reserve Pool</a>, 
+where they janitors can post their backup shows when they are needed.
+
+The idea that some shows are sub par because they are rushed in to fill free slots can now be put to rest. 
+All the shows in the <a href="https://hackerpublicradio.org/contribute.html#schedule_reserve_pool">Reserve Pool</a>
+are there because the Host did not feel the need to rush the shows out.
+
+#### Too many free slots
+
+On the other hand seeing too many free slots some people get disheartened that their show won’t be aired for weeks,
+so end up not recording a show in the first place.
+
+####  Hacking Human Behaviour
+
+So the HPR Community can influence the supply chain by been smart about how we schedule the shows.
+
+When you upload consider the <a href="https://hackerpublicradio.org/contribute.html#scheduling_rules">Scheduling Rules</a> when picking your slot.
+
+This way <strong>your</strong> (person reading this) actions, 
+give the HPR Community complete control over the supply of shows in a general sense.
+
+Remember the HPR Community have not missed a day since September 2009.
+
+# Distribution Channels
+
+Getting our podcast distributed is no problem what so ever.
+
+While NPR, BBC, Netflix, Disney+, etc can afford to record unique content, unique content is very, very expensive. 
+Amazon, Apple and Spotify may have the resources to do this, 
+but they and others, make use of the freely available content to inflate their inventory of content.
+
+We provide these platforms with our feed and our blessing. So long as they adhere to the
+<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) License</a>. 
+Our prime directive at work.
+
+We publish a RSS feed, and that feed is then picked up by others such as
+<a href="https://archive.org/details/hackerpublicradio">Archive.org</a>,
+<a href="https://music.amazon.fr/podcasts/9d9e6211-ff78-4501-93b6-6a9e560c4dbd/hacker-public-radio">Amazon Music</a>,
+<a href="https://podcasts.google.com/feed/aHR0cDovL2hhY2tlcnB1YmxpY3JhZGlvLm9yZy9ocHJfcnNzLnBocA">Google Podcasts</a>,
+<a href="https://www.iheart.com/podcast/256-hacker-public-radio-30994513/" target="_blank">iHeart Radio</a>,
+<a href="https://podcasts.apple.com/us/podcast/hacker-public-radio/id281699640">iTunes</a>,
+<a href="https://www.listennotes.com/de/podcasts/hacker-public-radio-hacker-public-radio-mNH-jsI7LcJ/">Listen Notes</a>,
+<a href="https://www.mixcloud.com/hackerpublicradio/">MixCloud</a>,
+<a href="https://player.fm/series/hacker-public-radio">PlayerFM</a>,
+<a href="https://www.podchaser.com/podcasts/hacker-public-radio-76781">Podchaser</a>,
+<a href="https://nl.radio.net/podcast/hacker-public-radio">Radio.net</a>,
+<a href="https://open.spotify.com/show/7e2hYcnHj9vKgUzsIOf4r3">Spotify</a>,
+<a href="https://toppodcast.com/podcast_feeds/hacker-public-radio/">Top Podcasts</a> and now for some reason
+<a href="https://www.imdb.com/title/tt30528560">IMDB</a>.
+
+We have no control over what they do with the feed, how often the use it, if they cache it, if they use the images from it, if the show the
+explicit tag, or as in this case, if they <a href="https://repo.anhonesthost.net/HPR/hpr_hub/issues/11">display the host</a> or not.
+
+That’s why you can help by taking up the mop and becoming the Janitor for your Distribution Channel.
+
+---
+
+# Mail list Discussions on the topic
+
+On 8/28/21 08:12, e8hffff wrote:
+> It's painful to only have one show a week day, and that's double pain if only
+> a short podcast.  I regularly start the day off with listening to podcasts but
+> recently I unsubscribed from a bigger creator (Jupiter Broadcasting) for
+> dishing on freedom fighters of COVID lockdowns, so, I'm now lucky to have one
+> show pop up a day to listen to.  Not enough.  I can't see why HPR is
+> restricting the flow of information. It's crazy.  People can limit themselves
+> if they find they are overwhelmed.
+>
+> Cheers e8hffff.
+
+
+From ken at fallon.ie  Sun Aug 29 07:22:20 2021
+From: ken at fallon.ie (Ken Fallon)
+Date: Sun, 29 Aug 2021 09:22:20 +0200
+Subject: [Hpr] Hpr Digest, Vol 155, Issue 8
+In-Reply-To: <14821733.4WXcVoXQB2@masterhost>
+References: <mailman.1.1630159417.109199.hpr_hackerpublicradio.org@hackerpublicradio.org>
+ <14821733.4WXcVoXQB2@masterhost>
+Message-ID: <503ee371-44a0-6d76-b999-ca0aaa62464d@fallon.ie>
+
+Hi e8hffff,
+
+I'm the Janitor in question let me reply. First thanks for posting this 
+to the mail list. As I said in the show the Janitors do not decide HPR 
+policy, this mail list does[1].
+
+ > It's painful to only have one show a week day, and that's double pain 
+if only a short podcast.
+
+You point is a valid one, and is often brought up for discussion. The 
+most recent was April of this year, which was triggered by an article by 
+hedorah[2]. Have a read of that discussion and pop back here with your 
+thoughts.
+
+To address that point, we have long had the option to ignore the 
+dictates of the evil Janitors ;-) Just go to "Get Shows > Advanced 
+Settings[2]" and you can get the shows as soon as they are posted. 
+Remember that if a show is posted incorrectly and we need to repost it, 
+you will probably miss the new release. But no harm to have another pair 
+of ears checking the future freed for us.
+
+Don't forget we have 3996 older shows ready right now. That's 76 days 12 
+hours 3 minutes 31 seconds right there. Assuming you listen for 12 hours 
+a day you are covered until Saturday, 29 January 2022. By which time 
+there will be another 110 shows for you.
+
+You can also help out by adding tags[4] and updating the shownotes for 
+those shows.
+
+It's great to see you are intending to contribute some shows. If you run 
+into any issues please get in touch. Any tips on the process from a new 
+contributor is great as we are always trying to make it easier to post 
+shows.
+
+[1] http://hackerpublicradio.org/about.php#governance
+[2] http://hackerpublicradio.org/advanced_rss_settings.php
+[3] http://hackerpublicradio.org/syndication.php
+[4] http://hackerpublicradio.org/report_missing_tags.php
+
+-- 
+Regards,
+
+Ken Fallon (G5KEN)
+http://kenfallon.com
+http://hackerpublicradio.org/correspondents.php?hostid=30
+
+
+From ken at fallon.ie  Sat Jan 20 21:25:54 2024
+From: ken at fallon.ie (Ken Fallon)
+Date: Sat, 20 Jan 2024 22:25:54 +0100
+Subject: [Hpr] Happy new year - should we continue with HPR ?
+In-Reply-To: <d4199b4c-ace4-46f4-a653-60dba980c147@jezra.net>
+References: <c10b8e8c-4d86-4bdc-b847-88b5c5889c21@fallon.ie>
+ <d4199b4c-ace4-46f4-a653-60dba980c147@jezra.net>
+Message-ID: <feb17d42-9f85-4783-a196-278b976aa88d@fallon.ie>
+
+Hi All,
+
+The reason lostnbronx did the show "hpr0560 :: Old soldiers", was 
+because HPR was releasing shows on an ad hoc unpredictable schedule. 
+People were unsubscribing, other podcasts were asking if HPR had 
+finished or not. In fact that was the first time I asked is HPR RIP 
+<https://lists.hackerpublicradio.com/pipermail/hpr/2010-September/000109.html> 
+?
+
+My feeling has always been that a consistent release schedule builds 
+trust in podcasts. Since then lots of research has been done that 
+supports it. Eg: youtube 
+<https://support.google.com/youtube/answer/13616979> "A consistent, 
+sustainable release schedule is critical when building and fulfilling 
+audience expectations...." , spotify 
+<https://podcasters.spotify.com/resources/learn/create/podcast-schedule> 
+"When podcasters don't stick to a steady schedule, it can be the first 
+sign of podfading, when a show becomes less and less regular until it 
+eventually disappears." Should it matter ? No. Does it matter ? Yes.
+
+In the case of HPR, we release "New episodes every weekday Monday 
+through Friday". You might have no clue who the host will be, what it's 
+going to be about, if it's going to have potty language in it or not, 
+but you *do* know that "you can tune in tomorrow for another exciting 
+episode". We haven't missed a day since 2010-09-21 and sometimes that is 
+the only thing that keeps the Janitors going.
+
+We have 427 hosts and 240 slots, so one show a year is more than enough 
+to handle the schedule. Going to fewer release days would not address 
+the problem of getting shows in the first place, it just prolongs the 
+inevitable. So no my personal feeling is that we should not release less 
+shows when the queue is low, nor should we release more shows when the 
+queue is full, which as has also been suggested. That said if the 
+consensus is that that should be changed then this is the place to 
+discuss it.
+
+For now the compact with the Janitors is simple, "You keep sending in 
+shows and we'll keep posting them. When there are no more shows we'll 
+close down HPR with dignity." Hopefully that won't be for ages yet but 
+it's up to you all to decide. So if you want your say Vote Early 
+<https://hub.hackerpublicradio.org/calendar.php> and Vote Often 
+<https://hub.hackerpublicradio.org/request.php?id=9999>. (There is no 
+time limit on the voting either ;-) )
+
+-- 
+Regards,
+
+
+
+From gort.klaatu at gmail.com  Mon Sep 13 13:15:09 2010
+From: gort.klaatu at gmail.com (Klaatu)
+Date: Mon, 13 Sep 2010 09:15:09 -0400
+Subject: [Hpr] HPR RIP ?
+In-Reply-To: <AANLkTi=YB-b8B1bD2boEwPZaKXxgBbOVYEqV50Cwgcb8@mail.gmail.com>
+References: <AANLkTi=4YhEXjM3MxP=ufkgwWqqf0iGB=Nc+PF2R6eyG@mail.gmail.com>
+	<AANLkTi=YB-b8B1bD2boEwPZaKXxgBbOVYEqV50Cwgcb8@mail.gmail.com>
+Message-ID: <AANLkTik9aKriHZN7ZfaBsU6SGRHV_k2_-2PFmx5JVJat@mail.gmail.com>
+
+Well, just got back from Ohio Linux Fest, where we had a wildly successful
+Hacker Public Radio panel, with SigFLUP, Dave Yates, Dann from TLLTS, and
+Lord_Drachenblut as panelists.  People were into it, excited about it, and
+those who had never heard of it were really excited about the idea of a
+community show.
+
+I believe HPR is actually a lot healthier than you think it is.  i can't
+access the FTP server (my IP address gets blocked frequently, apparently due
+to an evil automagic iptable rule?) but if I could, I'd tell you exactly how
+many episodes were sitting there waiting to be posted.  I know for a fact
+that I have at least 9 (probably a low estimate) SELF interviews that have
+been sitting there for 3 months.  SigFLUP's field trip (ep 567 i think?) had
+been sitting for a month before posted.  Insert other examples here.
+
+I think what really 'needs' to happen is that the shows that exist need to
+be posted.
+
+So...the way I see it, either:
+
+1. Someone who is not going to be blocked needs to log in and post episodes.
+2. The posting process needs to be semi-automated or greatly simplified
+3. I need ssh access or to get at least one ip address that I would log in
+from NOT blocked.
+
+And then HPR would start looking a lot healthier.
+
+On Sun, Sep 12, 2010 at 5:50 PM, Arron Finnon <afinnon at gmail.com> wrote:
+
+> Howdie Guys,
+>
+> Late to the party on this thread but hell.  I'm in the middle of
+> trying to set up a week long series on HPR with a live show at the
+> end, just trying to draw some people in.
+>
+> TBH my whole issue is always about releases.  I have stuff backed up
+> in there for last years SFD (this years is on Saturday)
+>
+> I have to be honest and say that IMHO is what holds us back, lots of
+> great content not knowing if/when is a pain.  My suggestion not matter
+> how crazy it sounds is to let hosts push their own shows out on HPR at
+> a rate they are happy with.  Yeah some days HPR fans are going to have
+> a bumper day, and some days its going to be quite as hell.  I'm not
+> saying there isn't any creases to iron out with this idea, but put it
+> this way if you've done over 5 shows surely your trusted enough to
+> push a show out when ever, or dare i say dust down the calendar and
+> bring it back.
+>
+> My 2 Cents, and you bet your ass you've been over charged
+>
+> Finux
+>
+> p.s just realized chaining from googlemail.com to gmail.com is not so
+> cool for mailman
+>
+> _______________________________________________
+> Hpr mailing list
+> Hpr at hackerpublicradio.org
+> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
+>
+
+
+
+From ken.fallon at gmail.com  Thu Sep 22 05:49:14 2011
+From: ken.fallon at gmail.com (Ken Fallon)
+Date: Thu, 22 Sep 2011 07:49:14 +0200
+Subject: [Hpr] Scheduling the same host or series in one week
+In-Reply-To: <4E7A20CF.9020204@osource.org>
+References: <CAK-oqQb+xiMzSk_Q7zE=sevTkLvwZnAn38jDTPUqjt9y9dHU7g@mail.gmail.com>
+	<CAKyPAbPw3CYV3aNPLca3+kR7imyYu1yK=omrZxqwAfPa1d+muQ@mail.gmail.com>
+	<4E7A20CF.9020204@osource.org>
+Message-ID: <CAK-oqQa7NUDV1AvgEZ3ziEW_E9V4PHKJ+HZOEdmYCu-Wy81w2Q@mail.gmail.com>
+
+Thanks everyone for your feedback it is really helping to make the
+scheduling better. I think that the Xorg interviews fall outside this
+discussion as they are regular series and are not time critical. They
+will be released one a week just like klaatu's series that are in the
+queue now. That has the advantage that our listeners get to hear the
+series regularly but not so often that it's the only content for
+several days in a row.
+
+One important point that I neglected to mention in the email (I think
+I covered it a few times on the discussions on the community news
+shows) is that the rules need to be clear, transparent, fair and most
+of all possible to code. The rules as they stand now are:
+
+if release_show_on = today then post else
+if show_scheduled_slot = today then post else
+if host_num_of_episodes = 0 then post else
+for each show time_in_queue
+   if host or series != in_last_5_days then post
+next
+
+
+> On 09/20/2011 01:35 PM, Joshua "lowtek" Burton wrote:
+>>
+>> I think it would be nice to have a quick release of episodes related to
+>> a recent event. ?Especially if it's reviews, reports, etc. ?I think some
+>> interviews may not be as time relevant but some might be.
+
+
+
+
+From ken.fallon at gmail.com  Fri May  4 11:09:56 2012
+From: ken.fallon at gmail.com (Ken Fallon)
+Date: Fri, 4 May 2012 13:09:56 +0200
+Subject: [Hpr] Friday News Show
+In-Reply-To: <4FA38BBE.8010404@gmail.com>
+References: <CAK-oqQaEt0WT4Su+t09Q0HeKCFYAWRHtNnxua3ST0cwzoVZZ0g@mail.gmail.com>
+	<4FA0417F.8030604@zwilnik.com> <4FA38BBE.8010404@gmail.com>
+Message-ID: <CAK-oqQZhbZ-4Whph+sAwCiOJsnPGkgXwSVXvPtZZA0Cw-oLhTw@mail.gmail.com>
+
+Here are the agreed scheduling rules
+1. Time critical (Where the host has requested a show to be posted at
+a particular time or that the show contains newsworthy information.)
+2. Scheduled Slots (Where a host has been assigned a regular day to
+release a show.)
+3. New Hosts (In order to encourage new hosts we will prioritize shows
+submitted from new hosts so they can experience the excitment of
+podcasting.)
+4. HPR Content on a First in First Out basis.
+
+
+
+
+
+
+From ken.fallon at gmail.com  Wed Oct 10 08:39:17 2012
+From: ken.fallon at gmail.com (Ken Fallon)
+Date: Wed, 10 Oct 2012 10:39:17 +0200
+Subject: [Hpr] Vote on removing non HPR shows.
+In-Reply-To: <CAD_dxjUCLgN9Prwi2Ff9O66ck=O_our8E4tKWXrN5Oc+ncBJ1w@mail.gmail.com>
+References: <mailman.1.1349809202.12104.hpr_hackerpublicradio.org@hackerpublicradio.org>
+	<CAD_dxjUCLgN9Prwi2Ff9O66ck=O_our8E4tKWXrN5Oc+ncBJ1w@mail.gmail.com>
+Message-ID: <20121010103917.299288ea@dell>
+
+TOPIC CHANGE from "Re: [Hpr] Hpr Digest, Vol 49, Issue 2"
+
+On Tue, 9 Oct 2012 23:08:39 -0500
+Fifty OneFifty <fiftyonefifty at linuxbasement.com> wrote:
+
+> Ken,
+> 
+> I don't know what to say (though I have made what I thought were
+> humorous comments on other podcasts).  I submitted a full week's
+> worth of content in July (3 original shows and two syndicated I was
+> involved in)  that are still a good two weeks out of showing up on
+> HPR.  I loved all you original stuff from OggCamp, and catching up on
+> everything from last year, but I think we are getting a rep for stale
+> shows you can find elsewhere  (no intended offense to our syndication
+> partners).   Expect a show on my ODroidX (which I am sure many folks
+> are tired of hearing about) AND gv-20 very soon
+> 
+> 5150
+
+Hi 5150,
+
+I appreciate where you are coming from but if you look at the queue
+you'll see that it's made up of shows from what I'd consider HPR
+regulars.
+
+Ahuka will have released 12 shows this year.
+Frank_Bell 7 shows this year
+mrgadgets 4 shows this year (21 last year)
+Seetee 5 shows this year
+sigflup 6 shows this year
+5150 5 shows this year, not counting your appearances on the HPR
+Community news
+
+
+> > The only way to eliminate the queue quicker is to open the flood
+> > gates and let everything out as soon as it comes in. Which would
+> > mean a flood of shows a few times a year.
+> 
+> "Either we release one show a day, five times per week, or we release
+> them all at once?" Can't there be some middle path here?
+
+
+
+
+
+
+From ken.fallon at gmail.com  Wed Oct 10 20:07:59 2012
+From: ken.fallon at gmail.com (Ken Fallon)
+Date: Wed, 10 Oct 2012 22:07:59 +0200
+Subject: [Hpr] Vote on removing non HPR shows.
+In-Reply-To: <8250988.V5dQfOsaul@bunnies>
+References: <mailman.1.1349809202.12104.hpr_hackerpublicradio.org@hackerpublicradio.org>
+	<CAD_dxjUCLgN9Prwi2Ff9O66ck=O_our8E4tKWXrN5Oc+ncBJ1w@mail.gmail.com>
+	<20121010103917.299288ea@dell> <8250988.V5dQfOsaul@bunnies>
+Message-ID: <20121010220759.61c65f8e@dell>
+
+[start personal opinion]
+As a reminder, the reason we started releasing
+non HPR shows was that there was no shows at all to release. The reason
+there were no shows was that we went from one show a day, to a few a
+week to a few a month until our listers (who are our contributers after
+all) began to say "is HPR dead ?". And whatever about contributing to
+an active network, I guarantee you that no one wants to release shows
+to a network that is dead. This is exactly what happened during 2010. -
+see attached.
+
+I believe we also have a responsibility to our listeners to bring them
+one show a day. The history of podcasts will show you that a regular
+schedule builds trust in the network. That trust was hard won back and
+it took a lot of work from a lot of people to get us through 2011 to a
+stage where people are contributing again.
+
+I just went through the queue and commented out the material that was
+not created "solely" for HPR. That brings us down to 9 shows and we need
+49 to get to the end of the year. Sure we are going to get some shows
+from this appeal but that will buy us another month or so. Then I'll be
+back to begging klaatu and Mr. Gadgets for contributions. 
+
+What I want is a steady stream of HPR listeners contributing shows at
+the same rate that we release them. I am open to any and all
+suggestions to promote that.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+From ken.fallon at gmail.com  Thu Oct 11 09:29:12 2012
+From: ken.fallon at gmail.com (Ken Fallon)
+Date: Thu, 11 Oct 2012 11:29:12 +0200
+Subject: [Hpr] Vote on removing non HPR shows.
+In-Reply-To: <op.wlziajsd2031o5@localhost>
+References: <mailman.1.1349809202.12104.hpr_hackerpublicradio.org@hackerpublicradio.org>
+	<CAD_dxjUCLgN9Prwi2Ff9O66ck=O_our8E4tKWXrN5Oc+ncBJ1w@mail.gmail.com>
+	<20121010103917.299288ea@dell> <8250988.V5dQfOsaul@bunnies>
+	<20121010220759.61c65f8e@dell>
+	<CAKAng83GivSY1vTma81fw-fgTtyFnKekK476_Lbs7nmuFrgC_A@mail.gmail.com>
+	<op.wlziajsd2031o5@localhost>
+Message-ID: <20121011112912.4ca105cb@dell>
+
+Speaking as a HPR Admin, we will facilitate whatever the community decides.
+
+The following is Ken's personal opinion and can/should be challenged
+
+---------------------------------------
+Changing the release schedule
+
+As a community member I disagree strongly for the following reasons (in no particular order)
+
+As stated before we have made a commitment to our listeners to release five shows a week. Each time we stick to what we do we cement the idea that HPR is a regular trusted community that stands by what it says.
+
+I already get complaints from people that we produce too many shows (See Fab's OggCamp interview). We are already telling people to delete the show not the feed. To make that easier for people, hosts will soon be asked to fill in a short summary of their show. That will be automatically converted from text to speech and added to the front of every episode.
+
+It doesn't fix the problem of people not wanting to hear recycled material on the HPR feed.
+
+Two additional shows a week, means that someone needs to prepare (check the audio, add intros/outro, add show notes add ID tags, update the queue list, email the new hosts, etc etc). That can be done ahead of time but posting needs to be done every day. That means you are committing someone to connecting to HPR from where ever they are to confirm that all the feeds are working, that each episode has been published correctly, that each show can be played from start to finish, that the website is rendering the show notes correctly. They will need to do this even if they are on Vacation, on a business trip, are abroad, are on a unstable Internet connection. Even if we automate it (more on that later), the *responsibility* has increased and the checks and fixes all still need to be done. We do this every week day but I for one am not willing to commit my weekends as well, many of which already are full with editing or recording HPR shows.
+
+A five day a week release schedule means that the show numbers are predictable. Monday show ends in a 1 or a 6, Tuesdays 2 or a 7, etc. This is incredibly handy when you are barely awake.
+
+
+
+
+
+
+
+
+
+
+
+
+From ken.fallon at gmail.com  Fri Oct 12 14:03:33 2012
+From: ken.fallon at gmail.com (Ken Fallon)
+Date: Fri, 12 Oct 2012 16:03:33 +0200
+Subject: [Hpr] Vote on removing non HPR shows.
+In-Reply-To: <5078154D.2010509@zwilnik.com>
+References: <mailman.1.1349809202.12104.hpr_hackerpublicradio.org@hackerpublicradio.org>
+	<CAD_dxjUCLgN9Prwi2Ff9O66ck=O_our8E4tKWXrN5Oc+ncBJ1w@mail.gmail.com>
+	<20121010103917.299288ea@dell> <8250988.V5dQfOsaul@bunnies>
+	<20121010220759.61c65f8e@dell>
+	<CAKAng83GivSY1vTma81fw-fgTtyFnKekK476_Lbs7nmuFrgC_A@mail.gmail.com>
+	<op.wlziajsd2031o5@localhost> <20121011112912.4ca105cb@dell>
+	<5078154D.2010509@zwilnik.com>
+Message-ID: <CAK-oqQYoZY2=JowsChai3BMFr96PtA3W9F0Oqpva=G5GHLeJ0g@mail.gmail.com>
+
+Hi All,
+
+I want to thank everyone for providing feedback on the current state
+of affairs, this discussion has been fantastic to watch and
+participate in. I wanted to take the time to summarise the situation
+as I see it and I'd appreciate people commenting on whither this is
+correct or not from your point of view.
+
+Summary:
+	HPR releases shows on a very regular schedule and ideally the flow of
+shows in would match the flow of shows out.
+
+Fact:
+	HPR can only control the release rate and has no control over the
+rate at which shows are submitted.
+	Sometimes there are very few shows in the queue resulting in problems
+for the admins in getting shows to air.
+	Other times there are a lot of shows in the queue resulting in hosts
+waiting a long time for their show to air.
+
+The issue that needs to be solved:
+	We need a way to regulate the queue.
+
+The current solution:
+	We have used syndicated content to reduce the amount of shows released.
+	This has failed as it has not regulated the queue.
+
+The Solution (Too many shows in the queue):
+	Release HPR shows at a rate of five shows a week.
+	We have seen that a rate of 3 shows a week will fill up the queue and
+5 shows a week will empty it.
+
+The Solution (Too few shows in the queue):
+	Increase the number of backup shows in the queue.
+	If these shows start playing then the admins will have some time to
+muster new shows.
+
+----------------------------------------
+
+With that in mind I propose changing the scheduling rules to:
+
+Time critical:
+	A show contains newsworthy information of importance to the community
+in general.
+
+Reserved Show Number:
+	Where a host has reserved a special show number (eg HPR1000).
+
+Reserved Date:
+	Where a host has reserved a special date ( eg April 1 ).
+
+Reserved Block:
+	Where a host has attended a festival and can reserve up to 5 slots
+within two weeks of the event.
+
+New Hosts:
+	In order to encourage new hosts we will prioritize their first show.
+	
+Shows From the High Priority Queue:
+	HPR Content based on the host with the oldest previous release date.
+
+Shows From the Normal Priority Queue:
+	HPR Content based on the host with the oldest previous release date.
+	
+Shows From the Low Priority Queue:
+	HPR Content based on the host with the oldest previous release date.
+	
+Shows From the Procrastination Queue:
+	HPR Content based on the host with the oldest previous release date.
+	Anyone known to procrastinate will have the option of uploading an
+embarrassing show to this queue.
+	So long as the queue remains filled then the show will never be played.
+	
+Play the HPR Last Show Episode:
+	If this show is played, then the community has no desire for HPR to continue.
+	Sync with Archive.org and Shutdown HPR.
+	
+Notes:
+	Reservations should be made well in advance.
+	Allocation of regular slots will need to be approved by the mailing list.
+	
+----------------------------------------
+
+OK What do you think ?
+
+Ken.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+I approve of the changes
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <https://lists.hackerpublicradio.com/pipermail/hpr/attachments/20220611/f2388b2d/attachment.htm>
+
+From ken at fallon.ie  Mon Jun 13 07:05:15 2022
+From: ken at fallon.ie (Ken Fallon)
+Date: Mon, 13 Jun 2022 09:05:15 +0200
+Subject: [Hpr] Reserve Queue
+Message-ID: <a484d02e-c514-650b-8887-d735ba4f9e40@fallon.ie>
+
+In today's show the Janitors discuss how the erratic feast/famine nature 
+of the queue may be helped by filling free slots in the main feed from a 
+reserve queue.
+
+  * The current Emergency Queue would be renamed to the Reserve Queue.
+  * If a free slot in the calendar is not filled in time, then a show
+    will be used from the Reserve Queue.
+  * Shows will be taken from the Reserve Queue on a first in first out
+    basis.
+  * Hosts can either schedule a show for a particular slot or have their
+    shows added to the Reserve Queue.
+  * Eventually we will we work on a dedicated upload option, but for now
+    hosts can pick a random slot and just make a note in the show notes
+    that the show is intended for the Reserve Queue.
+
+Thoughts ?
+
+Why yes Ken, one thing springs to mind. Should you not first pick hosts 
+who have not submitted a shows recently ?
+
+Gosh Ken. That is a good point, I'll need to think about that.
+
+Anyone else ?
+
+https://hackerpublicradio.org/eps.php?id=3616

requested_topics/README.md

@@ -0,0 +1,92 @@
+# Requested topics
+
+This is a list of topics that have been requested by the community. 
+
+## General
+
+- How did you get into podcasting/linux/geekdom?
+- What podcasts you listen to and can recommend
+- What's in your bag? Tell us what tools/gear/stuff you keep close at hand.
+- What got you into Linux?
+- Your favorite Android applications.
+- Your favorite desktop applications.
+- Your favorite browser extensions.
+- A introduction to Wireshark.
+- How to set up your own blog.
+- Choosing a artistic design for website, business cards etc.
+- Music Theory
+- Installing a VPN to your home network
+- Init and System.d
+- Episodes for the LPI, or the Networking series.
+- Beginning Audio Series for HPR and OSMP Release
+- Hackintosh computers - what are they, why would you want one.
+- Grub 2.0 introduction and customization.
+- FM Transmitter hack to listen into internet streams
+- How I Got Into Accessible Computing
+- How to do knitting
+- How to build a house
+- How to solder <a href="<!--% absolute_path(baseurl) %-->eps/hpr1037/index.html">hpr1037</a>, 
+  <a href="<!--% absolute_path(baseurl) %-->eps/hpr1047/index.html">hpr1047</a>
+- How to weld
+- How to fix a car
+- Reviews of stream playing software, (for linuxheads who don't want to keep a browser tab open all the time)
+- Reviews of stream ripping software on linux
+- Beginners guide to gnuplot
+- Nagios series, intro, setup, advanced ...
+- How to set up GPG/openPGP
+- What I do with my Raspberry Pi
+- It broke, I fixed it
+- How does coreboot work
+- Introduction to HAM Radio
+- I've moved and they do it like this here
+- How to record a tag team tutorial on a topic
+- Open Street Map new editor
+- etymology
+- functional versus procedural programming
+- sed, awk and grep
+- Setting up imap/smtp (gmail) in a cli mail program
+- Irssi - a sane setup
+- Your view of the future
+- Alternative uses for Bayesian email classifiers (<a href="https://www.youtube.com/watch?v=JKB5CojW4AA">more info</a>)
+- How to use a multimeter, and other basic electronic components like a 555 timer
+- How does Hubble remain fixed on a spot in space while in orbit of the earth
+- Gnu automake system.
+- Any experiences integrating Dell/Wyse thin- and zero- clients into linux networks.
+- What Are the Answers I Need, To the Questions I Don't Know Enough to Ask?
+
+## Networking
+
+### IPv6
+
+- What is an IP address, and what is IPv6 - basic settings. Why can't we just NAT at the ISP level, are there privacy issues in having your MAC address as part of your IP?
+- How to setup IPv6 on Linux, BSD, Windows, Mac, Spark, Android etc
+- IPv6 Addressing terminology , format, shortcuts, address structure, (link local, unique and global), reservations, subnetting, allocation
+- IPv6 Firewall, what to block what to allow
+- Packet structure
+- Troubleshooting IPv6 network issue, using common tools with IPv6, ping icmp, telnet, curl, tcpdump, wireshark,etc
+- How discovery is handled, what is used for dhcp
+- DNS server setup
+- Routing server setup
+- Setting up common services like ssh, apache, nginx
+- Setting up VPN like wireguard
+- Explanation of the new Anycast and why you would use it.
+- Transition plans tips and tricks.
+
+
+## Security 
+
+What do we need for a firewall and what are the detection/prevention technologies that we could be implementing?
+Beyond Firewall and an IDS/IPS, what do I need?
+If you were to treat your home network like a corporate server farm, what tools and hardware would it entail to treat your home network like a security professional?
+Should one use a secondary IDS, behind the firewall, to record what the primary defenses missed.
+Where and how do I set that up?
+Beyond firewall and IDS, what other tools should we be running ?
+Where should they be in my network, and how many physical boxes are we talking about ?
+Emphasis should be on low power devices and free as in beer tools.
+
+How to Read Logs and Formulate a Response to an Intrusion.
+What I've learned from SW, is that you can't prevent an intrusion, it's how to respond when you are compromised.
+Again, according to SW, the security manager's job is to detect intrusions, inside 48 hours rather than 48 months.  
+How can you protect your proprietary data and customer database?
+Better uses for IPFS and IPNS to get a better understanding of practical use of this.
+

suggested_changes.md

@@ -0,0 +1,46 @@
+# HPR Suggested Change
+
+
+## Track reservation key in eps table
+
+Moved from https://repo.anhonesthost.net/HPR/hpr_generator/issues/238
+
+A uploaded show is know by it's key, this should be kept in the eps table so it can be located easily.
+
+## Remove deprecated fields in eps table
+
+Check if version and downloads can be deprecated.
+
+## Comment links should be clickable
+
+Should they ? More moderation needed ?
+
+https://repo.anhonesthost.net/HPR/hpr_generator/issues/157
+
+## Audit of media and supplementary files
+
+https://repo.anhonesthost.net/HPR/hpr_generator/issues/154
+
+Given a show like 2173, which was built to link to supplementary notes on the HPR server, these notes (and other assets) are currently not available because the links are incorrect.
+
+This show references several assets for example:
+
+sqlite> select filename from assets where episode_id = 2173;
+┌─────────────────────────────┐
+│          filename           │
+├─────────────────────────────┤
+│ hpr2173/blinkt_client.py    │
+│ hpr2173/blinkt_legends.svg  │
+│ hpr2173/cronjob_comments    │
+│ hpr2173/full_shownotes.html │
+│ hpr2173/img_01.png          │
+│ hpr2173/img_02.png          │
+│ hpr2173/img_03.png          │
+│ hpr2173/img_04.png          │
+│ hpr2173/img_05.png          │
+│ hpr2173/img_06.png          │
+└─────────────────────────────┘
+
+These are on the IA with the same filenames.
+
+Could this issue be resolved by redirection?

workflow/processing_a_show.md

@@ -17,8 +17,8 @@ The files are downloaded by trusted Janitors that have the ability to `scp`/`rsy
 The directory structure is based on a combination of fields separated by the underscore (`_`) delimiter.
 
 - Upload date and time `UTC_TIMESTAMP()` at reservation time.
-- The requested `episode number` or `9999` if the reserve queue is to be used.
-- The requested `epidode date` or `1970-01-01` if the reserve queue is to be used.
+- The requested `episode number` or `9999` if the reserve pool is to be used.
+- The requested `epidode date` or `1970-01-01` if the reserve pool is to be used.
 - The random unique key for this request.
 
 ```
@@ -30,9 +30,9 @@ The upload will produce at a minimum a `shownote.json` file. It may also include
 
 Addition files and images may be provided by the host, eg: images, scripts, pdf documents etc.
 
-Shows destined for the reserve queue are moved from the upload directory and placed in the reserve directory using the script [rename-reserve.bash](https://repo.anhonesthost.net/HPR/hpr-tools/src/branch/main/workflow/rename-reserve.bash). 
+Shows destined for the reserve pool are moved from the upload directory and placed in the reserve directory using the script [rename-reserve.bash](https://repo.anhonesthost.net/HPR/hpr-tools/src/branch/main/workflow/rename-reserve.bash). 
 
-This is run manually by the Janitors as it checks to see if a url to the show was provided, and attempts to download the linked file. When new hosts submit a show directly to the reserve queue, the Janitors will resubmit it to the first available slot in the normal queue. This is because new hosts need to have an entry created in the `hosts` table, but also because it gives the community an opportunity to welcome the new host.
+This is run manually by the Janitors as it checks to see if a url to the show was provided, and attempts to download the linked file. When new hosts submit a show directly to the reserve pool, the Janitors will resubmit it to the first available slot in the normal queue. This is because new hosts need to have an entry created in the `hosts` table, but also because it gives the community an opportunity to welcome the new host.
 
 It renames the directory structure based on a combination of fields separated by the underscore (`_`) delimiter.
 
@@ -45,7 +45,7 @@ It renames the directory structure based on a combination of fields separated by
 ```
 2339680845_987_4bd713699e5bc0978d5fef85a60f09bc7f70ef3488624_Emperor_Ming_Top_tips_for_time_travel
 ```
-Reserve shows are downloaded and submitted by the Janitors on behalf of the host. This follows the normal posting process where the host and Janitors are cc'd on the notification emails. The only difference is that the audio is edited to include a notification that the show is from the reserve queue, and that it is the Janitors that upload the show via the supplied link.
+Reserve shows are downloaded and submitted by the Janitors on behalf of the host. This follows the normal posting process where the host and Janitors are cc'd on the notification emails. The only difference is that the audio is edited to include a notification that the show is from the reserve pool, and that it is the Janitors that upload the show via the supplied link.
 
 ## Adding the host to the `hosts` table