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 <email@example.com> 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> 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
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
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
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> 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> 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 <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