Has Klaatu's show legitimately been in the queue for that long or did it somehow slip through the cracks?<br><br><div class="gmail_quote">On Wed, May 29, 2013 at 9:59 AM,  <span dir="ltr"><<a href="mailto:hpr-request@hackerpublicradio.org" target="_blank">hpr-request@hackerpublicradio.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Hpr mailing list submissions to<br>
        <a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a><br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org" target="_blank">http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org</a><br>
or, via email, send a message with subject or body 'help' to<br>
        <a href="mailto:hpr-request@hackerpublicradio.org">hpr-request@hackerpublicradio.org</a><br>
You can reach the person managing the list at<br>
        <a href="mailto:hpr-owner@hackerpublicradio.org">hpr-owner@hackerpublicradio.org</a><br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Hpr digest..."<br>
<br>Today's Topics:<br>
   1. Re: new show posting algorithm (<a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a>)<br>
   2. Re: new show posting algorithm (Klaatu)<br>
   3. Re: new show posting algorithm (Ken Fallon)<br>
   4. Re: new show posting algorithm (Klaatu)<br>
<br><br>---------- Forwarded message ----------<br>From: <a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a><br>To: <a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a><br>

Cc: <br>Date: Tue, 28 May 2013 16:34:54 -0400<br>Subject: Re: [Hpr] new show posting algorithm<br>> I know this is a much-discussed topic, but it's partly for that reason that<br>
> I've been tracking the progress of an episode I submitted via FTP, trying to<br>
> predict when it would actually be posted to HPR's feed. One show I posted on<br>
> April 2nd to FTP has been "in queue" for 42 days and counting.<br>
> I think that's too long for anyone's show to be in queue; I think it<br>
> discourages contributors, I think it frustrates contributors, and I think it<br>
> risks making mini-series episodes so far and few between that they become<br>
> disjointed.<br>
If the show in question is "Icecast102", I can also verify that this issue affects me as a listener and not just a contributor - I've been waiting for that one in particular for a while now, and still have no idea when I'll get to hear it (not that my particular, specific interest at this moment necessarily reflects the specific interests of HPR listeners in general, just mentioning this as an example).<br>

> It seems to me that a simpler algorithm would help encourage contributors<br>
> (both existing and new) to post shows. Here is my proposal:<br>
> 1. First In, First Out<br>
> 2. When possible, no repeated hosts within the same week<br>
> 3. No reserved slots; shows with existing RSS feeds are re-broadcast only<br>
> when there is no original HPR content waiting to be aired.<br>
> 4. Special requests (for time-sensitive episodes) are the exception to every<br>
> rule.<br>
> Thoughts?<br>
(I'll start with the "thoughts", then throw in a suggestion or two at the end...)<br>
I've gotten more sympathetic lately about the desire to hoard shows in the queue for use in times of submission-famine. I've also come to more appreciate the emphasis on bringing in new hosts: contributing to HPR is like a roll or toilet paper, or sex. ("After the first one, the rest are much easier...") so an investment in pulling in a larger pool of contributors improves the odds that if the show queue gets critically low there'll be at least a few people who are likely to be willing and able to transfuse a few more shows into the system to keep HPR alive. The quick hit of positive reinforcement for first-time contributors is a good thing, despite the disruption of the queue.<br>

That said, the current arrangement does also discourage regular contributions from the same hosts EXCEPT where the hosts can reliably commit to a regular schedule (reserved slots). In my case, I've not gotten very far into the followup to my last episode in part because I know it'll be at least a month or two before it would hit the feed anyway (since I've already had a show in the feed recently). Summer tends to be pretty lean historically for new submissions, so I'd guess there's a good chance that the queue might be getting very low by sometime in August (maybe even mid-late July if contributions dry up quickly) but then it still makes little difference whether I get something in the queue now or wait until late July.<br>

(On a personal level, I really need to get myself into a regular habit/rhythm of recording so that I get better and more efficient at it. Being the "acknowledgement courtesan" that I am, the anticipation of the feedback from an episode is a key motivator for me, and the long latency between the behavior and the reinforcement messes with my ability to derive a "reward" from the effort. This is definitely a personal flaw rather than a "problem with hacker public radio", but I may not be the only one experiencing this personal speedbump.)<br>

So I guess, fundamentally, the problem is how to clear up the bouts of podstipation HPR gets at times like this without inducing podorrhea and running out of shows and without giving up the incentives for new hosts.<br>
(Also, for a longer-term topic: we actually want to make this problem WORSE - we want Hacker Public Radio to grow as much as possible, I assume. Ideally, at some point we have so many shows coming in that we have to split things up like <a href="http://twit.tv" target="_blank">twit.tv</a> into a variety of separate topic feeds.  Yes, I realize that's quite a long ways off, but I'm thinking it would be good to look ahead to a glorious future and not ONLY focus on "how do we not starve?")<br>

Here's one suggestion for the near future: more feeds.<br>
Leave the main "Hacker Public Radio" feed as it is, with the existing scheduling rules (possibly with some sort of 'maximum wait time' to prevent a show sitting in the queue for TOO long though).  The only change involved in my suggestion here would be that shows get assigned an HPR Episode# as soon as they are ready for the queue rather than when they are actually released. That way, they can also appear immediately in a second "unrestricted" feed, which simply presents the shows as they are added for those who are willing to opt-in to dealing with an uneven release schedule. That would allow the main Hacker Public Radio feed to keep going in lean times as it does now, while at least some listeners would be hearing (and hopefully providing feedback on) shows as they are submitted at the same time.<br>

It's been said that some people are already complaining that HPR releases too many shows. If we continue to grow, we may even end up wanting to have some "tag based" feeds (e.g. a feed specifically limited to, say, "Linux" topics, a feed specifically limited to "science" topics, a feed for just "media" topics, etc.). I don't think we've hit the point where the inflow of new shows is enough for that to be very useful just yet (though with ~1200 shows so far, it might be worth experimenting with the archives and one or two "topical" feeds to see how it looks).<br>

Either way (or even both ways) I think the result would be the main queue actually growing even more, with the addition of other channels allowing submitters to be heard and thus making the growing latency of the main queue less of an issue.<br>

I'd also reiterate the suggestion of possibly doing multi-episode days on the main feed (show in the queue for two months but also a new contributor that day? Double-feature time!) when the main queue grows to a sufficient length, though if "too many shows in the feed" is really a problem listeners are complaining about, I don't know if that would be counterproductive or not.<br>

Perhaps as an incentive for frequent contribution, having multiple shows in the backup queue or the main queue might bump up older shows by the same host by a day or two each.  ("Show not coming out quickly enough for you? Submit some more!")<br>

<br><br>---------- Forwarded message ----------<br>From: Klaatu <<a href="mailto:klaatu@straightedgelinux.com">klaatu@straightedgelinux.com</a>><br>To: <a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a><br>

Cc: <br>Date: Tue, 28 May 2013 16:51:52 -0400<br>Subject: Re: [Hpr] new show posting algorithm<br>Epicanus,<br>
I like the idea of tag based feeds. Sounds like a really cool idea, although I<br>
admit to having no clue how to implement it.<br>
As for the notion of multi-episode release days.... I would advise against it.<br>
I've been with HPR for a long time now, and I've seen surplus and surfeit; I<br>
wouldn't get too drunk on how many shows we have right now in queue because<br>
before you know it we will be calling your cell phone demanding shows because<br>
we have NOTHING to post tomorrow. It's happened before!<br>
I do believe the "new hosts" move to the top of the queue is a good idea; I<br>
forgot about that and I do think it's an important exception-to-every-rule<br>
On Tuesday, May 28, 2013 04:34:54 PM <a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a> wrote:<br>
> > I know this is a much-discussed topic, but it's partly for that reason<br>
> > that<br>
> > I've been tracking the progress of an episode I submitted via FTP, trying<br>
> > to predict when it would actually be posted to HPR's feed. One show I<br>
> > posted on April 2nd to FTP has been "in queue" for 42 days and counting.<br>
> ><br>
> > I think that's too long for anyone's show to be in queue; I think it<br>
> > discourages contributors, I think it frustrates contributors, and I think<br>
> > it risks making mini-series episodes so far and few between that they<br>
> > become disjointed.<br>
> If the show in question is "Icecast102", I can also verify that this issue<br>
> affects me as a listener and not just a contributor - I've been waiting for<br>
> that one in particular for a while now, and still have no idea when I'll<br>
> get to hear it (not that my particular, specific interest at this moment<br>
> necessarily reflects the specific interests of HPR listeners in general,<br>
> just mentioning this as an example).<br>
> > It seems to me that a simpler algorithm would help encourage contributors<br>
> > (both existing and new) to post shows. Here is my proposal:<br>
> ><br>
> > 1. First In, First Out<br>
> ><br>
> > 2. When possible, no repeated hosts within the same week<br>
> ><br>
> > 3. No reserved slots; shows with existing RSS feeds are re-broadcast only<br>
> > when there is no original HPR content waiting to be aired.<br>
> ><br>
> > 4. Special requests (for time-sensitive episodes) are the exception to<br>
> > every rule.<br>
> ><br>
> > Thoughts?<br>
> (I'll start with the "thoughts", then throw in a suggestion or two at the<br>
> end...)<br>
> I've gotten more sympathetic lately about the desire to hoard shows in the<br>
> queue for use in times of submission-famine. I've also come to more<br>
> appreciate the emphasis on bringing in new hosts: contributing to HPR is<br>
> like a roll or toilet paper, or sex. ("After the first one, the rest are<br>
> much easier...") so an investment in pulling in a larger pool of<br>
> contributors improves the odds that if the show queue gets critically low<br>
> there'll be at least a few people who are likely to be willing and able to<br>
> transfuse a few more shows into the system to keep HPR alive. The quick hit<br>
> of positive reinforcement for first-time contributors is a good thing,<br>
> despite the disruption of the queue.<br>
> That said, the current arrangement does also discourage regular<br>
> contributions from the same hosts EXCEPT where the hosts can reliably<br>
> commit to a regular schedule (reserved slots). In my case, I've not gotten<br>
> very far into the followup to my last episode in part because I know it'll<br>
> be at least a month or two before it would hit the feed anyway (since I've<br>
> already had a show in the feed recently). Summer tends to be pretty lean<br>
> historically for new submissions, so I'd guess there's a good chance that<br>
> the queue might be getting very low by sometime in August (maybe even<br>
> mid-late July if contributions dry up quickly) but then it still makes<br>
> little difference whether I get something in the queue now or wait until<br>
> late July.<br>
> (On a personal level, I really need to get myself into a regular<br>
> habit/rhythm of recording so that I get better and more efficient at it.<br>
> Being the "acknowledgement courtesan" that I am, the anticipation of the<br>
> feedback from an episode is a key motivator for me, and the long latency<br>
> between the behavior and the reinforcement messes with my ability to derive<br>
> a "reward" from the effort. This is definitely a personal flaw rather than<br>
> a "problem with hacker public radio", but I may not be the only one<br>
> experiencing this personal speedbump.)<br>
> So I guess, fundamentally, the problem is how to clear up the bouts of<br>
> podstipation HPR gets at times like this without inducing podorrhea and<br>
> running out of shows and without giving up the incentives for new hosts.<br>
> (Also, for a longer-term topic: we actually want to make this problem WORSE<br>
> - we want Hacker Public Radio to grow as much as possible, I assume.<br>
> Ideally, at some point we have so many shows coming in that we have to<br>
> split things up like <a href="http://twit.tv" target="_blank">twit.tv</a> into a variety of separate topic feeds.  Yes,<br>
> I realize that's quite a long ways off, but I'm thinking it would be good<br>
> to look ahead to a glorious future and not ONLY focus on "how do we not<br>
> starve?")<br>
> Here's one suggestion for the near future: more feeds.<br>
> Leave the main "Hacker Public Radio" feed as it is, with the existing<br>
> scheduling rules (possibly with some sort of 'maximum wait time' to prevent<br>
> a show sitting in the queue for TOO long though).  The only change involved<br>
> in my suggestion here would be that shows get assigned an HPR Episode# as<br>
> soon as they are ready for the queue rather than when they are actually<br>
> released. That way, they can also appear immediately in a second<br>
> "unrestricted" feed, which simply presents the shows as they are added for<br>
> those who are willing to opt-in to dealing with an uneven release schedule.<br>
> That would allow the main Hacker Public Radio feed to keep going in lean<br>
> times as it does now, while at least some listeners would be hearing (and<br>
> hopefully providing feedback on) shows as they are submitted at the same<br>
> time.<br>
> It's been said that some people are already complaining that HPR releases<br>
> too many shows. If we continue to grow, we may even end up wanting to have<br>
> some "tag based" feeds (e.g. a feed specifically limited to, say, "Linux"<br>
> topics, a feed specifically limited to "science" topics, a feed for just<br>
> "media" topics, etc.). I don't think we've hit the point where the inflow<br>
> of new shows is enough for that to be very useful just yet (though with<br>
> ~1200 shows so far, it might be worth experimenting with the archives and<br>
> one or two "topical" feeds to see how it looks).<br>
> Either way (or even both ways) I think the result would be the main queue<br>
> actually growing even more, with the addition of other channels allowing<br>
> submitters to be heard and thus making the growing latency of the main<br>
> queue less of an issue.<br>
> I'd also reiterate the suggestion of possibly doing multi-episode days on<br>
> the main feed (show in the queue for two months but also a new contributor<br>
> that day? Double-feature time!) when the main queue grows to a sufficient<br>
> length, though if "too many shows in the feed" is really a problem<br>
> listeners are complaining about, I don't know if that would be<br>
> counterproductive or not.<br>
> Perhaps as an incentive for frequent contribution, having multiple shows in<br>
> the backup queue or the main queue might bump up older shows by the same<br>
> host by a day or two each.  ("Show not coming out quickly enough for you?<br>
> Submit some more!")<br>
> _______________________________________________<br>
> Hpr mailing list<br>
> <a href="mailto:Hpr@hackerpublicradio.org">Hpr@hackerpublicradio.org</a><br>
> <a href="http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org" target="_blank">http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org</a><br>
- klaatu<br>
<br><br>---------- Forwarded message ----------<br>From: Ken Fallon <<a href="mailto:ken.fallon@gmail.com">ken.fallon@gmail.com</a>><br>To: <a href="mailto:klaatu@straightedgelinux.com">klaatu@straightedgelinux.com</a><br>

Cc: "<a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a>" <<a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a>><br>Date: Wed, 29 May 2013 00:38:18 +0200<br>Subject: Re: [Hpr] new show posting algorithm<br>

I think the current queue is fair in so far as hosts who have<br>
released, need to stand aside for those that haven't aired since they<br>
have. So once you release you go back to the end of the queue.<br>
Unfortunately the queue amounts to "${everyone in the universe} MINUS<br>
${anyone who has released since I did}. So in principle it's fair but<br>
in practice it isn't.<br>
The worst part is that it is causing confusion, frustration and<br>
leading to a sense of unfairness.<br>
I think Klaatu nailed it with the rule "First in First out" but I<br>
would suggest that be the only rule, with the caveat that you can pick<br>
any available date/episode number. That way as soon as a show (final<br>
FLAC, with complete show notes) is received, and is processed it is<br>
given it's permanent date and show number. This would allow the *host*<br>
to decide how to space out the episode, so that some times you might<br>
leave a week between shows, eg: for a series, and other times release<br>
them all in one block, eg: after attending a festival.<br>
New hosts should not be jumped to the start of the queue as there<br>
would be only a two week wait if we used this system on the current<br>
queue. Your show will be available in the "dudeman" feed that releases<br>
shows as soon as they are posted.<br>
So looking at how that compares to the current system:<br>
Rule 1 Time critical:<br>
For urgent shows, you will need to swap the _slot_ with the person who<br>
is scheduled. This means that if you have hprYYYY and you wish to have<br>
hprBBBB then you two swap and everyone in between keep the same<br>
number/date. If it's so important then the person will wish to swap,<br>
if not then it's not that important.<br>
Rule 2 Reserved Slots :<br>
Record the show well in advance and reserve the date.<br>
Rule 3 Scheduled Slots:<br>
65% of our content is Scheduled slots so I agree with klaatu, so yes<br>
the reservations (not the shows) have to go. They can continue to<br>
submit shows and pick slots like everyone else, it's just that more<br>
planning is involved.<br>
Rule 4 Normal priority:<br>
If you don't select a date then you will be allocated the first available slot.<br>
Rule 5 Backup Shows:<br>
I'd still like to have some backup shows so that epicanis has some<br>
time to record a show after klaatu calls his cell.<br>
On Tue, May 28, 2013 at 10:51 PM, Klaatu <<a href="mailto:klaatu@straightedgelinux.com">klaatu@straightedgelinux.com</a>> wrote:<br>
> Epicanus,<br>
> I like the idea of tag based feeds. Sounds like a really cool idea, although I<br>
> admit to having no clue how to implement it.<br>
> As for the notion of multi-episode release days.... I would advise against it.<br>
> I've been with HPR for a long time now, and I've seen surplus and surfeit; I<br>
> wouldn't get too drunk on how many shows we have right now in queue because<br>
> before you know it we will be calling your cell phone demanding shows because<br>
> we have NOTHING to post tomorrow. It's happened before!<br>
> I do believe the "new hosts" move to the top of the queue is a good idea; I<br>
> forgot about that and I do think it's an important exception-to-every-rule<br>
> rule.<br>
> -klaatu<br>
> On Tuesday, May 28, 2013 04:34:54 PM <a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a> wrote:<br>
>> > I know this is a much-discussed topic, but it's partly for that reason<br>
>> > that<br>
>> > I've been tracking the progress of an episode I submitted via FTP, trying<br>
>> > to predict when it would actually be posted to HPR's feed. One show I<br>
>> > posted on April 2nd to FTP has been "in queue" for 42 days and counting.<br>
>> ><br>
>> > I think that's too long for anyone's show to be in queue; I think it<br>
>> > discourages contributors, I think it frustrates contributors, and I think<br>
>> > it risks making mini-series episodes so far and few between that they<br>
>> > become disjointed.<br>
>> If the show in question is "Icecast102", I can also verify that this issue<br>
>> affects me as a listener and not just a contributor - I've been waiting for<br>
>> that one in particular for a while now, and still have no idea when I'll<br>
>> get to hear it (not that my particular, specific interest at this moment<br>
>> necessarily reflects the specific interests of HPR listeners in general,<br>
>> just mentioning this as an example).<br>
>> > It seems to me that a simpler algorithm would help encourage contributors<br>
>> > (both existing and new) to post shows. Here is my proposal:<br>
>> ><br>
>> > 1. First In, First Out<br>
>> ><br>
>> > 2. When possible, no repeated hosts within the same week<br>
>> ><br>
>> > 3. No reserved slots; shows with existing RSS feeds are re-broadcast only<br>
>> > when there is no original HPR content waiting to be aired.<br>
>> ><br>
>> > 4. Special requests (for time-sensitive episodes) are the exception to<br>
>> > every rule.<br>
>> ><br>
>> > Thoughts?<br>
>> (I'll start with the "thoughts", then throw in a suggestion or two at the<br>
>> end...)<br>
>> I've gotten more sympathetic lately about the desire to hoard shows in the<br>
>> queue for use in times of submission-famine. I've also come to more<br>
>> appreciate the emphasis on bringing in new hosts: contributing to HPR is<br>
>> like a roll or toilet paper, or sex. ("After the first one, the rest are<br>
>> much easier...") so an investment in pulling in a larger pool of<br>
>> contributors improves the odds that if the show queue gets critically low<br>
>> there'll be at least a few people who are likely to be willing and able to<br>
>> transfuse a few more shows into the system to keep HPR alive. The quick hit<br>
>> of positive reinforcement for first-time contributors is a good thing,<br>
>> despite the disruption of the queue.<br>
>> That said, the current arrangement does also discourage regular<br>
>> contributions from the same hosts EXCEPT where the hosts can reliably<br>
>> commit to a regular schedule (reserved slots). In my case, I've not gotten<br>
>> very far into the followup to my last episode in part because I know it'll<br>
>> be at least a month or two before it would hit the feed anyway (since I've<br>
>> already had a show in the feed recently). Summer tends to be pretty lean<br>
>> historically for new submissions, so I'd guess there's a good chance that<br>
>> the queue might be getting very low by sometime in August (maybe even<br>
>> mid-late July if contributions dry up quickly) but then it still makes<br>
>> little difference whether I get something in the queue now or wait until<br>
>> late July.<br>
>> (On a personal level, I really need to get myself into a regular<br>
>> habit/rhythm of recording so that I get better and more efficient at it.<br>
>> Being the "acknowledgement courtesan" that I am, the anticipation of the<br>
>> feedback from an episode is a key motivator for me, and the long latency<br>
>> between the behavior and the reinforcement messes with my ability to derive<br>
>> a "reward" from the effort. This is definitely a personal flaw rather than<br>
>> a "problem with hacker public radio", but I may not be the only one<br>
>> experiencing this personal speedbump.)<br>
>> So I guess, fundamentally, the problem is how to clear up the bouts of<br>
>> podstipation HPR gets at times like this without inducing podorrhea and<br>
>> running out of shows and without giving up the incentives for new hosts.<br>
>> (Also, for a longer-term topic: we actually want to make this problem WORSE<br>
>> - we want Hacker Public Radio to grow as much as possible, I assume.<br>
>> Ideally, at some point we have so many shows coming in that we have to<br>
>> split things up like <a href="http://twit.tv" target="_blank">twit.tv</a> into a variety of separate topic feeds.  Yes,<br>
>> I realize that's quite a long ways off, but I'm thinking it would be good<br>
>> to look ahead to a glorious future and not ONLY focus on "how do we not<br>
>> starve?")<br>
>> Here's one suggestion for the near future: more feeds.<br>
>> Leave the main "Hacker Public Radio" feed as it is, with the existing<br>
>> scheduling rules (possibly with some sort of 'maximum wait time' to prevent<br>
>> a show sitting in the queue for TOO long though).  The only change involved<br>
>> in my suggestion here would be that shows get assigned an HPR Episode# as<br>
>> soon as they are ready for the queue rather than when they are actually<br>
>> released. That way, they can also appear immediately in a second<br>
>> "unrestricted" feed, which simply presents the shows as they are added for<br>
>> those who are willing to opt-in to dealing with an uneven release schedule.<br>
>> That would allow the main Hacker Public Radio feed to keep going in lean<br>
>> times as it does now, while at least some listeners would be hearing (and<br>
>> hopefully providing feedback on) shows as they are submitted at the same<br>
>> time.<br>
>> It's been said that some people are already complaining that HPR releases<br>
>> too many shows. If we continue to grow, we may even end up wanting to have<br>
>> some "tag based" feeds (e.g. a feed specifically limited to, say, "Linux"<br>
>> topics, a feed specifically limited to "science" topics, a feed for just<br>
>> "media" topics, etc.). I don't think we've hit the point where the inflow<br>
>> of new shows is enough for that to be very useful just yet (though with<br>
>> ~1200 shows so far, it might be worth experimenting with the archives and<br>
>> one or two "topical" feeds to see how it looks).<br>
>> Either way (or even both ways) I think the result would be the main queue<br>
>> actually growing even more, with the addition of other channels allowing<br>
>> submitters to be heard and thus making the growing latency of the main<br>
>> queue less of an issue.<br>
>> I'd also reiterate the suggestion of possibly doing multi-episode days on<br>
>> the main feed (show in the queue for two months but also a new contributor<br>
>> that day? Double-feature time!) when the main queue grows to a sufficient<br>
>> length, though if "too many shows in the feed" is really a problem<br>
>> listeners are complaining about, I don't know if that would be<br>
>> counterproductive or not.<br>
>> Perhaps as an incentive for frequent contribution, having multiple shows in<br>
>> the backup queue or the main queue might bump up older shows by the same<br>
>> host by a day or two each.  ("Show not coming out quickly enough for you?<br>
>> Submit some more!")<br>
>> _______________________________________________<br>
>> Hpr mailing list<br>
>> <a href="mailto:Hpr@hackerpublicradio.org">Hpr@hackerpublicradio.org</a><br>
>> <a href="http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org" target="_blank">http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org</a><br>
> - klaatu<br>
> _______________________________________________<br>
> Hpr mailing list<br>
> <a href="mailto:Hpr@hackerpublicradio.org">Hpr@hackerpublicradio.org</a><br>
> <a href="http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org" target="_blank">http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org</a><br>
<br><br>---------- Forwarded message ----------<br>From: Klaatu <<a href="mailto:klaatu@straightedgelinux.com">klaatu@straightedgelinux.com</a>><br>To: "<a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a>" <<a href="mailto:hpr@hackerpublicradio.org">hpr@hackerpublicradio.org</a>><br>

Cc: <br>Date: Wed, 29 May 2013 09:59:16 -0400<br>Subject: Re: [Hpr] new show posting algorithm<br>On Wednesday, May 29, 2013 12:38:18 AM Ken Fallon wrote:<br>
> I think the current queue is fair in so far as hosts who have<br>
> released, need to stand aside for those that haven't aired since they<br>
> have. So once you release you go back to the end of the queue.<br>
> Unfortunately the queue amounts to "${everyone in the universe} MINUS<br>
> ${anyone who has released since I did}. So in principle it's fair but<br>
> in practice it isn't.<br>
> The worst part is that it is causing confusion, frustration and<br>
> leading to a sense of unfairness.<br>
> I think Klaatu nailed it with the rule "First in First out" but I<br>
> would suggest that be the only rule, with the caveat that you can pick<br>
> any available date/episode number. That way as soon as a show (final<br>
> FLAC, with complete show notes) is received, and is processed it is<br>
> given it's permanent date and show number. This would allow the *host*<br>
> to decide how to space out the episode, so that some times you might<br>
> leave a week between shows, eg: for a series, and other times release<br>
> them all in one block, eg: after attending a festival.<br>
> New hosts should not be jumped to the start of the queue as there<br>
> would be only a two week wait if we used this system on the current<br>
> queue. Your show will be available in the "dudeman" feed that releases<br>
> shows as soon as they are posted.<br>
> So looking at how that compares to the current system:<br>
> Rule 1 Time critical:<br>
> For urgent shows, you will need to swap the _slot_ with the person who<br>
> is scheduled. This means that if you have hprYYYY and you wish to have<br>
> hprBBBB then you two swap and everyone in between keep the same<br>
> number/date. If it's so important then the person will wish to swap,<br>
> if not then it's not that important.<br>
> Rule 2 Reserved Slots :<br>
> Record the show well in advance and reserve the date.<br>
> Rule 3 Scheduled Slots:<br>
> 65% of our content is Scheduled slots so I agree with klaatu, so yes<br>
> the reservations (not the shows) have to go. They can continue to<br>
> submit shows and pick slots like everyone else, it's just that more<br>
> planning is involved.<br>
> Rule 4 Normal priority:<br>
> If you don't select a date then you will be allocated the first available<br>
> slot.<br>
> Rule 5 Backup Shows:<br>
> I'd still like to have some backup shows so that epicanis has some<br>
> time to record a show after klaatu calls his cell.<br>
> Ken.<br>
> On Tue, May 28, 2013 at 10:51 PM, Klaatu <<a href="mailto:klaatu@straightedgelinux.com">klaatu@straightedgelinux.com</a>><br>
> > Epicanus,<br>
> ><br>
> > I like the idea of tag based feeds. Sounds like a really cool idea,<br>
> > although I admit to having no clue how to implement it.<br>
> ><br>
> > As for the notion of multi-episode release days.... I would advise against<br>
> > it. I've been with HPR for a long time now, and I've seen surplus and<br>
> > surfeit; I wouldn't get too drunk on how many shows we have right now in<br>
> > queue because before you know it we will be calling your cell phone<br>
> > demanding shows because we have NOTHING to post tomorrow. It's happened<br>
> > before!<br>
> ><br>
> > I do believe the "new hosts" move to the top of the queue is a good idea;<br>
> > I<br>
> > forgot about that and I do think it's an important exception-to-every-rule<br>
> > rule.<br>
> ><br>
> > -klaatu<br>
> ><br>
> > On Tuesday, May 28, 2013 04:34:54 PM <a href="mailto:epicanis%2Bhpr@dogphilosophy.net">epicanis+hpr@dogphilosophy.net</a> wrote:<br>
> >> > I know this is a much-discussed topic, but it's partly for that reason<br>
> >> > that<br>
> >> > I've been tracking the progress of an episode I submitted via FTP,<br>
> >> > trying<br>
> >> > to predict when it would actually be posted to HPR's feed. One show I<br>
> >> > posted on April 2nd to FTP has been "in queue" for 42 days and<br>
> >> > counting.<br>
> >> ><br>
> >> > I think that's too long for anyone's show to be in queue; I think it<br>
> >> > discourages contributors, I think it frustrates contributors, and I<br>
> >> > think<br>
> >> > it risks making mini-series episodes so far and few between that they<br>
> >> > become disjointed.<br>
> >><br>
> >> If the show in question is "Icecast102", I can also verify that this<br>
> >> issue<br>
> >> affects me as a listener and not just a contributor - I've been waiting<br>
> >> for<br>
> >> that one in particular for a while now, and still have no idea when I'll<br>
> >> get to hear it (not that my particular, specific interest at this moment<br>
> >> necessarily reflects the specific interests of HPR listeners in general,<br>
> >> just mentioning this as an example).<br>
> >><br>
> >> > It seems to me that a simpler algorithm would help encourage<br>
> >> > contributors<br>
> >> > (both existing and new) to post shows. Here is my proposal:<br>
> >> ><br>
> >> > 1. First In, First Out<br>
> >> ><br>
> >> > 2. When possible, no repeated hosts within the same week<br>
> >> ><br>
> >> > 3. No reserved slots; shows with existing RSS feeds are re-broadcast<br>
> >> > only<br>
> >> > when there is no original HPR content waiting to be aired.<br>
> >> ><br>
> >> > 4. Special requests (for time-sensitive episodes) are the exception to<br>
> >> > every rule.<br>
> >> ><br>
> >> > Thoughts?<br>
> >><br>
> >> (I'll start with the "thoughts", then throw in a suggestion or two at the<br>
> >> end...)<br>
> >><br>
> >> I've gotten more sympathetic lately about the desire to hoard shows in<br>
> >> the<br>
> >> queue for use in times of submission-famine. I've also come to more<br>
> >> appreciate the emphasis on bringing in new hosts: contributing to HPR is<br>
> >> like a roll or toilet paper, or sex. ("After the first one, the rest are<br>
> >> much easier...") so an investment in pulling in a larger pool of<br>
> >> contributors improves the odds that if the show queue gets critically low<br>
> >> there'll be at least a few people who are likely to be willing and able<br>
> >> to<br>
> >> transfuse a few more shows into the system to keep HPR alive. The quick<br>
> >> hit<br>
> >> of positive reinforcement for first-time contributors is a good thing,<br>
> >> despite the disruption of the queue.<br>
> >><br>
> >> That said, the current arrangement does also discourage regular<br>
> >> contributions from the same hosts EXCEPT where the hosts can reliably<br>
> >> commit to a regular schedule (reserved slots). In my case, I've not<br>
> >> gotten<br>
> >> very far into the followup to my last episode in part because I know<br>
> >> it'll<br>
> >> be at least a month or two before it would hit the feed anyway (since<br>
> >> I've<br>
> >> already had a show in the feed recently). Summer tends to be pretty lean<br>
> >> historically for new submissions, so I'd guess there's a good chance that<br>
> >> the queue might be getting very low by sometime in August (maybe even<br>
> >> mid-late July if contributions dry up quickly) but then it still makes<br>
> >> little difference whether I get something in the queue now or wait until<br>
> >> late July.<br>
> >><br>
> >> (On a personal level, I really need to get myself into a regular<br>
> >> habit/rhythm of recording so that I get better and more efficient at it.<br>
> >> Being the "acknowledgement courtesan" that I am, the anticipation of the<br>
> >> feedback from an episode is a key motivator for me, and the long latency<br>
> >> between the behavior and the reinforcement messes with my ability to<br>
> >> derive<br>
> >> a "reward" from the effort. This is definitely a personal flaw rather<br>
> >> than<br>
> >> a "problem with hacker public radio", but I may not be the only one<br>
> >> experiencing this personal speedbump.)<br>
> >><br>
> >> So I guess, fundamentally, the problem is how to clear up the bouts of<br>
> >> podstipation HPR gets at times like this without inducing podorrhea and<br>
> >> running out of shows and without giving up the incentives for new hosts.<br>
> >><br>
> >> (Also, for a longer-term topic: we actually want to make this problem<br>
> >> WORSE<br>
> >> - we want Hacker Public Radio to grow as much as possible, I assume.<br>
> >> Ideally, at some point we have so many shows coming in that we have to<br>
> >> split things up like <a href="http://twit.tv" target="_blank">twit.tv</a> into a variety of separate topic feeds.<br>
> >> Yes,<br>
> >> I realize that's quite a long ways off, but I'm thinking it would be good<br>
> >> to look ahead to a glorious future and not ONLY focus on "how do we not<br>
> >> starve?")<br>
> >><br>
> >> Here's one suggestion for the near future: more feeds.<br>
> >><br>
> >> Leave the main "Hacker Public Radio" feed as it is, with the existing<br>
> >> scheduling rules (possibly with some sort of 'maximum wait time' to<br>
> >> prevent<br>
> >> a show sitting in the queue for TOO long though).  The only change<br>
> >> involved<br>
> >> in my suggestion here would be that shows get assigned an HPR Episode# as<br>
> >> soon as they are ready for the queue rather than when they are actually<br>
> >> released. That way, they can also appear immediately in a second<br>
> >> "unrestricted" feed, which simply presents the shows as they are added<br>
> >> for<br>
> >> those who are willing to opt-in to dealing with an uneven release<br>
> >> schedule.<br>
> >> That would allow the main Hacker Public Radio feed to keep going in lean<br>
> >> times as it does now, while at least some listeners would be hearing (and<br>
> >> hopefully providing feedback on) shows as they are submitted at the same<br>
> >> time.<br>
> >><br>
> >> It's been said that some people are already complaining that HPR releases<br>
> >> too many shows. If we continue to grow, we may even end up wanting to<br>
> >> have<br>
> >> some "tag based" feeds (e.g. a feed specifically limited to, say, "Linux"<br>
> >> topics, a feed specifically limited to "science" topics, a feed for just<br>
> >> "media" topics, etc.). I don't think we've hit the point where the inflow<br>
> >> of new shows is enough for that to be very useful just yet (though with<br>
> >> ~1200 shows so far, it might be worth experimenting with the archives and<br>
> >> one or two "topical" feeds to see how it looks).<br>
> >><br>
> >> Either way (or even both ways) I think the result would be the main queue<br>
> >> actually growing even more, with the addition of other channels allowing<br>
> >> submitters to be heard and thus making the growing latency of the main<br>
> >> queue less of an issue.<br>
> >><br>
> >> I'd also reiterate the suggestion of possibly doing multi-episode days on<br>
> >> the main feed (show in the queue for two months but also a new<br>
> >> contributor<br>
> >> that day? Double-feature time!) when the main queue grows to a sufficient<br>
> >> length, though if "too many shows in the feed" is really a problem<br>
> >> listeners are complaining about, I don't know if that would be<br>
> >> counterproductive or not.<br>
> >><br>
> >> Perhaps as an incentive for frequent contribution, having multiple shows<br>
> >> in<br>
> >> the backup queue or the main queue might bump up older shows by the same<br>
> >> host by a day or two each.  ("Show not coming out quickly enough for you?<br>
> >> Submit some more!")<br>
> >><br>
> >> _______________________________________________<br>
> >> Hpr mailing list<br>
> >> <a href="mailto:Hpr@hackerpublicradio.org">Hpr@hackerpublicradio.org</a><br>
> >> <a href="http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org" target="_blank">http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org</a><br>
> ><br>
> > - klaatu<br>
> ><br>
> > _______________________________________________<br>
> > Hpr mailing list<br>
> > <a href="mailto:Hpr@hackerpublicradio.org">Hpr@hackerpublicradio.org</a><br>
> > <a href="http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org" target="_blank">http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org</a><br>
Sounds a lot better to me. How do you propose the hosts choose their airdate?<br>
- klaatu<br>
Hpr mailing list<br>
<a href="mailto:Hpr@hackerpublicradio.org">Hpr@hackerpublicradio.org</a><br>
<a href="http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org" target="_blank">http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Thank You,<br>Patrick Dailey<br>