[Hpr] new show posting algorithm

Klaatu klaatu at straightedgelinux.com
Wed May 29 06:59:16 PDT 2013


On Wednesday, May 29, 2013 12:38:18 AM Ken Fallon wrote:
> 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

Sounds a lot better to me. How do you propose the hosts choose their airdate?

- klaatu




More information about the Hpr mailing list