-----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----- _______________________________________________ Hpr mailing list Hpr@hackerpublicradio.org http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
