[mythtv] [mythtv-commits] Ticket #6899: Detect programs damaged by their broadcasters and notify the user for rescheduling

[Michael T. Dean]

On 03/01/2010 04:37 PM, f-myth-users wrote:
> I agree with just about everything you've said.
>
> (Surprise! :)
>
> [I could say, "But I'll maintain it!" but obviously that won't scale
> and I could get hit by a bus tomorrow.]
>
> Here's a suggestion, in that case:  Would it be reasonable to have a
> "user-contributed scripts" area in the wiki?

This sounds like a good idea.  Just please make sure to have sufficient 
warnings/disclaimers that any reasonable person should realize that 
these are all use-at-your-own-risk things and that they may be removed 
if found to cause more problems than they solve.

>    The only way somebody's
> going to find the patch in Trac is via a Google search, and it's still
> unlikely that they'll really be able to figure out which tickets have
> patches they could use, etc.  Putting them in the wiki makes it at
> least a little easier for people to find large collections of useful
> things without searching all over the net for them (and discovering
> that something useful is gone because some random website vanished).
>
> [I'm thinking of something with the prominence of the various links on
> the toplevel page, e.g., "User-contributed code" or something, perhaps
> under/near "External Links".  (Yes, it'll mess up the even-number-of-items
> layout there; oh well. :)  A few minutes of Googling plus targeted
> looking-around on the wiki didn't find such a thing, so even if it's
> there, it's probably not placed in a way that most people will find
> it.  The Knowledge Base and Feature Wishlists sections don't seem to
> have such a thing in them, for example.]
>    

For now start a page, then we can look at where to link from.  Just 
having the page will make things a lot easier for people to find 
(especially once the link starts getting posted a lot for Google, 
etc.).  There are actually a ton of scripts, etc. in the wiki now that 
probably should be aggregated under the new section you're talking 
about, too, so eventually, it may make it easier for users (as well as 
"maintainers") to find the scripts to use (or review).

> Also, something that might help:  The devos should decide exactly what
> role contrib should play, and document it (probably in a README in
> contrib).  How supported should stuff in it be?  Why should/shouldn't
> something be in there?  Right now, it's really unclear to me what the
> criteria are, or if those criteria are stable over time.

My plan is to clean it up a bit, first, then come up with a unified 
plan.  IMHO, many of the things in there wouldn't qualify under rules I 
would like to propose for it, so I think we need to clean it up (by 
re-doing those things that are useful in a supportable way and getting 
rid of the unsupportable versions) first.

>    If the idea
> is "we never want to maintain anyone else's stuff", then contrib
> should be -empty-, and it's not, so is the stuff there just stuff that
> snuck in before anyone really made up their minds?
>
> [You might also put a README in the distributed contrib dir pointing
> at the user-contributed-scripts section in the wiki, as a reminder as
> to where else one might easily find various user-contributed stuff;
> I'm fairly sure there are always going to be people who might start in
> contrib but will need be reminded, "Oh, wait, there's another pile of
> things I should look at as well".  That would have included me, when
> I started.]
>    

I'll do that once someone creates the section and it looks "ready."

> The basic thing I'm trying to avoid is having 50 bits of code on 50
> different websites; a wiki allows community-controlled modification of
> the code and also community-controlled commentary, like "this tool is
> great -but- watch out if your environment is like -this- or it'll
> screw you...", so doing this right, and on the MythTV wiki, has the
> potential to work out -better- than putting something into contrib,
> even if contrib was always maintained.
>    

Sounds like you already planned for disclaimers.  :)

Thanks,
Mike