tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Sexton" <gsex...@mhsoftware.com>
Subject RE: never say never...
Date Tue, 21 Feb 2006 00:03:32 GMT

> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org] 
> Sent: Monday, February 20, 2006 4:02 PM
> To: Tomcat Developers List
> Subject: Re: never say never...
> 


> I agree that closing bug reports without an explanation is rarely, if
> ever helpful. A few lines explaining why the bug is invalid / won't be
> fixed would help enormously.

I think everyone is in agreement here.

> 
> That being said, having spent that last couple of years fixing bugs it
> is immensely frustrating when having closed a bug report as invalid
> (with an explanation and where appropriate a reference to the spec) it
> is re-opened with a comment that clearly indicates that the person
> re-opening the bug report hasn't bothered to read the previous
> comments or the spec.
> 
> There is an argument that goes along the lines of "If the person
> creating the bug report can't be bothered to read the spec / do some
> basic fault finding / provide enough information to reproduce the
> fault / read http://tomcat.apache.org/bugreport.html etc why should I
> be bothered to explain things to them?". Whilst I do not agree with
> this view personally, I can see how people have reached this point and
> I do understand the frustration they feel.

Having a cycle of 4-8 iterations where a person asks why its resolved
invalid, and a committer re-marks it resolved invalid without comment
doesn't seem like it would reduce frustration on the part of the committer.
It seems to me they would just get angrier on each iteration.

Don't misunderstand me. I'm certainly not saying a committer shouldn't say
"This is non-compliant and will not be addresed" or "We comply with the
spec, and we will not be expanding the application to meet your specific
need". These are legitimate responses.  When the specification is involved,
it would be nice to reference the relevant part of the specification. When
committers use emotionally charged terms with no technical basis, or just
reject things out of hand without explanation its not fair.

> > There won't be courtesy until those people who are the 
> worst offenders are
> > punished in some manner, or have their status as committers 
> revoked. After
> > all, why should they behave when there is no consequence?
> I don't think that punishment is the answer. If you feel someone is
> discourteous point it out (privately or publicly - your choice) and
> ask them to modify their behaviour. Above all, don't descend to their
> level.

This is how things should be done there is just one small flaw. Those people
who are the worst offenders in this matter are pretty much unaffected by
this approach. If people consistently don't respond to that approach (which
should be first), then there needs to be some recourse. For example, a
popular book recommends this approach to conflict resolution:

1)	Approach the person directly. If that doesn't work.
2)	Approach the person with others as witnesses to verify what is said.
If the person still doesn't respond:
3)	Take the person before the community. If the person still doesn't
respond.
4)	Eject the person from your community and have nothing further to do
with them.

While your recommendation is sound, and is indeed step 1 as outlined above,
by itself it is not enough. There need to be steps to take if the person
doesn't respond.


George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
  


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message