[mythtv] mythtv trac rules (Was Re: Ticket #11221: The use of OpenAndUnlink() in mainserver.cpp::DeleteFile() prevents the use of CIFS)

[f-myth-users at media.mit.edu]

    > Date: Tue, 06 Nov 2012 19:33:05 -0500
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

    > On 11/06/2012 03:06 AM, Greg G. wrote:
    > > On 06.11.2012 08:07, Chris Bannister wrote:
    > >> On Mon, Nov 05, 2012 at 04:38:51PM +0100, Greg G. wrote:
    > >>> Ok knowing that the mythtv folks don't like bug discussion in Trac, I
    > >>> subscribed to mythtv-dev.
    > >> Huh? Shouldn't all information about a bug be kept in one place?
    > > I would agree, but in the past this community just chose to handle it
    > > differently so I will abide those rules. But perhaps this policy has
    > > changed?

    > The ticket should have usable information that doesn't require the 
    > developer who handles it to read through hundreds of messages before 
    > handling it.  If I have 30min to work on MythTV one evening, I won't 
    > even go near a ticket with lots of messages that require lots of reading 
    > because it would take up all my MythTV time, and I won't get any fix in 
    > place, and I will then forget what I found out before next time I get 
    > some MythTV time, so I'd have to start over.  Instead, when there's 
    > discussion required--versus information that will help the developer 
    > looking at the ticket--it should be had on the list and then results of 
    > the discussion summarized on the ticket when actual progress is made.

How likely is it that Trac could be modified in such a way that
comments could be triaged (perhaps and probably not even by the same
person who might be working on the code) to mark some comments as "not
directly developer-relevant" or something?  The idea would not be to
delete comments, but to allow filtering them, so people could submit
additional comments that may or may not be relevant to a developer,
but allow filtering such comments so that a developer might later say,
"Only show comments someone has really deemed relevant to the bug."
Thus, "me-too's" or information that seemed relevant at the time but
later shown to be a distraction or a misdiagnosis could be suppressed
unless desired (or, for that matter, perhaps resurrected).

This might allow people to keep bug-specific discussion with the bug,
instead of breaking it up across Trac and the mailing lists, and also
be less confusing to newcomers (many of whom are familiar with using
the bug-reporting system to hold -all- the discussion of the bug),
without overloading developers---assuming we have enough qualified
volunteers to triage the comments.  (And whether the default for a
newly-submitted comment to be deemed "developer-worthy" or "not
developer-worthy" might depend on volume & triage.)

I guess this would be similar to adding a reputation system (or at
least a rating system) to Trac comments.  (Hopefully one that's not
so general that we go down the Slashdot rathole. :)