[Hpr] new show posting algorithm

Klaatu klaatu at straightedgelinux.com
Tue May 28 13:51:52 PDT 2013


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




More information about the Hpr mailing list