[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Disputes between developers - draft guidelines

>>"Ian" == Ian Jackson <ian@davenant.greenend.org.uk> writes:

        Man, talk about being talked down to. 


 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
 Ian> decide.  

	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
 Ian> happy.

	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
 that fact. 

 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   <srivasta@debian.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

Reply to: