Re: Disputes between developers - draft guidelines
>>"Ian" == Ian Jackson <email@example.com> writes:
Man, talk about being talked down to.
Ian> DISPUTES BETWEEN DEVELOPERS
Ian> A *DRAFT* joint recommendation of the the Technical Committee, the
Ian> Project Leader and the Bug Tracking System Administrators.
Since this is not a technical issue, I do not think the
technical committee is the appropriate body to b doing this (though I
realize we can pontificate on anything we choose to.
Ian> If you really can't engage helpfully, for example because the other
Ian> Developer refuses constructive discussion, you can refer the question
Ian> to the Technical Committee (including, possibly, reassigning a bug
Ian> report to them) or the Project Leadership. If you do this, be
Ian> prepared to be told to go away and grow up !
If and only if the dispute is about technical issues. If it is
not, the technical committee has no jurisdiction.
Ian> If discussing the issue with all the relevant people hasn't produced a
Ian> conclusion and doesn't look like it will, the Technical Committee can
Can we, really?
Ian> 6. Bug report etiquette
Ian> Sometimes bugs are reported inappropriately; likewise, sometimes
Ian> maintainers close bug reports inappropriately. Bug reports are `todo
Ian> list' items for the whole Project; they should be closed when there is
Ian> rough consensus that the whole system is working as well as it could.
No. The BTS is a means of tracking problems with the package,
it is not a glorified PIM. There are better ways of keeping a TODO
You are also discounting the fact that a package maintainer is
often the person closest to th software, next to th authors, and may
have a better idea about the real status of the problem report.
Having spurious and incorrect reports cluttering up the BTS
helps no on; and makes it harder for volunteers to target effort.
Ian> * The bug was reported; the maintainer felt immediately that it was a
Ian> spurious bug report of some kind, and closed it, but the submitter
Ian> disagrees with the explanation and has reopened the report for
Ian> discussion. The matter should be debated until both Developers are
Both developres? What if the reporter is not a developer? Is
it OK to close the bug then?
In any case, generalization like this are often unsuited to
specific cases; and the determination needs to b made on a case by
case basis if the maintainer is justified in managing the TODO list
for his package, neh?
Ian> While a situation is being discussed, any relevant bug report(s)
Ian> should remain open. If a package maintainer closes your bug report,
Ian> you may reopen it if you wish to continue the discussion.
Ropening spurious bug reports is unlikely to be helpful. The
maintainer often does know better; and it is suboptimal to ignore
Ian> Note that while the Technical Committee is also happy to help resolve
Ian> disputes over individual bug reports,
Really? I recall we punted on th last such dispute.
I've finally figured out why airports make you walk so far out to get
to your plane. It's their way of giving your luggage a head start.
Manoj Srivastava <firstname.lastname@example.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C