[Hpr] new show posting algorithm

Ken Fallon ken.fallon at gmail.com
Tue May 28 15:38:18 PDT 2013


I think the current queue is fair in so far as hosts who have
released, need to stand aside for those that haven't aired since they
have. So once you release you go back to the end of the queue.
Unfortunately the queue amounts to "${everyone in the universe} MINUS
${anyone who has released since I did}. So in principle it's fair but
in practice it isn't.

The worst part is that it is causing confusion, frustration and
leading to a sense of unfairness.

I think Klaatu nailed it with the rule "First in First out" but I
would suggest that be the only rule, with the caveat that you can pick
any available date/episode number. That way as soon as a show (final
FLAC, with complete show notes) is received, and is processed it is
given it's permanent date and show number. This would allow the *host*
to decide how to space out the episode, so that some times you might
leave a week between shows, eg: for a series, and other times release
them all in one block, eg: after attending a festival.

New hosts should not be jumped to the start of the queue as there
would be only a two week wait if we used this system on the current
queue. Your show will be available in the "dudeman" feed that releases
shows as soon as they are posted.

So looking at how that compares to the current system:
Rule 1 Time critical:
For urgent shows, you will need to swap the _slot_ with the person who
is scheduled. This means that if you have hprYYYY and you wish to have
hprBBBB then you two swap and everyone in between keep the same
number/date. If it's so important then the person will wish to swap,
if not then it's not that important.

Rule 2 Reserved Slots :
Record the show well in advance and reserve the date.

Rule 3 Scheduled Slots:
65% of our content is Scheduled slots so I agree with klaatu, so yes
the reservations (not the shows) have to go. They can continue to
submit shows and pick slots like everyone else, it's just that more
planning is involved.

Rule 4 Normal priority:
If you don't select a date then you will be allocated the first available slot.

Rule 5 Backup Shows:
I'd still like to have some backup shows so that epicanis has some
time to record a show after klaatu calls his cell.

Ken.

On Tue, May 28, 2013 at 10:51 PM, Klaatu <klaatu at straightedgelinux.com> wrote:
> Epicanus,
>
> I like the idea of tag based feeds. Sounds like a really cool idea, although I
> admit to having no clue how to implement it.
>
> As for the notion of multi-episode release days.... I would advise against it.
> I've been with HPR for a long time now, and I've seen surplus and surfeit; I
> wouldn't get too drunk on how many shows we have right now in queue because
> before you know it we will be calling your cell phone demanding shows because
> we have NOTHING to post tomorrow. It's happened before!
>
> I do believe the "new hosts" move to the top of the queue is a good idea; I
> forgot about that and I do think it's an important exception-to-every-rule
> rule.
>
> -klaatu
>
>
>
> On Tuesday, May 28, 2013 04:34:54 PM epicanis+hpr at dogphilosophy.net wrote:
>> > I know this is a much-discussed topic, but it's partly for that reason
>> > that
>> > I've been tracking the progress of an episode I submitted via FTP, trying
>> > to predict when it would actually be posted to HPR's feed. One show I
>> > posted on April 2nd to FTP has been "in queue" for 42 days and counting.
>> >
>> > I think that's too long for anyone's show to be in queue; I think it
>> > discourages contributors, I think it frustrates contributors, and I think
>> > it risks making mini-series episodes so far and few between that they
>> > become disjointed.
>>
>> 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).
>> > It seems to me that a simpler algorithm would help encourage contributors
>> > (both existing and new) to post shows. Here is my proposal:
>> >
>> > 1. First In, First Out
>> >
>> > 2. When possible, no repeated hosts within the same week
>> >
>> > 3. No reserved slots; shows with existing RSS feeds are re-broadcast only
>> > when there is no original HPR content waiting to be aired.
>> >
>> > 4. Special requests (for time-sensitive episodes) are the exception to
>> > every rule.
>> >
>> > Thoughts?
>>
>> (I'll start with the "thoughts", then throw in a suggestion or two at the
>> end...)
>>
>> 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.
>>
>> 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.
>>
>> (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.)
>>
>> 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.
>>
>> (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 twit.tv 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?")
>>
>> Here's one suggestion for the near future: more feeds.
>>
>> 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.
>>
>> 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).
>>
>> 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.
>>
>> 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.
>>
>> 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!")
>>
>> _______________________________________________
>> Hpr mailing list
>> Hpr at hackerpublicradio.org
>> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
> - klaatu
>
> _______________________________________________
> Hpr mailing list
> Hpr at hackerpublicradio.org
> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org




More information about the Hpr mailing list