[mythtv] thoughts about the "mythtv sucks" comments... " was "video sources"

[hendrixski]

>>> I guess what i'm trying to say is that in quite a few areas of myth you
>>> end up needing a lot of background knowledge. Would these sessions of
>>> yours help with this? That I don't know....
>>>       
>> Ubuntu has a TON of training opportunities to turn newbies into
>> valuable contributors, and then sessions to turn valuabla contributors
>> into full blown developers.
>>
>> Would it help?  Shall we find out?  Who's up for giving it a try?
>>     
> You know, there's this thing that we used to do in the olden days when
> dinosaurs still stalked the earth. It's called documentation. 

Documentation is good for self-training.  But aside from self-training 
there exists also the option of organized training events.  Let's 
_assume_ that the documentation + lists/irc is sufficient for anybody to 
teach themselves how to code for mythtv. The question at hand is : would 
it be worth it to hold a "class" in *addition* to all that, which 
teaches a group of people how to get better at mythtv development, and 
gives a more complete picture (including background knowledge) than 
documentation alone could.

Daniel Kristjansson said Ubuntu can do this because of having a 
billionaire-backed budget.  I would argue that perhaps Canonical is 
saving time and money on this by getting better contributions, that save 
time for the core developers.  If mythtv devs could save time by 
receiving better patches that require fewer corrections, would any of 
them like to invest a little time teaching contributors in order to 
achieve this long-term time-saving?

Stuart Auchterlonie's response indicates that we don't know if it would 
in fact save time, or would successfully give people the background 
knowledge needed for certain tasks, so I'll just politely bring this 
back up: Would we like to try it once or twice and find out?

Classroom ideas include: "how to better debug mythtv with valgrind", 
"how to do X, Y and Z, in multirec", "About DVB implementations", 
"Architecture Q&A" etc. etc.

 - Hendrixski


-- 
 - Hendrixski

How to ask questions:
 * Do your homework: google it, search archives from lists and forums
 * Ask on the appropriate list or forum using a meaningful header
 * Be precise, impersonal, to the point, state your goal, and say "please" and "thank you"

How to answer questions:
 * Verify what they're asking about, turn bad questions into good ones
 * Give information, ask if it answers their question.  Rinse & Repeat
 * Not all manuals are created equal! link to your favorite one and say "Read This Fine Manual"