[Hpr] Vote on removing non HPR shows.

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


One last thing I remember from usenet newgroup votes (those were the
old days, eh?) was that voting in the thread before it's really decided
to have a vote makes a thread unreadable. Wait and see if it's going to
get to that, and then create an email address for the occasion...
---
DG

PS, Matthew is right, it is a wonderful problem to have...

On Wed, 10 Oct 2012 14:22:56 -0400
dg <dg at deepgeek.us> wrote:

> {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





More information about the Hpr mailing list