[mythtv-users] Feature request page on wiki

[Michael Watson]

On 29/01/2012 5:02 AM, Michael T. Dean wrote:
> On 01/27/2012 06:35 AM, blind Pete wrote:
>> On Tue, 24 Jan 2012, Michael T. Dean wrote:
>>> On 01/23/2012 02:42 AM, Pieter De Wit wrote:
>>>> On 23/01/2012 16:36, Raymond Wagner wrote:
>>>>> On 1/22/2012 19:50, Pieter De Wit wrote:
>>>>>> Please don't take this in the wrong light, but who, from the dev team,
>>>>>> looks at the "Feature Request" page on the wiki ?
>>>>> You can always check the wiki edit history.  The simple fact is that
>>>>> MythTV is written by unpaid volunteers, and unpaid volunteers are only
>>>>> going to work on things that they have a personal use for, or otherwise
>>>>> interest them.  Most have their own local TODO lists they want to get
>>>>> done anyway.  Too many people thinking up ideas, and not enough actually
>>>>> doing them, plus the complaint I've voiced in the past about a big long
>>>>> list in a wiki not being easy to sift through.
>>>> Ok - so how about relaxing the rules around feature requests on the bug
>>>> tracker ?
>>> I can't find the tickets I'm actually trying to work on/reference as
>>> originals for duplicate tickets/point out on list/... as it is.  The
>>> last thing we need is hundreds of new "tickets" for things that aren't
>>> even bugs.  Our bug tracker is our bug tracker and only that.  (And,
>>> really, even now, it either needs a good cleanup--like starting over--or
>>> some much better search capabilities.  It's gotten too large to be
>>> useful--which is why we're so adamant about discussion /not/ occurring
>>> on the bug database.)
>> Do you want a two stage system?  Stage one (this list), "I have
>> a problem", stage two, "That really is a bug, it goes on the
>> tracker".  There will be less public feedback, but there seems to
>> be more of a shortage of devs rather than public.
> Well, some people (especially those who aren't subscribed to the list)
> will always submit bug reports directly.  Those, however (even if
> they're invalid tickets), aren't nearly as big a problem as discussions
> or "me toos" or "still seeing this" or "has anyone made progress on
> this" type stuff going into the bug database.
>
> My main point, though, was just that we don't want to bury important
> bugs underneath a blanket of feature requests and wishes, so that devs
> won't be able to find what they need.  If you look at the sheer number
> of feature requests/wishes on the wiki page--and remember that Raymond
> Wagner has done a /lot/ of cleanup/consolidation/deletion of ones that
> have been submitted--you'll see that they would easily outnumber our
> open bugs.
>
>>>>     Easier to manage ? I personally agree with you, imaging me
>>>> trying to help.....no idea where to start. Perhaps the wiki can be used
>>>> as a brain dump for the ideas in the bug tracker ?
>>> I'd be OK with a completely separate tracker for feature
>>> requests--something like Ubuntu's Brainstorm or whatever
> And, FWIW, we're looking into a separate-tracker approach, again.  Now
> that we should be moving back to our primary hardware soon, we can
> probably get things set up "before long".
>
FWIW, I think users should be advised to subscribe to this list to 
discuss new feature requests before adding a new Feature request, many 
of the features desired may already be available through other avenues, 
also the new desired feature may be discussed for its merits prior to 
cluttering up the feature request page.