[Hpr] Hpr Digest, Vol 49, Issue 5

Fifty OneFifty fiftyonefifty at linuxbasement.com
Wed Oct 10 14:22:36 PDT 2012


On rereading my last post this morning, it's apparent to me that I might
have been both more clear and more tactful.  First off, I don't want to see
Linux In the Shell (I'm learning a lot) or TGTM go anywhere.  It does seem
however that the queue for original content other than those two shows
often seems to remain static for weeks on end.  Partly this was due I think
to the "hurry up and broadcast all of the Full Circle last year's Oggcamp
eps before this year's Oggcamp" and (due respect to Pokey and Johnathan,
who worked very hard) every talk from NELF.  This was all excellent content
that was available elsewhere.  I only make this observation because we
could easily fill the schedule just by rebroadcasting presentations from
all the available fests.  On that point, perhaps we could only do a
sampling of talks after a fest and let people know where the rest can be
found.  We would always have the option to play more talks when the queue
gets short.

I don't include Ken's interviews from the recent Oggcamp, and they were
some of the best bits of podcasting I've heard.  Not that I minded, but
playing them consecutively did have the  effect of bringing the queue to a
halt once again.  I do think the RMS interview should move to the top of
the queue as soon as it is ready (no pressure pokey).

5150



On Wed, Oct 10, 2012 at 1:23 PM, <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. I canceled the google calendar (Ken Fallon)
>    2. Vote on removing non HPR shows. (Ken Fallon)
>    3. Re: Vote on removing non HPR shows.
>       (epicanis+hpr at dogphilosophy.net)
>    4. Re: Vote on removing non HPR shows. (Matthew K)
>    5. Re: Vote on removing non HPR shows. (dg)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 10 Oct 2012 09:33:05 +0200
> From: Ken Fallon <ken at fallon.ie>
> To: hpr at hackerpublicradio.org
> Subject: [Hpr] I canceled the google calendar
> Message-ID: <20121010093305.14693ed7 at dell>
> Content-Type: text/plain; charset=US-ASCII
>
> Hi All,
>
> Sorry about the spam but I canceled the google calendar invite as it
> fails to provide a recurring meeting that is "the Saturday before the
> first Monday of the month.
>
> Ken.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 10 Oct 2012 10:39:17 +0200
> From: Ken Fallon <ken.fallon at gmail.com>
> To: hpr at hackerpublicradio.org
> Subject: [Hpr] Vote on removing non HPR shows.
> Message-ID: <20121010103917.299288ea at dell>
> Content-Type: text/plain; charset=US-ASCII
>
> TOPIC CHANGE from "Re: [Hpr] Hpr Digest, Vol 49, Issue 2"
>
> On Tue, 9 Oct 2012 23:08:39 -0500
> Fifty OneFifty <fiftyonefifty at linuxbasement.com> wrote:
>
> > Ken,
> >
> > I don't know what to say (though I have made what I thought were
> > humorous comments on other podcasts).  I submitted a full week's
> > worth of content in July (3 original shows and two syndicated I was
> > involved in)  that are still a good two weeks out of showing up on
> > HPR.  I loved all you original stuff from OggCamp, and catching up on
> > everything from last year, but I think we are getting a rep for stale
> > shows you can find elsewhere  (no intended offense to our syndication
> > partners).   Expect a show on my ODroidX (which I am sure many folks
> > are tired of hearing about) AND gv-20 very soon
> >
> > 5150
>
> Hi 5150,
>
> I appreciate where you are coming from but if you look at the queue
> you'll see that it's made up of shows from what I'd consider HPR
> regulars.
>
> Ahuka will have released 12 shows this year.
> Frank_Bell 7 shows this year
> mrgadgets 4 shows this year (21 last year)
> Seetee 5 shows this year
> sigflup 6 shows this year
> 5150 5 shows this year, not counting your appearances on the HPR
> Community news
>
> Which leaves two episodes from Door2DoorGeek and another from
> BuyerBrown. Neither can be classified as 'unknown' in the podcasting
> community. My email was a request to get new hosts or to get previous
> dormant hosts to send in new shows.
>
> Personally I think that the comments about stale content are unhelpful.
> The majority of HPR content is timeless, in so far as they are as valid
> today as they were when they were submitted. If any show is time
> sensitive, we can and do bump them up. The fact that your shows have
> not come out yet are as a result of a splurge of shows been submitted
> after the new year and been processed according to the scheduling rules.
>
> The only way to eliminate the queue quicker is to open the flood gates
> and let everything out as soon as it comes in. Which would mean a flood
> of shows a few times a year.
>
> The other option is to remove syndicated content. Since our last
> discussion on this topic we have dropped the Sunday Morning Linux
> Review. Which leaves:
>
> Syndicated Thursdays, providing 25 shows. And TGTM News HPR Tech
> Edition which is a subset of TGTM News itself, providing 21 shows. That
> is a total of 46 shows minus the 13 non syndicated shows in the queue,
> means that we would have run out of shows on the 20th of August.
>
> Following the discussions last time, I understood that the community
> wanted to maintain both shows but I may have been mistaken. I don't
> want to go over this again and again so if no-one objects I would like
> to have the community vote on whither to drop ST and/or TGTM news.
>
> I suggest that we open a poll starting at the beginning of the October
> HPR Community News recording (2012-11-03T19:00:00Z), running for a
> month and ending at the start of the November HPR Community  News
> recording (2012-12-01T19:00:00Z).
>
> Anyone that wishes to argue their point can do so in person on the
> October HPR Community News recording (2012-11-03T19:00:00Z), via
> recorded segments, or email transcript.
>
> Ken.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 10 Oct 2012 13:29:13 -0400
> From: epicanis+hpr at dogphilosophy.net
> To: hpr at hackerpublicradio.org
> Subject: Re: [Hpr] Vote on removing non HPR shows.
> Message-ID: <8250988.V5dQfOsaul at bunnies>
> Content-Type: text/plain; charset="us-ascii"
>
> > I appreciate where you are coming from but if you look at the queue
> > you'll see that it's made up of shows from what I'd consider HPR
> > regulars.
> > [...] My email was a request to get new hosts or to get previous
> > dormant hosts to send in new shows.
> >
> > Personally I think that the comments about stale content are unhelpful.
>
> You may be misinterpreting what 5150 meant by "stale" (either that or I
> am...)
> I don't think he means "too old", but rather "recycled" or "not 'fresh'"
> (i.e. not
> an "original" to HPR).  It sounds like you may actually agree with this,
> given the
> call for more hosts outside of the more productive handful who currently
> dominate
> the calendar. (As a "dormant" host myself until a few weeks ago, I
> naturally
> and self-interestedly approve...)
>
> > The majority of HPR content is timeless, in so far as they are as valid
> > today as they were when they were submitted. If any show is time
> > sensitive, we can and do bump them up.
>
> I keep thinking there's got to be an option between "demand to be put at
> the head of the queue immediately (due to timeliness or being new)" and
> "wait at the back of the line", though I can't actually think what it
> would be.
>
> It seems like there may be some unnecessary rigidity in the current
> approach though.  For example:
>
> > The only way to eliminate the queue quicker is to open the flood gates
> > and let everything out as soon as it comes in. Which would mean a flood
> > of shows a few times a year.
>
> "Either we release one show a day, five times per week, or we release them
> all
> at once?" Can't there be some middle path here?
>
> > The other option is to remove syndicated content. Since our last
> > discussion on this topic we have dropped the Sunday Morning Linux
> > Review. Which leaves:
> >
> > Syndicated Thursdays, providing 25 shows. And TGTM News HPR Tech
> > Edition which is a subset of TGTM News itself, providing 21 shows. That
> > is a total of 46 shows minus the 13 non syndicated shows in the queue,
> > means that we would have run out of shows on the 20th of August.
>
> This implies that quite a large proportion of the shows are currently
> reruns
> from elsewhere. Although I usually end up skipping them myself (unless
> the summary/show notes suggest that the episode specifically covers
> some topic I have an interest in) I don't think it's a bad idea to have
> occasional
> promotions of shows from elsewhere that may be of interest to hackers,
> which hackers may not know of otherwise.  I wouldn't vote for merely
> getting rid of them, myself.
>
> [...](repasted slightly out of order here...)[...]
>
> > The fact that your shows have
> > not come out yet are as a result of a splurge of shows been submitted
> > after the new year and been processed according to the scheduling rules.
> [...]
> I think the problem may be that in the present situation, the existing
> rules and schedule have given HPR a bout of podstipation.
>
> At a rate of only 5 shows per week, one of which is "syndicated Thursdays"
> and seemingly about one or two per week are scheduled slots, that means
> that the regular calendar of everyone else is only going to move a few
> shows
> each week. The current calendar of 15 shows looks like it will take
> another month
> or more to get through - longer if your call for new hosts results in more
> new
> hosts jumping the queue (I think this IS good practice by the way,
> I'm not saying they shouldn't).
>
> For the majority (I think) of currently-contributing hosts who cannot
> reliably promise the time to contribute on a scheduled slot basis,
> a show produced and uploaded today could be sitting for months before
> the host gets any feedback (I don't know about anyone else, but that's
> the main thing that motivates ME). The incentive is more to put off
> doing a show for a few months to see if the queue goes down
> rather than do it now.
>
> My own suggestion: script the release rate to adjust based on the length of
> the queue, with the goal of keeping approximately one to two weeks of
> backlog. When the queue is short, release no more than now (five out of
> seven days, once per day). When it is long, add weekends. Longer still,
> release every twelve hours.  This seems like something that ought to
> be scriptable automatically based on the number of shows sitting in the
> queue directory.
>
> And, yes, I'll volunteer to work on that if anyone likes the idea and wants
> me to.
>
> > Following the discussions last time, I understood that the community
> > wanted to maintain both shows but I may have been mistaken. I don't
> > want to go over this again and again so if no-one objects I would like
> > to have the community vote on whither to drop ST and/or TGTM news.
>
> So to reiterate, my vote is: do not drop those shows.
> But DO look for other ways to get the queue flowing better.
> (Reducing the number of non-HPR shows may help, but I don't
> think their existence is the main problem.)
>
> Signed,
> A self-proclaimed Acknowledgement Courtesan
>
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 10 Oct 2012 11:09:17 -0700 (PDT)
> From: Matthew K <matt_hew at rocketmail.com>
> To: Ken Fallon <ken.fallon at gmail.com>,  "hpr at hackerpublicradio.org"
>         <hpr at hackerpublicradio.org>
> Subject: Re: [Hpr] Vote on removing non HPR shows.
> Message-ID:
>         <1349892557.33733.YahooMailNeo at web124701.mail.ne1.yahoo.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Too many shows? What a great problem to have!!! Is it really to the point
> where there are too many shows? Fantastic!
>
> My vote is, that I think Hacker Public Radio should be first and foremost
> for individuals (or groups of individuals) to post shows on topics they
> think would interest the community.
>
> If a syndicated group wants to put thier shows on the station, I think
> that is great; however, I feel that they should only play if there is
> nothing else in the queue. If I want to subscribe to something like the
> full circle podcast, it is already on the Internet somewhere else, and I
> could just subscribe to it there. I think we should just link to things
> like that rather than hosting duplicate content on HPR. They should only be
> used as "filler"when there is no show to play.
>
> If we really need to cut, I think the news shows, and summaries of shows
> could be cut out (or appended to other shows) on months where there is a
> glutton of shows. Also, combining multi-part episodes into a single episode
> before posting could help reduce show count.
>
> Matt
>
>
> >________________________________
> > From: Ken Fallon <ken.fallon at gmail.com>
> >To: hpr at hackerpublicradio.org
> >Sent: Wednesday, October 10, 2012 2:39 AM
> >Subject: [Hpr] Vote on removing non HPR shows.
> >
> >TOPIC CHANGE from "Re: [Hpr] Hpr Digest, Vol 49, Issue 2"
> >
> >On Tue, 9 Oct 2012 23:08:39 -0500
> >Fifty OneFifty <fiftyonefifty at linuxbasement.com> wrote:
> >
> >> Ken,
> >>
> >> I don't know what to say (though I have made what I thought were
> >> humorous comments on other podcasts).? I submitted a full week's
> >> worth of content in July (3 original shows and two syndicated I was
> >> involved in)? that are still a good two weeks out of showing up on
> >> HPR.? I loved all you original stuff from OggCamp, and catching up on
> >> everything from last year, but I think we are getting a rep for stale
> >> shows you can find elsewhere? (no intended offense to our syndication
> >> partners).?  Expect a show on my ODroidX (which I am sure many folks
> >> are tired of hearing about) AND gv-20 very soon
> >>
> >> 5150
> >
> >Hi 5150,
> >
> >I appreciate where you are coming from but if you look at the queue
> >you'll see that it's made up of shows from what I'd consider HPR
> >regulars.
> >
> >Ahuka will have released 12 shows this year.
> >Frank_Bell 7 shows this year
> >mrgadgets 4 shows this year (21 last year)
> >Seetee 5 shows this year
> >sigflup 6 shows this year
> >5150 5 shows this year, not counting your appearances on the HPR
> >Community news
> >
> >Which leaves two episodes from Door2DoorGeek and another from
> >BuyerBrown. Neither can be classified as 'unknown' in the podcasting
> >community. My email was a request to get new hosts or to get previous
> >dormant hosts to send in new shows.
> >
> >Personally I think that the comments about stale content are unhelpful.
> >The majority of HPR content is timeless, in so far as they are as valid
> >today as they were when they were submitted. If any show is time
> >sensitive, we can and do bump them up. The fact that your shows have
> >not come out yet are as a result of a splurge of shows been submitted
> >after the new year and been processed according to the scheduling rules.
> >
> >The only way to eliminate the queue quicker is to open the flood gates
> >and let everything out as soon as it comes in. Which would mean a flood
> >of shows a few times a year.
> >
> >The other option is to remove syndicated content. Since our last
> >discussion on this topic we have dropped the Sunday Morning Linux
> >Review. Which leaves:
> >
> >Syndicated Thursdays, providing 25 shows. And TGTM News HPR Tech
> >Edition which is a subset of TGTM News itself, providing 21 shows. That
> >is a total of 46 shows minus the 13 non syndicated shows in the queue,
> >means that we would have run out of shows on the 20th of August.
> >
> >Following the discussions last time, I understood that the community
> >wanted to maintain both shows but I may have been mistaken. I don't
> >want to go over this again and again so if no-one objects I would like
> >to have the community vote on whither to drop ST and/or TGTM news.
> >
> >I suggest that we open a poll starting at the beginning of the October
> >HPR Community News recording (2012-11-03T19:00:00Z), running for a
> >month and ending at the start of the November HPR Community? News
> >recording (2012-12-01T19:00:00Z).
> >
> >Anyone that wishes to argue their point can do so in person on the
> >October HPR Community News recording (2012-11-03T19:00:00Z), via
> >recorded segments, or email transcript.
> >
> >Ken.
> >
> >_______________________________________________
> >Hpr mailing list
> >Hpr at hackerpublicradio.org
> >http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
> >
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://hackerpublicradio.org/pipermail/hpr_hackerpublicradio.org/attachments/20121010/26cae88c/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Wed, 10 Oct 2012 14:22:56 -0400
> From: dg <dg at deepgeek.us>
> To: hpr at hackerpublicradio.org
> Subject: Re: [Hpr] Vote on removing non HPR shows.
> Message-ID: <20121010142256.13661f6b at squeeze0212.slc5.com>
> Content-Type: text/plain; charset=US-ASCII
>
> {I thought hard and long about this, so it's a little verbose...}
>
> I like to think about the HPR calendar as 260 shows a years, of which I
> put 33 or so....
>
> I think if it can be automated, that treating the que length to
> change policy is the best idea so far! I'd really be excited to
> see this executed as long as it could be automated so that Ken is not
> awash in thinking about rules on a daily basis. What would be the logic
> here, "if the wc of the ls is greater than 15 then (alternate routine
> goes here,)" in some script that is running on the server?
>
> If it is easier, might I suggest that if the que gets big, maybe TGTM
> tech edition might be put into the regular que until the que clears up?
> It's been a dozen newscasts (according to my stats under the webpage,)
> and I think that if I won any listeners from the HPR audience, they
> probably would have subscribed to my whole show at my webpage by now if
> they wanted a really fast delivery of my show.
>
> However, if it does go to a vote, might I make a few suggestions...
>
> 1) set a quorum. Since our audience is 5000, and the list membership is
> somewhat smaller, I do think it would be a good idea to say upfront "if
> we don't get x emails, then we won't consider it valid." This way, if
> people just don't care enough we won't have a small vocal minority put
> through something the entire audience does not like. I don't pretend to
> know upfront what a good number would be, but I think you get the idea.
>
> 2) Tell the audience in the community news section that "I am a big
> boy, and whatever the community wants I will go ahead with without
> taking any offense. I am honored to be listened to this much by the HPR
> community, but will understand if my verbosity is screwing
> things up for the schedule. If it is decided that I my show is taking
> up too much space in the que, and if I get 25 emails, I will publish
> a tech-only edition on my own webpage (IE, I will "fork" if the demand
> is right and it makes things easier all around.)
>
> 3) OTOH, It was out of respect for the founding crew that I created a
> tech-only edition, because those founders were apolitical. However, I
> am thinking that after a thousand episodes, times may have changed. So
> if we do have some kind of voting, may I respectfully request that the
> vote over TGTM news take this form, "I think TGTM news should a)
> continue it's current tech-only form b) have the full news+tech news
> cast" and a second question "I think TGTM news should a) only be run if
> the que is light b) run no matter what and c) kicked off the feed
> because it is too many shows a month." Of course, only if it is OK, I'm
> trying to use this opportunity to really discover what our listener-ship
> truly wants.
>
> 4) I'd volunteer to conduct the vote (ala "usenet volunteer
> votetakers",) however, I am obviously going to
> look helplessly biased over this. So if it goes to a vote, how about
> somebody volunteer so that Ken is *NOT* clobbered in a sea of emails.
>
> PS if it's only twice a month, it's just not a news program to me,
> which is why I never did the fortnightly thing.
>
> OK, thanks for listening to me about this, and thanks for having me in
> the HPR community!
> ---
> DeepGeek
>
>
> On Wed, 10 Oct 2012 13:29:13 -0400
> epicanis+hpr at dogphilosophy.net wrote:
>
> > > I appreciate where you are coming from but if you look at the queue
> > > you'll see that it's made up of shows from what I'd consider HPR
> > > regulars.
> > > [...] My email was a request to get new hosts or to get previous
> > > dormant hosts to send in new shows.
> > >
> > > Personally I think that the comments about stale content are
> > > unhelpful.
> >
> > You may be misinterpreting what 5150 meant by "stale" (either that or
> > I am...) I don't think he means "too old", but rather "recycled" or
> > "not 'fresh'" (i.e. not an "original" to HPR).  It sounds like you
> > may actually agree with this, given the call for more hosts outside
> > of the more productive handful who currently dominate the calendar.
> > (As a "dormant" host myself until a few weeks ago, I naturally and
> > self-interestedly approve...)
> >
> > > The majority of HPR content is timeless, in so far as they are as
> > > valid today as they were when they were submitted. If any show is
> > > time sensitive, we can and do bump them up.
> >
> > I keep thinking there's got to be an option between "demand to be put
> > at the head of the queue immediately (due to timeliness or being
> > new)" and "wait at the back of the line", though I can't actually
> > think what it would be.
> >
> > It seems like there may be some unnecessary rigidity in the current
> > approach though.  For example:
> >
> > > The only way to eliminate the queue quicker is to open the flood
> > > gates and let everything out as soon as it comes in. Which would
> > > mean a flood of shows a few times a year.
> >
> > "Either we release one show a day, five times per week, or we release
> > them all at once?" Can't there be some middle path here?
> >
> > > The other option is to remove syndicated content. Since our last
> > > discussion on this topic we have dropped the Sunday Morning Linux
> > > Review. Which leaves:
> > >
> > > Syndicated Thursdays, providing 25 shows. And TGTM News HPR Tech
> > > Edition which is a subset of TGTM News itself, providing 21 shows.
> > > That is a total of 46 shows minus the 13 non syndicated shows in
> > > the queue, means that we would have run out of shows on the 20th of
> > > August.
> >
> > This implies that quite a large proportion of the shows are currently
> > reruns from elsewhere. Although I usually end up skipping them myself
> > (unless the summary/show notes suggest that the episode specifically
> > covers some topic I have an interest in) I don't think it's a bad
> > idea to have occasional promotions of shows from elsewhere that may
> > be of interest to hackers, which hackers may not know of otherwise.
> > I wouldn't vote for merely getting rid of them, myself.
> >
> > [...](repasted slightly out of order here...)[...]
> >
> > > The fact that your shows have
> > > not come out yet are as a result of a splurge of shows been
> > > submitted after the new year and been processed according to the
> > > scheduling rules.
> > [...]
> > I think the problem may be that in the present situation, the existing
> > rules and schedule have given HPR a bout of podstipation.
> >
> > At a rate of only 5 shows per week, one of which is "syndicated
> > Thursdays" and seemingly about one or two per week are scheduled
> > slots, that means that the regular calendar of everyone else is only
> > going to move a few shows each week. The current calendar of 15 shows
> > looks like it will take another month or more to get through - longer
> > if your call for new hosts results in more new hosts jumping the
> > queue (I think this IS good practice by the way, I'm not saying they
> > shouldn't).
> >
> > For the majority (I think) of currently-contributing hosts who cannot
> > reliably promise the time to contribute on a scheduled slot basis,
> > a show produced and uploaded today could be sitting for months before
> > the host gets any feedback (I don't know about anyone else, but that's
> > the main thing that motivates ME). The incentive is more to put off
> > doing a show for a few months to see if the queue goes down
> > rather than do it now.
> >
> > My own suggestion: script the release rate to adjust based on the
> > length of the queue, with the goal of keeping approximately one to
> > two weeks of backlog. When the queue is short, release no more than
> > now (five out of seven days, once per day). When it is long, add
> > weekends. Longer still, release every twelve hours.  This seems like
> > something that ought to be scriptable automatically based on the
> > number of shows sitting in the queue directory.
> >
> > And, yes, I'll volunteer to work on that if anyone likes the idea and
> > wants me to.
> >
> > > Following the discussions last time, I understood that the community
> > > wanted to maintain both shows but I may have been mistaken. I don't
> > > want to go over this again and again so if no-one objects I would
> > > like to have the community vote on whither to drop ST and/or TGTM
> > > news.
> >
> > So to reiterate, my vote is: do not drop those shows.
> > But DO look for other ways to get the queue flowing better.
> > (Reducing the number of non-HPR shows may help, but I don't
> > think their existence is the main problem.)
> >
> > Signed,
> > A self-proclaimed Acknowledgement Courtesan
> >
> > _______________________________________________
> > Hpr mailing list
> > Hpr at hackerpublicradio.org
> > http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Hpr mailing list
> Hpr at hackerpublicradio.org
> http://hackerpublicradio.org/mailman/listinfo/hpr_hackerpublicradio.org
>
>
> End of Hpr Digest, Vol 49, Issue 5
> **********************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://hackerpublicradio.org/pipermail/hpr_hackerpublicradio.org/attachments/20121010/10208aa0/attachment-0006.html>


More information about the Hpr mailing list