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

Re: Disputes between developers - content, draft #4


        Well, here is a detailed critique. Unfortunately, there is a
 lot of ground to cover between our positions; here is a start.

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

 Ian> A *DRAFT* recommendation by the Technical Committee. 

	Which has not yet said it approved of this document being
 presented by them.

 Ian> 1. Motivation

 Ian> Debian is a very large project.  We will inevitably disagree, and
 Ian> occasionally get annoyed with each other.  To allow us to work well
 Ian> together a bit of give and take is needed, and we must be willing to
 Ian> present coherent reasons for our views, and to listen to and engage
 Ian> with counterarguments.

	Well, belabouring the obvious, I would think, we are all
 supposed to be well nigh adults here. But let us see how this goes. 

 Ian> This document gives some general advice about friendly interaction.
 Ian> It also says what you can do when this fails: if you are having
 Ian> problems working well with another Developer; or if, despite talking
 Ian> to them constructively, you cannot agree.

 Ian> 2. Distinguish flameage from technical disputes and procedural errors

 Ian> There are basically three kinds of dispute:

 Ian> * Technical disagreements: these are largely about how software should
 Ian>   work, and form the meat of many of the Project's discussions.

 Ian> * Procedural disagreements: these are about how the project should
 Ian>   work, rather than about software.

 Ian> * Interpersonal disputes - just `not getting along'.  In any large
 Ian>   community like Debian there will be personality clashes, and people
 Ian>   you find difficult to deal with.

 Ian> Try to keep these separate, and to get along as best you can.

	Excise the last sentence. Platitude.

 Ian> For Debian to be able to construct good software, we must be able to
 Ian> disagree with the way something is done or proposed in a constructive
 Ian> and useful way.  The best designs result when all the issues have been
 Ian> considered.


 Ian> Useful technical discussions can become derailed by flameage.  To help
 Ian> avoid this, please phrase your technical disagreements moderately.
 Ian> If you receive a heated complaint about some technical matter, please
 Ian> try to respond to the technical, not emotional, content !

	Hmm. If that were feasible in a particular situation, I don't
 think we would be at the point of reading this document. Singing the
 Barney theme song may be good advice, but I think is is a mild insult
 to ones intelligence, ands again, belabours the obvious. 

	We do not need a document for 5 year olds; we need a document
 that is helpful when adults, who generally know a modicum of the
 tenets of social behaviour, are locked in a dispute.

	I suggest we get rid of the teaching pre schooler bits of
 aphorism, and get on with information that developers can use.

 Ian> 3. Interpersonal behaviour

 Ian> If you are having problems getting along with another developer,
 Ian> firstly consider whether there's anything you can do to try to improve
 Ian> the situation.  Send only moderate, reasonable messages; offer to talk
 Ian> in some other way, perhaps even by phone (it's much easier to give
 Ian> offence accidentally by email or on IRC than on the phone).

	Same as bove. I would assume we all have actually interacted
 with other humans, and we know that you can get flies caught with
 honey. If I am reading this document, vacuous banalities are not what
 I need. 

 Ian> Check that there is some purpose to continuing the dispute
 Ian> besides trying to extract an apology.  If you just want an
 Ian> apology, and aren't getting it, then you will probably just have
 Ian> to put it down to experience and move on.  Some people -
 Ian> particularly expert programmers! - are just a bit difficult, and
 Ian> it's usually best just to put up with them.

	If we edit this down to a single sentence, this would be fine.

 Ian> If it's a technical dispute, try to talk only about the technical
 Ian> questions at issue.  Avoid complaining to the other Developer that
 Ian> they are being unhelpful; that'll turn the conversation into a
 Ian> shouting match.

	Umm. The irony.

 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.

	Ok. This is good -- the first constructive mechanism that my
 mother did not tell me about.

 Ian> 4. Procedural mistakes and disagreements

 Ian> The Project has many rules and conventions, written and
 Ian> unwritten, about when certain actions are appropriate and are
 Ian> inappropriate.  For example, sending a non-maintainer-upload of
 Ian> another Developer's package, closing and reopening a bug report,
 Ian> and forwarding mail from one place to another, are all sometimes
 Ian> appropriate but sometimes not.

 Ian> If you feel another Developer has erred, by failing to go about things
 Ian> in the right way, you should of course tell them about it.  But,
 Ian> please try to make your message helpful and friendly.  Probably they
 Ian> didn't know about the rule in question, or understand it differently.

 Ian> If you can, refer the other Developer to some documentation explaining
 Ian> what the right process is.  If such documentation does not exist,
 Ian> consider writing it - it is difficult for nonexistent documentation to
 Ian> be authoritative, and a misunderstanding that arises once in the
 Ian> absence of a documented procedure is likely to arise again.  The
 Ian> Debian Developers' Reference is usually an excellent place to document
 Ian> common practice.

 The Project has many rules and conventions, written and unwritten,
 about when certain actions are appropriate and are
 inappropriate. Often, these rules are not absolute, and context is
 important. If you feel another Developer has erred, by failing to go
 about things in the right way, please start by pointing out politely
 that they may have missed the rule, and accompany your message with
 references to the specific procedure, or pointing to precedents that
 establish an unwritten rule. If possible, accompany your request with
 a rationale for the correct procedure, and why yuo feel it applies to
 this case.

	A conciliatory request may work better than a confrontational
 one, and one should not assume that the error was deliberate, it
 could well have been an oversight. 

 Ian> If the other Developer disagrees, you should seek guidance from the
 Ian> wider Project, so that everyone has the same ideas of how things are
 Ian> supposed to work.  In the end, if a firm decision needs to be made,
 Ian> the Project Leadership will have to decide.

 In case of a disagreement over the rule or practice in general,
 please seek guidance from thewider Project, and start a discussion on
 the merits of the rule or practice; often, it may be that the rule or
 practice needs to be amended or have exceptions added; and the result
 may be a better dcumented rule with the rationale that may prevent
 such a disagreement in the future. 

 Ian> If a Developer persistently flouts the Project's rules - written or
 Ian> unwritten - then you should consult the Project Leadership for advice;
 Ian> the Project Leadership will, if appropriate, warn them about their
 Ian> behaviour, and in extreme cases may seek the Developer's expulsion.

	I think we should excise this stick. We do not need to talk
 about chastisement and punishment in a dicument about reconciliation
 -- the project leadership can act on such flouting after qa genberal
 discussion on its own.

 Ian> 5. Technical disagreements

 Ian> Most disagreements in the Project are technical; this is good.

	Chatty and paternalistic. 

 Ian> The vast majority are useful, and can be resolved by constructive
 Ian> discussion where all aspects of the problem are considered.  All
 Ian> Developers should participate constructively in technical discussions
 Ian> where necessary.  When you're short of time you should reduce the
 Ian> quantity, not the quality, of your contributions.

	Again, I wouldn't be reading this if that were still feasible,
 and this is redundant. We are not all social misfits that need be
 reminded of basic rules of interpersonal interactions.

 Ian> Be flexible; try to avoid categorical statements such as `I will never
 Ian> implement that'.  There is no shame in being convinced, by good
 Ian> arguments, to change your mind, even if you have just been vigorously
 Ian> promoting the opposite view !

	There are things I shall never implement, and I am not going
 to muzzle myself. Usually, there are good solid reasons for my
 statements. (I shall never include a remote root exploit into my

	If we excise these avuncular comments, we shall have a decent
 skeleton of a useful document.

 Ian> In the case of a tradeoff between one good property and another,
 Ian> there are often value judgements to be made; these value
 Ian> judgements are usually best made by package maintainers, and
 Ian> other developers should allow the maintainer of a package some
 Ian> leeway.

	Umm, unless we happen to disgree, or the maintainer is Herbert Xu?

 Ian> If discussing the issue with all the relevant people hasn't
 Ian> produced a conclusion and doesn't look like it will, the
 Ian> Technical Committee can decide.  You can refer it to the
 Ian> Committee in the form of a bug report (see below); sending a
 Ian> summary of the situation to the Committee would be very helpful,
 Ian> too.

 Ian> 6. Bug report etiquette

 Ian> Sometimes bugs are reported inappropriately; likewise, sometimes
 Ian> maintainers close bug reports inappropriately.  Bug reports are
 Ian> `todo list' items for the whole Project; they should be closed
 Ian> when there is rough consensus that the whole system is working
 Ian> as well as it could.

	I strongly disagree. The Bug list is a communications
 mechanism that allows us to improve debian, and as such, it is far
 more, and in some aspects, less than, a TODO list. 

	The BTS allows users of our packages to communicate with us,
 and enables contributrs to work on the problems with the package. As
 such, the bug severity is a simple mechanism to allow allocation of
 scant resources; and it is important that there is a common
 understanding of what a priority implies. 

 Ian> For example, here are some examples of situations where a bug report
 Ian> should not be closed:

 Ian> * The bug was reported against A, reassigned to B, but the maintainer
 Ian> of B feels that B is working correctly (and by implication that the
 Ian> bug is in A).  The maintainers should talk about it to decide which
 Ian> package needs to change, without closing the bug until it's fixed.

	In this case, obviously the BTS is recording a problem, and
 not merely a todo list of either package. You may argue that all
 problems should be fixed, and thus are todo items, but that
 abstraction loses a llot of the characteristics of the phenomena that
 a bts represents. 

 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.

 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.

 Ian> At no other time should you play `bug report tag' with anyone
 Ian> else.  If someone makes a change to a bug report status which
 Ian> you disagree with you should *discuss* the matter with them but
 Ian> *not* immediately undo their action in the BTS, except to reopen
 Ian> the bug to stop it getting lost.  If you are unable to reach a
 Ian> conclusion through constructive discussion, you should ask for
 Ian> outside help with resolving your dispute, as outlined above.

 Ian> Note that while the Technical Committee is also happy to help resolve
 Ian> disputes over individual bug reports, you should not refer a matter to
 Ian> the Committee until you have tried to explore the issue yourselves.
 Ian> When this has been done, the bug report logs should contain detailed
 Ian> description of the problem and records of your discussions, and you
 Ian> may then reassign the bug report to the pseudo-package `tech-ctte'.

	This last bit sounds fair enough.


 The Law of Software Envelopment Every program at MIT attempts to
 expand until it can read mail. Those programs which cannot expand are
 replaced by ones which can.
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: