Re: Disputes between developers - draft guidelines
Before I comment on any of the actual points below, I'd like to make some
statements first.
I have been seen in public reopening bugs that have been incorrectly closed by
bad changelog entries. I have done this with my owner@bugs hat on. However,
this wrong. I still feel very strongly on this issue, but I should have done
it as a converned(very) developer.
As an owner@bugs person, I feel that owner@bugs should be hands off in any
decisions that regard the content of the bugs in our system. We can do code,
we can otherwise maintain the system. However, any decisions as to the state
of various bugs(other than bugs.debian.org and debbugs) stored in the system
should be left to those invovled.
Also, for the record, shortly before this email was sent by Ian, I closed a
bug(with a rather terse reply) filed by Ian against dpkg(the whole md5sum
issue with 1.10). I stand by my email. If Ian would have done the research
first, he would have seen that all his complaints had been previously
discussed.
<rant>Also, as part of the above, I am annoyed when other developers don't
use(or know how to use) the tools that are available. Especially if so called
other developers are part of some semi-functional technical body, and should
know better</rant>
On Wed, 16 Oct 2002, Ian Jackson wrote:
> DISPUTES BETWEEN DEVELOPERS
>
> A *DRAFT* joint recommendation of the the Technical Committee, the
> Project Leader and the Bug Tracking System Administrators.
As stated above, I do not feel that the BTS Admins should have any say in
this.
> 2. Distinguish flameage from technical disputes and procedural errors
>
> Distinguish problems working constructively due to an interpersonal
> dispute (`not getting along'), from technical disagreements about how
> software should work, or procedural disagreements about whether some
> particular thing should or should not be done.
Too many large words. Brain on overload. Simplify this whole paragraph.
Not to mention it's not a paragraph, but a single runon sentence.
> If you feel another Developer has erred, by failing to go about things
> in the right way, you should of course tell them about it. But,
> please try to make your message helpful and friendly. Probably they
> didn't know about the rule in question, or understand it differently.
> If you can refer the other Developer to some documentation saying when
> they should and should not do something, do so.
Yes, by putting "closes: #####" or "fixed in nmu. closes: ####" in
changelogs.
> 6. Bug report etiquette
>
> Sometimes bugs are reported inappropriately; likewise, sometimes
> maintainers close bug reports inappropriately. Bug reports are `todo
> list' items for the whole Project; they should be closed when there is
> rough consensus that the whole system is working as well as it could.
Yes, like 164889. The issue has been discussed, and resolved. You didn't do
any research before sending off your report. I have the right to be annoyed
when someone who is supposed to know better doesn't know how to do things the
correct way.
> * The bug was reported; the maintainer felt immediately that it was a
> spurious bug report of some kind, and closed it, but the submitter
> disagrees with the explanation and has reopened the report for
> discussion. The matter should be debated until both Developers are
> happy.
The issue at hand has been discussed. You have brought no knew arguments to
the table. Absolutely none. Why should we(dpkg developers) waste time
beating a dead horse?
> At no other time should you play `bug report tag' with anyone else.
> If someone makes a change to a bug report status which you disagree
> with you should *discuss* the matter with them but *not* immediately
> undo their action in the BTS, except to reopen the bug to stop it
> getting lost. If you are unable to reach a conclusion through
> constructive discussion, you should ask for outside help with
> resolving your dispute, as outlined above.
Again, you're overstepping the bounds of the package maintainers.
As a whole, you'd have some, in your opinion, bad reactions to things you've
tried to do. So, instead of trying to find out why, you go and pen this whole
long document to try and force your agenda thru political means.
For comparison, see Santiago's mail to -vote about GR and spam.
Reply to: