[Hpr] Backup shows

Ken Fallon ken at fallon.ie
Mon Mar 10 05:28:44 PDT 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2014-03-09 20:36, Dave Morriss wrote:
> On 09/03/14 16:55, Ken Fallon wrote:
>> I would like to bring this topic to some form of closure. Can I invite
>> everyone to comment on this proposed text.
> 
> Looks good. Some minor suggestions below.
> 
>> <quote>
>> If you have a non urgent show, please consider scheduling it during the
>> summer period in the Northern Hemisphere as this is usually when we are
>> short of shows. The backup queue is intended only to be used in the
>> cases where there is still a gap in the schedule 24 hours prior to release.
> 
>> The shows will by their very nature need to be "timeless", ie: your
>> topic should still be relevant in four years or more. People will be
>> able to hear the show on the website but they will not be included in
>> any feeds until release.
> 
>> Please begin all shows with text similar to:
>> "This is a backup show, if you are hearing this then HPR needs shows
>> ASAP. Please consider contributing a show. Email admin at hacker public
>> radio dot org for more information."
> 
> Perhaps make reference to the page on the website which explains this in
> great detail?
This text is for the web site, so what else needs to be added ?

> 
>> We expect that we need at least 10 shows in the backup queue in order to
>> give people enough time to record and submit shows. Remember once that
>> all the backup shows have been used up and there are no more shows in
>> the queue, HPR as a project will stop.
>> </quote>
> 
> Does it need to point out that if the cache of shows exceeds a
> threshold, rather than keeping an ever-growing collection (however slow
> the rate of growth), the older shows will be released into the live
> system? Something like that? Use some other criterion than age?

I think we need to make it clear that shows in this queue will *never*
get released unless there is an emergency. The reason I mention 10
shows, is because that is the minimum I think we need to rally the troops.

Taking a step back. We have multiple definitions of "backup" shows. My
understanding of the backup queue was that it would be used when shows
were needed to fill gaps. Once it got big, shows would be rotated out.

The reason we had this discussion on the Community News, was that I have
gotten a few emails from people who submitted their shows as backups and
then wondered where they were not scheduled for release.

On the other hand as we can see from the discussions to this thread,
some hosts intend that their shows never be rotated out and only used
for backup slots.

So the purpose of this clause is to make the Backup queue an Emergency
Queue. IE *only* shows intended to be in there for a looooooong time. No
rotation, no maximum size, playable - yes, but not scheduled until they
are needed.

So what about people that don't care when they are scheduled, who are in
no particular rush to have their show aired, but expect it to be
released sometime. I do not want to be responsible for scheduling those,
for fear of acquisitions of bias. Yes we could write a script to
schedule them but then that leads to confusion. So then why not let the
people schedule the shows themselves at a time we know will be quiet.
Eg: during the summer.

Does that seem logical and fair ?

If so I want to release the shows in the backup queue that where not
intended to be there for that long. (The hosts will still need to pick
the day)

Rename the queue Emergency Queue.

Update the website with appropriate text explaining the change. Namely
it's our preference if you pick a day for release.

- -- 
Regards,

Ken Fallon
http://kenfallon.com
http://hackerpublicradio.org/correspondents.php?hostid=30
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTHa/7AAoJECO2jUN3MRFpbWkQAJT+qV/7Xe5b7RF3Lpr1cgel
dsRJ3gRJba/AWZ1U/6EFeyMohJf1+pBYD/1O1Fffs+8+KSO9LZbBYnNfKQUyCcKu
mtN/q909HWrtrkNotA/LLGY94AhsnMDwptFXmErepIq/ofxZebEh66DzrDwcRk1U
G88bRVJk3uSwVeU1r324fFEonrJ8aKtBYCFb2cRVtIA7BQrt4WBCkpK17df02G4M
5fs5LAfztypOUXhRra8BezEEucEaqnwHfWC0C2F48Tm3MPS37dApw7ZifnYUPSS0
4Rx4AWSzcnDahqe+J0kpbdAaf7w55yzXNG8blcrH1j7s1V7GtMVFdB06f/HGkl0X
cCJHxhQONPg9qwMR8BHAIgiu3haNJPxtq7jCrzqlEbmJQhYM0BHiK/bUD2U1nk1R
16+RicOZm+cDzarcZIrwaT//Zo6vllQthbzb6rTDuFcGwomqjPNV+5ooB9y2Hhkv
qqZe0pJYz8Eg7BzvFeQEZ2uxuRw3PfBVD4MFq27emhUnUI0wLkEe6/H/c3wtiCUA
fyjvrFgyvsPVApud1WX5Vv4Tldpav5H4RhyA3Ljr20m+Qr5238xSfgJFuU4eqcCI
d6g1Mvj3N//d/7Tm/iUYI9eSrBIdldCVIKhO/sYqMNkugiX6SdS7S6WgXlK6WS96
/6Cgtzlumya+AEKPr+85
=ydSl
-----END PGP SIGNATURE-----




More information about the Hpr mailing list