This is my new constructive idea.

[Dale Worley]

On Sat, 2007-05-19 at 17:54 -0500, Andrew Rodland wrote:
> Stop. Stop, stop, stop. Hurting. Open. Source.
> 
> Reopen http://developer.pidgin.im/ticket/1134, then close it as "fixed" when 
> you can honestly say you did. Or close it as "wontfix" to tell the world in 
> plain terms that you don't think you need to serve your users.

I admit that I have no knowledge about the ongoing soap opera that is
Pidgin development -- but for once, that makes my opinions more
relevant, rather than less.

One of the difficulties of open source development is that much of it
happens in public, not in a hothouse where everybody already knows what
everybody is talking about.  In the case of issue tracking, it means
that writing a issue is more difficult, because the description has to
be comprehensible to someone who has minimal understanding of the
product.

In the case of 1134 referred to above, regardless of how important the
real problem is, it's a poor bug report because it's incomprehensible to
the uninitiated.  As far as I can tell, the real topic sentence is the
first sentence of the second paragraph ("Removing prpl-specific icons"),
and yet I still can't guess what it really means.

Please, if there are real problems, spend the time to write clear-headed
issue descriptions, so people who aren't initiated into kabbalah have
some hope of knowing what you're talking about.

As a second principle, there are times when there is a larger
"philosophic" issue (a question of overall design) and several concrete
issues which are examples of the philosophic issue.  The best practice
is usually to file all of the issues individually, and link them
together (in the appropriate manner for your bug tracker), because some
times the "correct" resolution of the general principle and some of the
specific cases are opposite (because of special situations).

Following these principles is important for an open source project -- it
makes the debate accessible to the public who is allegedly the
beneficiary of the project, and it helps to make clear what the question
is and why it is A Good Idea.  Borderline rants as the documented
version of a change request do not attract broad-based support.

I see that 1143 has been marked as "invalid", though the comments call
it a duplicate of 414.  I suppose it's possible that it is a duplicate,
but that requires considerable knowledge to tell. It's certainly
deficient in starting with a clear description of what the problem is,
though.  414 is better in terms of brevity, but still has a lot of
extraneous matter -- by my count only 9 words ("you cant see what
protocol is talking to you") of 41 describe the problem, and there's a
wad of problems with the writing itself.

Dale