[mythtv-users] Forum reminder and feature requests

[Richard Hulme]

On 09/05/14 08:38, Stephen P. Villano wrote:
>
> On 5/9/14, 2:27 AM, Paul Harrison wrote:
>> On Friday, 9 May 2014, 0:24, Matt Mossholder <matt at mossholder.com> wrote:
>>
>> On Thu, May 8, 2014 at 6:56 PM, Bill Meek <keemllib at gmail.com> wrote:
>>>> Now known as the: Archived Feature Request List. It was updated today
>>>> and says: "The new Feature Request Forum replaces this wiki page.
>>>> Please use it instead."
>>>>
>>>> --
>>>> Bill
>>> Eww. An opaque link to a forum site, on a wiki page titled "Feature
>>> Wishlist", under a single heading of "MythTV Feature Request Forum".
>>> Oh, and the word "Archived" added to the next section title. Not
>>> particularly obvious.
>>>
>>> I can see how facilitating discussion of features could be handy, but
>>> burying the wishlist in a forum just seems wrong. Might just be me.
>>>
>>> Oh well.
>>>
>>
>> Few of the devs read the wiki page because it was a mess and is difficult to add replies to requests without the whole thing becoming a complete mess.
>>
>> It's hoped the Feature Request forum will make it easier for users to add requests and discuss them or add support for a particular request. It is also hoped that potential developers will see a request and want to help get it added.
>>
>>
>> We are only doing things that many users have asked for in the past.
>>
>> The truth is we either adapt and modernise or the project dies.
>>
>> At the moment the doom mungers are winning and the project is on life support but the remaining devs do want to resurrect it so please be positve :)
>>
>> Paul H.
>>
>> _______________________________________________
>>
> With due respect, the wiki pages *are* a mess. If *anyone* is qualified
> to document the software, it most certainly is the developer base. It
> can be refined further from that base. Otherwise, none have a damned
> clue about what is correct.
>
> Adapt or modernize is true. Deal or die. Die, I'll be royally pissed
> off. Pissed off enough to not bother with any project devs from today
> are involved with. For, it turned into abandoned ware. Find a leader
> that listens to all and move forward. It isn't rocket science and I'm
> pretty damned sure you work for a living and understand our
> sociology-economic system!
>
> If I relied upon doom mongers, I and my teams would literally not be
> alive today. Idiots listen to the "conventional wisdom", wise people
> take risks and adapt and move forward based upon learned lessons.
> The reality is, MythTV is a good product. It can be better, that is a
> function of both developer capability *and* userbase
> suggestions/contributions.

It should be obvious but just for those that don't get it:

-----------------------------------------
  Stephen's reply is tongue-in-cheek!
-----------------------------------------

Some people might think he was being serious by suggesting that the 
developers are the only ones who should/can contribute to the project.

He is right that we have a day-jobs,  That's what we get paid for and 
therefore what we *must* make time for.  Because we get paid, we work on 
things that maybe don't interest us too much.

We don't get paid a penny for working on MythTV and the time we spend on 
it comes out of our non-working time that we divvy up between family, 
friends, eating, sleeping and any other hobbies we might have.

What should make it obvious that Stephen wasn't being serious is the 
conclusion that the it's the developers responsibility to give up every 
second of their free time (and writing good, stable software that is all 
things to all people and works perfectly takes a *long* time) to work 
exclusively on other people's problems because those people demand it. 
That's those people who are paying so much for the results.

So, what Stephen's trying to say is this:

Work with the developers.  Explain what could be improved.  If you can't 
do it from a technical position, explain how the changes would appear to 
the end-user.  If the developer suggests that changing it would break 
something for others, go back and see how else it could be changed so as 
not to break something else.

If the documentation is wrong or out-dated and the observed behaviour 
doesn't match the documented behaviour, perhaps ask whether the observed 
behaviour is correct.  If it is, update that bit of the documentation. 
Most of the documentation is aimed at end-users, so you don't need to be 
a programmer.

Ask, and you might get.  Demand and insult, and you almost certainly won't.

Richard.