[Hpr] Vote on removing non HPR shows.

dg dg at deepgeek.us
Wed Oct 10 11:22:56 PDT 2012


{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





More information about the Hpr mailing list