[Hpr] Hpr Digest, Vol 56, Issue 21

Patrick Dailey pdailey03 at gmail.com
Wed May 29 08:33:31 PDT 2013


Has Klaatu's show legitimately been in the queue for that long or did it
somehow slip through the cracks?

On Wed, May 29, 2013 at 9:59 AM, <hpr-request at hackerpublicradio.org> wrote:

> Send Hpr mailing list submissions to
>         hpr at hackerpublicradio.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
>
> or, via email, send a message with subject or body 'help' to
>         hpr-request at hackerpublicradio.org
>
> You can reach the person managing the list at
>         hpr-owner at hackerpublicradio.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Hpr digest..."
>
> Today's Topics:
>
>    1. Re: new show posting algorithm (epicanis+hpr at dogphilosophy.net)
>    2. Re: new show posting algorithm (Klaatu)
>    3. Re: new show posting algorithm (Ken Fallon)
>    4. Re: new show posting algorithm (Klaatu)
>
>
> ---------- Forwarded message ----------
> From: epicanis+hpr at dogphilosophy.net
> To: hpr at hackerpublicradio.org
> Cc:
> Date: Tue, 28 May 2013 16:34:54 -0400
> Subject: Re: [Hpr] new show posting algorithm
> > 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!")
>
>
>
>
> ---------- Forwarded message ----------
> From: Klaatu <klaatu at straightedgelinux.com>
> To: hpr at hackerpublicradio.org
> Cc:
> Date: Tue, 28 May 2013 16:51:52 -0400
> Subject: Re: [Hpr] new show posting algorithm
> 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
>
>
>
>
> ---------- Forwarded message ----------
> From: Ken Fallon <ken.fallon at gmail.com>
> To: klaatu at straightedgelinux.com
> Cc: "hpr at hackerpublicradio.org" <hpr at hackerpublicradio.org>
> Date: Wed, 29 May 2013 00:38:18 +0200
> Subject: Re: [Hpr] new show posting algorithm
> 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.netwrote:
> >> > 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
>
>
>
>
> ---------- Forwarded message ----------
> From: Klaatu <klaatu at straightedgelinux.com>
> To: "hpr at hackerpublicradio.org" <hpr at hackerpublicradio.org>
> Cc:
> Date: Wed, 29 May 2013 09:59:16 -0400
> Subject: Re: [Hpr] new show posting algorithm
> 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.netwrote:
> > >> > 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
>
>
>
> _______________________________________________
> Hpr mailing list
> Hpr at hackerpublicradio.org
> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
>
>


-- 
Thank You,
Patrick Dailey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://hackerpublicradio.org/pipermail/hpr_hackerpublicradio.org/attachments/20130529/0fb12170/attachment-0006.html>


More information about the Hpr mailing list