[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:
Hi,

        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
 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
 list. 

	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.

	manoj
-- 
 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: